Software UART -> Eingabe überwachen

pcprofi

Neues Mitglied
12. Apr. 2008
90
0
0
Sprachen
Hallo Bascom-Profis,

hab da mal wieder ein Problem:

Ich muss leider eine Software-UART nutzen... Wie kann ich es hinbekommen, dass die Software ein Byte auffängt, und dieses irgendwo buffert, so dass ich es im Programmverlauf abfragen kann?

Oder muss ich tatsächlich hingehen, und muss dem 2. µC (der Hardware-UART nutzt) eine AbfrageMitteilung senden, ob er was parat hat, und dann auf die Antwort warten?

Gruß Rainer

[edit]

Sprache wäre BASCOM
 
Hallo Rainer!

Also wenn ich mir deine Frage so durchlese überlege ich nun, wo genau das Problem sein soll. :hmmmm:

Wenn du z.B. mit :
Code:
Open "COMC.5:9600,8,N,1,inverted" For Input As #1          'PC.5 = RxD

den Pin C.5 als Dateneingang definierst, kannst du in deinem Programm z.B. mit :
Code:
Inputbin #1 , Rxd_Wert

den seriellen Eingang abfragen und den Wert in die Variable "Rxd_wert" abspeichern.


Nun kannst du im weiteren Verlauf die Variable "Rxd_wert" in deinem Programm nutzen.
Die eingegangenen Daten sind damit also (zwischen) gespeichert.


Hattest du deine Frage so gemeint? :hmmmm:


Gruß,
Cassio
 
Hallo Rainer,

in BASCOM gibt es dazu das spezielle "Config Serialin = Buffered , Size = 128" Konstrukt.

Code:
' ----- CONFIG -----

' Hardware RS232 Kanal 1 konfigurieren = interne RS232
Config Com1 = 38400 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0
[COLOR="Red"][B]Config Serialin = Buffered , Size = 128[/B][/COLOR]
Open "com1:" For Binary As #1

' Software RS232 Kanal 2 und 3 konfigurieren = externe RS232
' Anschluss an Mega16 über PORTB.0 für RxD und PORTB.1 für TxD.

' Achtung: Tracesausgaben zum PC erfolgen über SW-RS232. Die HW-RS232 wird zur
' Kommunikation mit dem Slave verwendet

' Öffnen eines Transmit-Kanals (#2) für Ausgaben
Open "comb.1:38400,8,n,1" For Output As #2

' Öffnen eines Receive-Kanals (#3) für Eingaben
Open "comb.0:38400,8,n,1" For Input As #3

Ich habe in meinem Zisternen-Füllstand-Anzeigen-Projekt hier auch auf einen SW-Uart zurück greifen müssen da mein Mega16 nur einen RS232-Kanal hat, ich aber zwei RS232 benötigt habe.

In dem Codebeispiel oben siehst Du meine Initialisierung.
Das Komplette programm findest Du auf Seite 6 im oben genannten Thread.

Eine gute Hilfe bietet hierbei auch die BASCOm-Hilfe für den Befehl "CONFIG SERIALIN". Zu beachten sind dort Sonderbefehle zum löschen (clear) des Buffers usw.

Aus der Erfahrung heraus kann ich Dir sagen dass es gut funktionier tund ich sehr zufrieden mit der Lösung bin.

Ich würde vorschlagen, schau Dir zunächst die BASCOM Hilfe und das BASCOm Beispiel an, dann schau einfach mal in den Code von mir und wenn noch Fragen sind melde Dich einfach.

Grüße,
Markus
 
Hallo Zusammen,

das, was Markus geschrieben hat ist genau die Lösung. Ich wollte die Software-UART Buffern, damit ich eben im Hauptprogramm abfragen kann, ob per UART etwas eingegangen ist oder nicht. Aber Markus hat diesen Befehl auch nur für die HW-UART verwendet - NICHT bei der Software (oder ich habe es übersehen).

Oder gilt das global?

Allerding sehe ich ich auf der MCS-Seite nichts über die Verwendung einer SW-UART - da steht nur was über Hardware... Deswegen komme ich da gerade jetzt so iwie nicht weiter...

Hatte das bisher so gelöst:

Der "Haupt"-µC sendet ein Anfragebyte an den Slave - und dieser antwortet mit einem Entsprechenden Byte. Das ist aber ein unnötiger Zeitaufwand.

Gruß Rainer
 
Hallo Rainer,

Der "Haupt"-µC sendet ein Anfragebyte an den Slave - und dieser antwortet mit einem Entsprechenden Byte. Das ist aber ein unnötiger Zeitaufwand.

Hmmm, verstehe ich nicht genau wo jetzt Dein Problem ist. Alsooo, der Buffer sollte auch mit dem SW-Interface funktionieren. Alles andere wäre unplausibel.

Ist Dein Problem jetzt das überflüssige Zeichen?

Kannst Du mir mal Deinen Code anhänge? Ich würde mir das gerne mal im Code ansehen, welche Routinen und Funktionen Du verwendest. Es sieht aktuell für mich so aus - wenn es das Problem ist - das Du eine Funktion verwendest welche ein Echo produziert.

Näheres kann ich aber erst auf Basis Deines Codes sagen,

Grüße,
Markus
 
Hallo Markus,

also konkret geht es um folgendes:

Ich steuere eine Uhr (Ja - Ich weiß, Projektvorstellung folgt nach Fertigstellung mit allem drum und dran zum zerflücken und verbessern) per RC5-IR-FB. Weil das vorher allerdings nur mit drei Tasten erfolgt ist, habe ich nicht darauf geachtet, dafür z.B. die TXD/RXD Pins zu nehmen, sondern einfach die nächstbesten.

Jetzt die Umgestaltung zur IR-Fernbedienung.

Weil in der Uhr aber alle drei Timer benötigt werden (ATMega8: Timer, Multiplex, PWM), musste ich für das RC5 auf einen weiteren µC ausweichen. Da ich nur 2 Pins zur Vefügung habe (außer +VCC/GND) hab ich mir gedacht - Prima nimmste halt UART.

Jetzt macht dieser zweite µC ja nichts weiter, als auf RC5-Signale zu lauschen, und er sortiert sie soweit, dass er sozusagen bereits ein "UART-Codesignal" an den UhrenµC sendet, damit dieser weiß, was er auszuführen hat.

Code hab ich grad nicht da - ich versuchs mal ein bissl zu symbolisieren:

Momentaner Status:

In regelmäßigen Intervallen:

µC sendet Kennung per UART an RC5-µC.
Der schaut nach, ob da ein RC5-Befehl gekommen ist und schickt eine dementsprechende Antwort zurück.

Hier muss immer wieder bei jeder Schleife die Abfrage genutzt werden - aber bei einer Timing-kritischen Sache wie einer Uhr ist das suboptimal.


So stelle ichs mir vor:

Wenn der RC5-µC einen RC5 Befehl bekommt, dann sendet er sofort ein Signal per UART an den UhrenµC. Dort wird das Signal dann gebuffert, so dass der µC in der Main-Loop mit ISCHARWAITING() abprüft ob da was angekommen ist, und dann eben die Subroutine zur Abarbeitung des UART-Befehls dezent einfach überspringen kann.

Wäre auch alles kein Problem - wenn ich denn die Hardware-UART nutzen könnte.


Ich hoffe jetzt isses verständlicher...




[EDIT]

Natürlich wäre auch ein Umstieg auf eine andere Übertragungsart möglich - wenn eben nur die 2 Signalleitungen benutzt werden... Bei der UART bin ich mir halt in der Anwendung bei Bascom relativ sicher, deswegen hab ichs genommen...
 
Hallo Rainer,

jetzt weiß ich zwar was Du machen möchtest. Hört sich soweit alles verständlich und plausibel an.

Nun weiß ich aber noch weniger, worin den eigentlich Dein Problem liegt. Soweit ich Dich verstanden habe möchtest Du den SW-Uart nutzen. Ich bin der Meinung, dass da nichts dagegen spricht.

Hast Du den Uart schon in Betrieb genommen und wie sind die Ergebniss?
Wie sieht Deine Konfiguration des UART aus?
Hast Du den Buffer aktiv?
Welche Funktionen verwendest Du zum Lesen und Schreiben von Zeichen auf die RS232?

Wenn diese grundlegenden Fragen geklärt sind, die ich brauche damit ich ein Verständnis für Dein Problem entwickeln kann, dann brauche ich von Dir noch etwas präziesere Infos, was denn nicht geht und wo genau welches Fehlerverhalten auftritt.

Sorry aber gerade jetzt verstehe ich nur Bahnhof. Ich verstehe nur "da funktioniert was nicht" aber ich habe keine Ahnung, was nicht funktioniert, was das Problem ist und was Du schon alles ausprobiert hast und im Code umgesetzt hast. Ich brauche die Info wie es ist und wie Du es haben möchtest.

Please more input more input!!!

Grüße,
Markus
 
Hallo Rainer!

Ich weiß was du machen möchtest und hatte das so in der Art für meinen 57mm-LED-Wecker auch mal aufgebaut.
Letztlich habe ich aber den IR-Empfang dem Haupt-µC überlassen und dem "Neben-µC" anderen Aufgaben zugeteilt. ;)
Die Komunikation ist aber identisch!


Der "Haupt-µC" kümmert sich bei dir also um alle wichtigen Dinge wie Uhr und weiteres und lediglich den RC5-Empfang möchtest du von einem separaten µC erledigen lassen.

Dein Ansatz (wie Markus auch schon schrieb) mit dabei völlig in Ordnung!

Eigentlich brauchst du sogar nur eine serielle Verbindung.
Der IR-µC sendet permant ein "Signal"-------> und der Haupt-µC nimmt es entgegen und verarbeitet die Info weiter.



Du richtest dir mit "Open" jeweils die benötigten Verbindungen ein, also z.B.:
Im Haupt-µC = Open "COMC.1:9600,8,N,1,inverted" For Input As #1

und im IR-µC = Open "COMB.1:9600,8,N,1,inverted" For Output As #1


In der Hauptschleife des IR-µC fragst du permanent den IR-Code ab und übergibst dann die Comand-Variable zum Senden an den Haupt-µC.
Zum Beispiel = Printbin #1 , IR_cmd

Im Haupt-µC fragt dein Programm immer wieder den Software-RxD ab und weißt die Daten einer Variable zu: Inputbin #1 , IR_Comand

Nun kannst du im Haupt-µC die Variable "IR_Comand" ganz normal weiter verwenden.

Solltest du auch noch die IR-Adresse benötigen, musst du das nur entsprechend umbauen bzw. erweitern.

Eines wäre vielleicht noch zu beachten...
Der Befehl "Inputbin" lässt ggf. dein Programm im Haupt-µC warten bis Daten am Pin eingehen......
Darum sollte der IR-µC auch ständig Daten senden!


Ich hoffe, es war soweit verständlich. ;)

Schöne Grüße,
Cassio
 
So, wieder @home gibts jetzt die Codeschnippsel:

Ich habe momentan einen String zur Übertragung benutzt (Testphase), da man es besser mit mitlesen kann finde ich. Dass da noch mehr als der eigentliche String übertragen wird (CR/LF) ist mir klar - wird aber dezent vom Programm erstmal überlesen. Umstieg auf Bytes wird folgen, da die Uhr ne Funktion bekommen soll, mit der man sich die Codes einer RC5-FB anzeigen lassen kann, um dann enstprechend zu Programmieren.

Der IR-Empfänger:

Code:
Do


Getrc5(address , Command)
Getrc5(address_validation , Command_validation)

If Command = Command_validation Then
If Address = Address_validation Then
If Ischarwaiting() = 1 Then
   Received = Inkey()
   If Received = "A" Then
      If Address = 30 Then
         Select Case Command
            Case 189
               Print "A"
            Case 61
               Print "A"
            Case 16
               Print "B"
            Case 144
               Print "B"
            Case 32
               Print "E"
            Case 160
               Print "E"
         End Select
      Else
         Print "D"
      End If
   End If
End If
End If
End If


Loop

End



Uhren-µC:

Hier fehlt jetzt natürlich einiges an Code - die Grundfunktion dürfte aber klar sein.

Code:
Open "Comb.0:9600,8,N,1" For Input As #1                    ' RXD Receive Data
Open "Comb.1:9600,8,N,1" For Output As #2                   'TXD Transceive Data




Do

Received = Inkey(#1)

If Received = "D" Then
   nop
  Else
   If Received = "B" Then
      Incr Digit3
      If Digit3 = 10 Then
        Digit3 = 0
        Digit4 = Digit4 + 1
      End If
      If Digit4 = 6 Then
        Digit4 = 0
      End If
      Waitms 300
   End If
   If Received = "E" Then
     Incr Digit5
     If Digit5 = 10 Then
       Digit5 = 0
       Digit6 = Digit6 + 1
     End If
     If Digit6 = 2 Then
       If Digit5 = 4 Then
         Digit6 = 0
         Digit5 = 0
       End If
    End If
    Waitms 300
  End If
END IF

Loop

Sekundentick:

Print #2 , "A"
Incr Digit1

Return

Folgendes Problem ergibt sich halt hier: Ich arbeite mit 9600 Baud. Immer wenn der Empfang von einem Interrupt gestört wird lässt sich Müll nachweisen, ist ja auch logisch - in den meisten Fällen wirds halt einfach ignoriert, weil es nicht durch die Schleifen geht.
Noch ein Nachteil: Die Anfrage an den IR-µC wird im Sectic gestellt. Also einmal pro Sekunde, was zum Stellen der Uhr einfach zu K***** ist :shout:.
Setze ich das in die Main-Loop, stürzt der IR-Controller einfach ab. Der andere mögliche Interrupt vom Multiplexing ist da nciht viel anders.

Daher die Idee einfach senden, und wenn was da ist soll ers in der Main-Loop merken und eine Subroutine starten. Problem: Ich kann (könnte schon, möchte aber nciht) die Mainloop nicht anhalten und auf ein Zeichen warten, weil sie u.A. die Berechnung der einzelnen Ziffern übernimmt - aber nur wegen eines optischen Details (Verzögerung). Das wiederum geht also nur mit einem Buffer.
Der Buffer geht aber seinerseits wieder nicht - weil er ja in Software geschrieben werden müsste und da müsste dann schon wieder ein Interrupt mindestens her - der HW-Buffer ist ja physikalisch vorhanden.

Also gibt es für mein Problem 2 Lösungsmöglichkeiten:

Entweder die Anfrage/Antwort-Möglichkeit extrem beschleunigen - nur wie? - oder aber wie beschrieben, IR sendet ständig, und Uhr schaut nach, ob was im Buffer liegt...

Auch hier noch mal der Hinweis: Wenn ihr der Meinung seid, mit einer anderen Übertragungsart ginge das evt. besser, immer her damit...


Gruß Rainer
 
Hallo Rainer!

Warum machst du dir das Leben eigentlich so schwer! ;)

Probiere mal meine oben erwähnte Variante aus und du wirst merken, wie einfach alles sein kann. :)

Du benötigst keinen String zum senden, kein Inkey(), kein Ischarwaiting() und was noch so alles....


Dein IR-µC stellt immer die passenden Daten bereit und dein Haupt-µC nimmt sie einfach nur engegen, sobald das Programm dort in der Schleife vorbei kommt.
Fertig! :D

Selbst wenn du die IR-Adresse und das IR-Komando senden möchtest, machts du das nur bei beiden µCs in der selben Reihenfolge nacheinander....
Dadurch dass der Haupt-µC per Inputbin auf die Daten "wartet", passen die übermittelten Daten auch mit den Variablen zueinander.


Probiere es einfach mal mit einer einfachen Funktion und lass alles andere erst mal raus....


Schön wäre es auch, wenn wir die Reste vom Programmcode sehen könnten....
Einige Variablen kann man so besser nachvollziehen und außerdem frage ich mich immer noch, was du mit den ganzen Timern machst. :hmmmm:

Vielleicht liegt ja auch da der Lösungsansatz drin und du kannst dir die ganze Arbeit mit der seriellen Verbingung am Ende sparen. ;)


Gruß,
Cassio
 
Hallo Rainer!

Warum machst du dir das Leben eigentlich so schwer! ;)

Das wüsst ich manchmal auch gern...

Probiere mal meine oben erwähnte Variante aus und du wirst merken, wie einfach alles sein kann. :)

Habe ich bereits ausprobiert - aber entweder war ich zu doof oder der µC. Ich habe da dann 2 Bytes übermittelt - es kamen aber immer nur unsinnige und vor allem NIE gleiche Bytes an...

Du benötigst keinen String zum senden, kein Inkey(), kein Ischarwaiting() und was noch so alles....


Dein IR-µC stellt immer die passenden Daten bereit und dein Haupt-µC nimmt sie einfach nur engegen, sobald das Programm dort in der Schleife vorbei kommt.
Fertig! :D

Das funktionierte ja nicht - so hatte ich mir das auch erst gedacht. Leider existiert der Programmtext dazu nicht mehr - war aber so ähnlich wie bei dir beschrieben...

Selbst wenn du die IR-Adresse und das IR-Komando senden möchtest, machts du das nur bei beiden µCs in der selben Reihenfolge nacheinander....
Dadurch dass der Haupt-µC per Inputbin auf die Daten "wartet", passen die übermittelten Daten auch mit den Variablen zueinander.


Probiere es einfach mal mit einer einfachen Funktion und lass alles andere erst mal raus....

Siehe Oben. Es tat es nicht... Selbst wenn KEIN RC5-Signal übermittelt wird, was beim µC bei Adresse und Kommando ja jeweils 255 sein lässt kam vielleicht bei jeder 10. Übertragung mal 255/255 an.

Schön wäre es auch, wenn wir die Reste vom Programmcode sehen könnten....
Einige Variablen kann man so besser nachvollziehen und außerdem frage ich mich immer noch, was du mit den ganzen Timern machst. :hmmmm:

Rest vom Code kommt noch - muss ihn nur erstmal aufräumen, bzw. ich bin gerade dabei. Es ist aber noch eine Rohform, alle festen Werte werden später noch in Konstanten gepackt...

Timer0: Multiplex
Timer1: Sekundentick
Timer2: PWM (allerdings nur für die Doppelpunkte - könnte man auch durch andere Rs davor lösen, fand aber die Datenübertragungsproblematik auch ganz interessant... Mache das ja nur zum lernen...

Vielleicht liegt ja auch da der Lösungsansatz drin und du kannst dir die ganze Arbeit mit der seriellen Verbingung am Ende sparen. ;)


Gruß,
Cassio

Gut Möglich... Bzw eigentlich liegt er in den anderen Widerständen für den Doppelpunkt... Aber man will ja auch was dabei lernen...

Gruß Rainer


[edit]

HIer kommt der teilweise noch unaufgeräumte Code....

Code:
' ------------------------------------------------------------
'  Grundeinstellung des Microcontrollers
' ------------------------------------------------------------

$regfile = "m8def.dat"
$crystal = 16000000
$hwstack = 100
$swstack = 100
$framesize = 100

' ------------------------------------------------------------
'  Einstellung der Ausgabepins für das Display
' ------------------------------------------------------------

Config Portd.0 = Output                                     ' Segment A
Config Portd.1 = Output                                     ' Segment B
Config Portd.2 = Output                                     ' Segment C
Config Portd.3 = Output                                     ' Segment D
Config Portd.4 = Output                                     ' Segment E
Config Portd.5 = Output                                     ' Segment F
Config Portd.6 = Output                                     ' Segment G

Config Portc.0 = Output                                     ' Sek-Einer
Config Portc.1 = Output                                     ' Sek-Zehner
Config Portc.2 = Output                                     ' Min-Einer
Config Portc.3 = Output                                     ' Min-Zehner
Config Portc.4 = Output                                     ' Std-Einer
Config Portc.5 = Output                                     ' Std-Zehner


' -----------------------------------------------------------
'  Definierung der Software-UART, entstanden durch vorherige
'  Nutzung von Tastern. Umbau auf IR-Fernbedienung, aus
'  den Platz- und Timer-Gründen dann in weitern µC aus-
'  gelagert. Der PortPin B.2 stellt die Stromversorgung des
'  IR-Moduls dar, der benötigte Strom war 7 mA.
' -----------------------------------------------------------


Open "Comb.0:9600,8,N,1" For Input As #1                    ' RXD Receive Data
Open "Comb.1:9600,8,N,1" For Output As #2                   'TXD Transceive Data
Config Portb.2 = Output                                     ' Spannungsversorgung
Portb.2 = 1

' -----------------------------------------------------------
'  PortB.3 ist für das Blinken der Punkte zuständig, wird
'  per PWM gedimmt.
' -----------------------------------------------------------

Config Portb.3 = Output

Config Timer2 = Pwm , Compare Pwm = Clear Down , Prescale = 8
Ocr2 = 1


' -----------------------------------------------------------
'  Timer1 erstellt den Sekundentick - Auslösung 1x pro Sek.
' -----------------------------------------------------------


'TIMER1
Config Timer1 = Timer , Prescale = 1024 , Clear Timer = 1
Compare1a = 15625
On Compare1a Sekundentick


' -----------------------------------------------------------
'  Definierung der Subroutines für die Multiplexing-Anzeige
' -----------------------------------------------------------

Declare Sub 7digit1
Declare Sub 7digit2
Declare Sub 7digit3
Declare Sub 7digit4
Declare Sub 7digit5
Declare Sub 7digit6
Declare Sub Disp_off


' -----------------------------------------------------------
'  Definierung des Timers zum Multiplexen
' -----------------------------------------------------------

Config Timer0 = Timer , Prescale = 256
Timer0 = 127
On Ovf0 Multiplex

' -----------------------------------------------------------
'  Variablen
' -----------------------------------------------------------

Dim Digit1 As Byte
Dim Digit2 As Byte
Dim Digit3 As Byte
Dim Digit4 As Byte
Dim Digit5 As Byte
Dim Digit6 As Byte

Dim Blinking As Bit

Dim Display_off As Bit
Display_off = 0


Dim Anzeige As Byte

Dim Received As Byte
Dim Count As Byte


' ------------------------------------------------------------
'  Start
' ------------------------------------------------------------


Enable Timer0
Disable Timer1
Enable Timer2
Disable Compare1a
Enable Interrupts

Dim Tmr0preset As Byte
Tmr0preset = 127


'Digits





Anzeige = 1


Digit1 = 8
Digit2 = 8
Digit3 = 8
Digit4 = 8
Digit5 = 8
Digit6 = 8

Wait 5
Enable Compare1a

Digit1 = 0
Digit2 = 0
Digit3 = 0
Digit4 = 0
Digit5 = 0
Digit6 = 0

Ocr2 = 249

Enable Timer1

Enable Oc2

Do

Received = Inkey(#1)

If Received = "D" Then
   nop
  Else
   If Received = "B" Then
      Incr Digit3
      If Digit3 = 10 Then
        Digit3 = 0
        Digit4 = Digit4 + 1
      End If
      If Digit4 = 6 Then
        Digit4 = 0
      End If
      Waitms 300
   End If
   If Received = "E" Then
     Incr Digit5
     If Digit5 = 10 Then
       Digit5 = 0
       Digit6 = Digit6 + 1
     End If
     If Digit6 = 2 Then
       If Digit5 = 4 Then
         Digit6 = 0
         Digit5 = 0
       End If
    End If
    Waitms 300
  End If
  If Received = "A" Then
    If Anzeige = 7 Then
        Anzeige = 1
      Else
        Anzeige = 7
    End If
    Waitms 200
  End If
End If



If Digit1 = 10 Then
  Digit1 = 0
  Waitms 200
  Digit2 = Digit2 + 1
End If
If Digit2 = 6 Then
  Digit2 = 0
  Waitms 200
  Digit3 = Digit3 + 1
End If
If Digit3 = 10 Then
  Digit3 = 0
  Waitms 200
  Digit4 = Digit4 + 1
End If
If Digit4 = 6 Then
  Digit4 = 0
  Waitms 200
  Digit5 = Digit5 + 1
End If
If Digit5 = 10 Then
  Digit5 = 0
  Waitms 200
  Digit6 = Digit6 + 1
End If
If Digit6 = 2 Then
  If Digit5 = 4 Then
    Digit6 = 0
    Digit5 = 0
  End If
End If





Loop










Sekundentick:

Dim Nebenrechnung As Byte

Print #2 , "A"
Incr Digit1
If Anzeige = 7 Then
  Ocr2 = 255
 Else
  Nebenrechnung = Digit1 Mod 2
  If Nebenrechnung = 1 Then
    Ocr2 = 249
   Else
    Ocr2 = 255
  End If
End If

Return


Multiplex:
Timer0 = Tmr0preset

  Select Case Anzeige
      Case 1 : Gosub 7digit1
      Case 2 : Gosub 7digit2
      Case 3 : Gosub 7digit3
      Case 4 : Gosub 7digit4
      Case 5 : Gosub 7digit5
      Case 6 : Gosub 7digit6
      Case 7 : Gosub Disp_off
  End Select
Return


Sub 7digit1
Reset Portc.5

Portd = Lookup(digit6 , Segmente)
Set Portc.0
Anzeige = 2
'Waitms 1

End Sub

Sub 7digit2
Reset Portc.0

Portd = Lookup(digit5 , Segmente)
Set Portc.1
Anzeige = 3
'Waitms 1

End Sub

Sub 7digit3
Reset Portc.1

Portd = Lookup(digit4 , Segmente)
Portc.2 = 1
Anzeige = 4
'Waitms 1

End Sub

Sub 7digit4
Reset Portc.2

Portd = Lookup(digit3 , Segmente)
Portc.3 = 1
Anzeige = 5
'Waitms 1

End Sub



Sub 7digit5
Reset Portc.3

Portd = Lookup(digit2 , Segmente)
Portc.4 = 1
Anzeige = 6
'Waitms 1

End Sub



Sub 7digit6
Reset Portc.4

Portd = Lookup(digit1 , Segmente)
Portc.5 = 1
Anzeige = 1
'Waitms 1

End Sub

Sub Disp_off
Portc = &B00000000

End Sub


Segmente:
        'gfedcba
Data &B11000000                                             '0
Data &B11111001                                             '1
Data &B10100100                                             '2
Data &B00110000                                             '3
Data &B00011001                                             '4
Data &B00010010                                             '5
Data &B00000010                                             '6
Data &B01111000                                             '7
Data &B00000000                                             '8
Data &B00010000
 
Hmmmmm, im Prinzip könnte ich mir schon das Problem von Rainer vorstellen das er hat. Ich hatte das Problem bei meiner Zisternengeschichte auch.

Mein Problem war, dass zwei geräte unabhängig voneinande rund damit asynchron laufen. Ich konnte nicht sicherstellen, dass wenn der eine sendet, der andere damit gleich mit dem ohr auf der Leitung war. Ich habe Zeichen verloren und auch nur Schrott gelesen. Selbst die niedrige Baudrate von 9600 brachte hier keine Abhilfe. Erst die Einführung des buffers brache für mich die Lösung und seit dem funktionierte es einfach gut.

Damit habe ich beide Geräte zeitlich voneinander entkoppelt und es ist mir zunächst egal wer wann was sendet da die Daten gebuffert werden.
Ich könnte mir vorstellen, speziell bei der SW-Lösung, das laufende Timer und sonstige Interrupts hier bereits für eine zeitliche Verschiebung sorgen.

Grüße,
Markus
 
Hallo Rainer!

Jetzt läuft mir gerade die Zeit davon, aber kurz noch ein paar Zeilen....


Den PWM nur für die Doppelpunkte zu benutzen ist aber schon mächtig gewaltig!
Wenn du nur die Heligkeit anpassen möchtest, solltest du einfach andere Widerstände benutzen. ;)


Der IR-Empfang sendet...... wenn er nichts empfängt: Adresse: 255 / Komando: 127 !
Nicht 255/255 ! ;)

Wenn nur Müll rauskommt, dann werden die Daten nicht zeitgleich übermittelt.
Du kannst natürlich auch eine bidirektionale Verbindung aufbauen.
Wenn der Haupt-µC im Programm an die Stelle kommt, dass er auf die passenden Daten wartet, kann er ja ein Signal zum IR-µC senden.
Der IR-µC wartet also per "Inputbin" nur auf sein Signal und sendet dann per "Printbin" die erste Variable..... z.B. die IR-Adresse.
Dass nimmt der Haupt-µC mit "Inputbin" entgegen und sendet gleich danach wieder ein "Printbin"-Signal, was den IR-µC dazu veranlasst das zweite Signal zu senden.
Danach hat der Haupt-µC beide Variablen sinnvoll gefüllt und geht seiner Wege......
Während der IR-µC schon wieder auf das neue Signal vom Haupt-µC wartet.


Deinen restlichen Code kann ich mir nun mangels Zeit nicht mehr ansehen...
Wenn kein anderer hier schneller ist, dann schreibe ich ggf. später noch etwas dazu.

Schöne Grüße,
Cassio
 
Erst die Einführung des buffers brache für mich die Lösung und seit dem funktionierte es einfach gut.

Hi Markus!

Das ist natürlich die eleganteste Lösung! ;)


Ich habe mit "Printbin" und "Inputbin" auch nur mal "rumgespielt" und festgestellt, dass es damit recht einfach ist kleine Daten zwischen zwei µCs auszutauschen.


Gruß,
Cassio
 
Den PWM nur für die Doppelpunkte zu benutzen ist aber schon mächtig gewaltig!
Wenn du nur die Heligkeit anpassen möchtest, solltest du einfach andere Widerstände benutzen. ;)

Stimmt - war damals aber einfach mal so gemacht zum lernen - könnte man umändern, mir ging es aber jetzt immernoch darum, dass man sich ja mal mit Datenübertragung beschäftigen könnte.

Der IR-Empfang sendet...... wenn er nichts empfängt: Adresse: 255 / Komando: 127 !
Nicht 255/255 ! ;)

Da muss ich dir recht geben - habe das Toggle-Bit nicht beachtet. Allerdings halte ich es vermutlich für einfacher bei dieser Anwendung, einfach beide "KOmmandonummern" zu implementieren, als das Toggle-Bit herauszurechnen - denn bei einer Uhr spielt es wohl kaum eine Rolle, ob ich die Taste festhalte oder nochmal drücke... Aber warum sollte man sich die Mühe machen, den RC5-Code komplett auseinanderzunehmen, wenn er bereits 2 völlig in der Genauigkeit ausreichende Byte-Variablen füllt?

Wenn nur Müll rauskommt, dann werden die Daten nicht zeitgleich übermittelt.
Du kannst natürlich auch eine bidirektionale Verbindung aufbauen.
Wenn der Haupt-µC im Programm an die Stelle kommt, dass er auf die passenden Daten wartet, kann er ja ein Signal zum IR-µC senden.
Der IR-µC wartet also per "Inputbin" nur auf sein Signal und sendet dann per "Printbin" die erste Variable..... z.B. die IR-Adresse.
Dass nimmt der Haupt-µC mit "Inputbin" entgegen und sendet gleich danach wieder ein "Printbin"-Signal, was den IR-µC dazu veranlasst das zweite Signal zu senden.
Danach hat der Haupt-µC beide Variablen sinnvoll gefüllt und geht seiner Wege......
Während der IR-µC schon wieder auf das neue Signal vom Haupt-µC wartet.

Genau das ist das - wie es jetzt im Moment läuft.

Deinen restlichen Code kann ich mir nun mangels Zeit nicht mehr ansehen...
Wenn kein anderer hier schneller ist, dann schreibe ich ggf. später noch etwas dazu.

Schöne Grüße,
Cassio

Macht doch nichts... Zu einen bin ich froh, dass ihr mir helfen könnt, und zum anderen ärgere ich mich darüber, dass ich mich hier im Forum kaum beteiligen kann, weil ich einfach zu wenig AHnung habe...

Gruß Rainer
 
Hallo pcprofi,

Zu einen bin ich froh, dass ihr mir helfen könnt, und zum anderen ärgere ich mich darüber, dass ich mich hier im Forum kaum beteiligen kann, weil ich einfach zu wenig AHnung habe...
jeder fängt mal an und irgendwann gibt es auch mal ein Thema bei dem Du
weiterhelfen kannst :) Die Ahnung kommt auch mit der Zeit.

Gruß
Dino
 
Aber warum sollte man sich die Mühe machen, den RC5-Code komplett auseinanderzunehmen, wenn er bereits 2 völlig in der Genauigkeit ausreichende Byte-Variablen füllt?

Hallo Rainer!

Ich bin mir nicht sicher, ob da der Hund begraben liegt, aber.....

Der RC5-Code ist ein 14Bit Word........ und kein 16Bit Word. ;)

Es füllt also sogesehen nicht genau zwei Bytes!



Was meinst du denn mit "den RC5-Code auseinander nehmen"? :hmmmm:

Mit dem Befehl: "Getrc5(ir_adresse , ir_comando)" hast du ihn doch schon zerlegt!
Es exestieren dann doch automatisch zwei Variablen.....
In meinem Beispiel eben "IR-Adresse" und "IR-Comando" !

Bei deiner Idee müsstest du diese beiden Variablen extra wieder zusammen bringen...... um sie dann im anderen µC wieder auseinander zu "shiften".
Da wäre es doch einfacher die beiden Variablen nacheinander seriell zu übertragen. :hmmmm:


Gruß,
Cassio
 
Hallo Rainer!

Ich bin mir nicht sicher, ob da der Hund begraben liegt, aber.....

Der RC5-Code ist ein 14Bit Word........ und kein 16Bit Word. ;)

Es füllt also sogesehen nicht genau zwei Bytes!

Doch - genau da liegt er begraben - daher kommen nämlich die 255 meiner Meinung nach.

Es spielt aber in diesem Fall keine weitergehende Rolle...

Was meinst du denn mit "den RC5-Code auseinander nehmen"? :hmmmm:

Mit dem Befehl: "Getrc5(ir_adresse , ir_comando)" hast du ihn doch schon zerlegt!
Es exestieren dann doch automatisch zwei Variablen.....
In meinem Beispiel eben "IR-Adresse" und "IR-Comando" !

Bei deiner Idee müsstest du diese beiden Variablen extra wieder zusammen bringen...... um sie dann im anderen µC wieder auseinander zu "shiften".
Da wäre es doch einfacher die beiden Variablen nacheinander seriell zu übertragen. :hmmmm:


Gruß,
Cassio

nene fast... Er ist nur teilweise zerlegt, denn im Kommando steckt das Toggle-Bit mit drinne. Wenn du dieselbe Taste drückst, bekommst du einem einen Wert unter 127 und einmal denselben Wert mit 127 dazu addiert... Deswegen muss man hier was aufpassen, sonst tuts die Geschichte nur bei jedem zweiten TAstendruck...

Nein - ich zerlege den bereits im IR-µC und übertrage sozusage die aufbereitete Information. Schau mal in den Quelltext...
 
Hallo Rainer!

Das Togbit ist ja völlig sekundär......
Dieses kannst du auch immer gleich nach dem Empfang löschen (sofern du es nicht doch benötigst):

Getrc5(ir_adresse , ir_Comando)
Reset Comando.7

Damit hat sich das Togbit sofort für dich erledigt und deine Angaben stimmen auch mit dem gesendeten Code überein.


Nun ja.... probiere einfach noch mal ein wenig.
Bei mir hatte die serielle Übetragung sofort funktioniert und alle Variablen wurden störungsfrei gefüllt.


Schau mal in den Quelltext...

Sorry.... dafür habe ich zwischendurch noch keine ausreichende Zeit gefunden. :rolleyes:


Gruß,
Cassio
 
5.gif


TIMEOUT - ich ersticke im Moment in Arbeit... Projekt ruht jetzt mal ein paar Tage - danach gehts mal wieder weiter, ich schaff im MOment einfach nix...

Gruß Rainer
 

Über uns

  • Makerconnect ist ein Forum, welches wir ausschließlich für einen Gedankenaustausch und als Diskussionsplattform für Interessierte bereitstellen, welche sich privat, durch das Studium oder beruflich mit Mikrocontroller- und Kleinstrechnersystemen beschäftigen wollen oder müssen ;-)
  • Dirk
  • Du bist noch kein Mitglied in unserer freundlichen Community? Werde Teil von uns und registriere dich in unserem Forum.
  •  Registriere dich

User Menu

 Kaffeezeit

  • Wir arbeiten hart daran sicherzustellen, dass unser Forum permanent online und schnell erreichbar ist, unsere Forensoftware auf dem aktuellsten Stand ist und der Server regelmäßig gewartet wird. Auch die Themen Datensicherheit und Datenschutz sind uns wichtig und hier sind wir auch ständig aktiv. Alles in allem, sorgen wir uns darum, dass alles Drumherum stimmt :-)

    Dir gefällt das Forum und unsere Arbeit und du möchtest uns unterstützen? Unterstütze uns durch deine Premium-Mitgliedschaft!
    Wir freuen uns auch über eine Spende für unsere Kaffeekasse :-)
    Vielen Dank! :ciao:


     Spende uns! (Paypal)