RNB FRA 1.22 oder RN Control über I2C ansprechen

Hallo Roboterspezialisten!
Hat jemand schon Kenntnisse darüber, wie ich meine RNB-FRA 1.22 Roboterkarte über den I2C-Bus von der RN-Control (oder umgekehrt)ansprechen kann? Oder wie ich die Karten über den I2C-Adapter vom PC aus ansprechen kann - bzw. ganz einfach: Hat die RNB-FRA eine I2C-Slave adresse? Bei der Beschreibung der RN-Control ist so ein I2C-Netz angedeutet und es sah alles ganz einfach aus....
Ich möchte die RNB-FRA mit bestimmten Schrittfolgen für die Schrittmotoren programmieren und diese dann per I2C-Befehl abrufen.
Für Hilfe bin ich sehr dankbar!!! =D>

Hallo Leute,
nach stöbern im Forum habe ich die Möglichkeit entdeckt, die Kommunikation der beiden Kareten über einen RS232 Ringbus zu bewerkstelligen. Ich suche derzeit noch nach einer Möglichkeit mit Bascom die Schnittstelle Interrupt-gesteuert abzufragen - so wie mit dem Befehl "OnCom" in VB.
Grüße

Hi, Dottore, durch die Angabe
config serialin=buffered, size=nn
mach BasCom den Input mit Interrupt, mit der Frage
if ischarwaiting() = 1 then
databyte = inkey()
end if
kann man das dann pseudo-asynchron lesen

Danke PicNick,
reicht eigentlich nicht auch:

Enable Interrupts
Enable Int0 (Pin0, Port D für RS232 ?)
On Int0 Subroutine
End

Sub Subroutine()
if gerät=ich then
Tu was
else
schicke weiter zum nächsten Gerät
end if
Return
end

MfG,
Ulli.

Als Meta-Code ist das ja auch richtig, es gehört aber noch einiges Bit-Gefummel dazu, und sowas delegiert man besser, ind diesem Falle an den AVR u. den BasCom, die beiden sind bezahlt und sollen nun was tun.

Hallo PicNic,
danke für deine Unterstützung!
"die beiden sind bezahlt und sollen nun was tun" ist genau richtig!
Werde am Weekend mal die beiden Versionen durchtesten.
Viele Grüße

Man kann auch Interrupt Auslösen wenn Daten über RS232 empfangen wird. Ich glaub irgendwo in der Bascom Hilfe hatte ich da ein Beispiel gesehen. Kann aber auch sein das es im Kühnel Buch war, bin mir nicht ganz sicher.
Aber ich würde auch die Verfahrensweise von PicNick empfehlen. Man muss dann halt immer wenn man Zeit hat schaun ob schon ein paar Zeichen angekommen sind. Abe rwegen den Buffer ist das nicht sehr zeitkritisch. Im Prinzip läufts auch per Interrupt, nur man hat damit nix zu tun weils Bascom intern macht.


Gruß Frank

Hallo Frank,
der oben von mir zitierte Code mit "Enable Interrupts" und "Enable INT0" ist aus der Bascom-Hilfe.
Vielen Dank für die Unterstützung!
Herzliche Grüße!

Hi,

ich meinte mehr dieses konkrete Demo-Beispiel. Ist zwar für anderen Controller aber müsste eigentlich auch mit Mega gehen

Code:

---

'--------------------------------------------------------------------
'                      SERINT.BAS
'                  (c) 1999-2003 MCS Electronics
'  serial interrupt example for AVR
' also look at CONFIG SERIALIN for buffered input routines
'--------------------------------------------------------------------
'$regfile = "8535def.dat"
Const Cmaxchar = 20                                        'number of characters

Dim B As Bit                                                'a flag for signalling a received character
Dim Bc As Byte                                              'byte counter
Dim Buf As String * Cmaxchar                                'serial buffer
Dim D As Byte

'Buf = Space(20)
'unremark line above for the MID() function in the ISR
'we need to fill the buffer with spaces otherwise it will contain garbage

Print "Start"

On Urxc Rec_isr                                            'define serial receive ISR
Enable Urxc                                                'enable receive isr



Enable Interrupts                                          'enable interrupts to occur

Do
  If B = 1 Then                                            'we received something
    Disable Serial
    Print Buf                                              'print buffer
    Print Bc                                              'print character counter


    'now check for buffer full
    If Bc = Cmaxchar Then                                  'buffer full
        Buf = ""                                            'clear
        Bc = 0                                              'rest character counter
    End If

    Reset B                                                'reset receive flag
    Enable Serial
  End If
Loop

Rec_isr:
  Print "*"
  If Bc < Cmaxchar Then                                    'does it fit into the buffer?
    Incr Bc                                                'increase buffer counter


    If Udr = 13 Then                                      'return?
        Buf = Buf + Chr(0)
        Bc = Cmaxchar
    Else
        Buf = Buf + Chr(udr)                                'add to buffer
    End If


    ' Mid(buf , Bc , 1) = Udr
    'unremark line above and remark the line with Chr() to place
    'the character into a certain position
    'B = 1                                                    'set flag
  End If
  B = 1                                                    'set flag
Return

---

Hallo Frank !
Ich halte das für overkill und würd es nicht empfehlen.
die Config serialin=buffer .... - Angabe generiert bei einer ausreichenden Buffergröße eine tadellose, asynchrone Ringbuffer-routine. Mit dem "ischarwaiting" werden write- und read pointer verglichen, bei "=" wird null, sonst 1 zurückgegeben. dadurch kann ein folgendes inkey() auch für transparente daten (inclusive &00) verwendet werden.
Beim Beispiel ist das "print" in der ISR auch nur akzeptabel, wenn gleichzeitig config serialout= ( output ringbuffer) verwendet wird.
Blocking functions in einer ISR sind absolut "pfui"
Das Einzige, was man sich vorstellen könnte, wäre eine Terminator-definition, dh "On CR gosub .. " oder " on fill=70 gosub..." (overflow)
Weil aber der Buffer u. die Pointer eh definiert sind, kann man das auch selbst machen
(sich periodisch um seine Kinderchen zu kümmern, ist im Grunde die einzige Aufgabe der Haupt Do..LOOP Schleife)
*schnauf*

Da stimme ich dir schon voll zu Robert. Ich hatte das Beispiel nur mal rausgesucht um zu zeigen wie man RS232-Int mit Bascom Befehlen ausnutzt.
Um nur einen Buffer zu realisieren sind die internen Befehle sicher besser. Jedoch gibt es eventuell auch Aufgaben wo unmittelbar auf RS232 reagiert werden muss, dann kommt sowas in Betracht. Es ist dann auch leicht möglich ASM-Code im Interrupt zu nutzen, wenn man es optimieren will. Aber das wären wohl Ausnahmeanwendungen.

Klaro, spezial ist spezial, und je Event, desto ISR. Aber du siehst ja schon im Beispiel oben, wie anfällig das ist, daß sich ISR u. Non-ISR gegenseitig die Daten massakrieren. Verkaufen könnt man das nicht, außer, man hat eine gut Hotline eingerichtet.

Hallo Frank, hallo Robert,
danke für euren kleinen Austausch - dadurch habe ich wieder ein bisschen mehr gelernt. Noch eine kleine Frage: Mit dem "inkey" Befehl kann ich doch nur ein Zeichen auslesen - oder? Wie übertrage ich aber eine ganze Zahl wie z.B. 222 ? Da brauch ich doch den "Input" Befehl, wenn ich mich nicht irre.
Und noch ne Frage: Es ist doch sicher möglich mit den Mega32 mit mehr als 9600Baud zu übertragen? Kann ich außerdem den 8Mhz-Quartz auf der RNB-FRA gegen einen mit 16MHz austauschen? Macht das Sinn?
Grüße,

Dottore, die HW-Uart geht auch einiges schneller, das kann man beim Einzelfall dann austesten. Es taucht dann nur ein anderes Problem auf: Das Inter-character-delay (Zeit zwischen zwei Zeichen). Viel mehr als ein Bit hat man nicht. In dieser Zeit muß ein Zeichen irgendwie verarbeitet worden sein. Und das darf man bei hohen Baudraten nicht unterschätzen. Und Framing- und Overflow-Errors zu handeln, macht auch nicht so viel spaß, dann geht's nämlich Richtung Protokoll und data-link-layer.
Weise Aussage (stimmt immer): es kommt eben drauf an, was zu geschehen hat.

EDIT: die Sache mit input: Wenn diese Zahl dann auch mit <enter> abgeschlossen wird, bist du mit input gut dran. Wenn nicht--> dann mußt du dich selbst um das kümmern, leider,leider

Hi Robert,
vielen Dank erst einmal für deine Ausdauer bei diesem Thema. =D>
Wenn ich´s richtig verstehe, muss ich wohl ein wenig testen, ob ich die Daten vernünftig mit mehr als 9600Baud übertragen kann. Das ist dann meine Aufgabe für dieses Wochenende. Wenn ich dann mit meiner Laserkiste soweit bin, werde ich als Dankeschön mal ein paar Bildchen von den "Laser-Zuckeleien" posten. kann aber noch ein paar Wochen dauern, da ich jetzt gerade erst mal mit der Hardware soweit bin (z.Zt 6 Laser drin (3grün, 3rot, alle gemischt zu gelb - 6 Schrittmotoren als xy-Pärchen und und und... Scanner sind mir im Augenblick noch zu teuer).
Schönes Wochenende wünscht:

Hallo alle Interessierten!
habe das Wochenende genutzt und die beiden Varianten, die RS232 interruptmäßig abzufragen, getestet.
Variante 1:
config serialin=buffered, size=nn
mach BasCom den Input mit Interrupt, mit der Frage
if ischarwaiting() = 1 then
databyte = inkey()
end if
Geht ganz gut, aber man muss ja dauernd die if...then Schleife durchlaufen um zu erfahren, ob was angekommen ist.

Daher bevorzuge ich:
Dim Gerät as Byte
Enable Interrupts
Enable Int0 (Pin0, Port D für RS232)
On Int0 Subroutine
End

Sub Subroutine()
gerät = inkey()
if gerät=A then
for i=1 to AnzahlBytes
Nachricht=inkey()
wort=wort & Nachricht
next
else
schicke weiter zum Gerät B
end if
Return
end

Damit kann der Controller in jedem beliebigen Unterprogramm sein. Wenn was ankommt wird sofort unterbrochen und die neue Anweisung ausgeführt.
Klappt bei mir prima.
Viele Grüße, :-b

Noch was:
Gibts in Bascom einen Befehl so wie Mscomm.input in VB, mit dem man direkt alles auslesen kann, oder muss mann immer Byte für Byte auslesen?

Außerdem: Habe höhere Taktraten (bisher bis 57500Baud) ausgetestet,
funktionierte tadellos, sogar ohne Buffer.

Grüße,

Zitat:

---

Zitat von Dr.U.Bianchi

Daher bevorzuge ich:

Code:

---


Dim Gerät as Byte
Enable Interrupts
Enable Int0 (Pin0, Port D für RS232)
On Int0 Subroutine
End

Sub Subroutine()
  gerät = inkey()
  if gerät=A then
    for i=1 to AnzahlBytes
      Nachricht=inkey()
      wort=wort & Nachricht
    next
  else
    schicke weiter zum Gerät B
  end if
Return

End

---

---

Ähm, da sind einige Sache, die ich nicht kapier:
1. Die Variable Gerät wird als Byte definiert und dann mit "A" verglichen?
Bei mir gibts das ein "Source variable doesnt match the target variable"
2. Enable Int0 (Pin0, Port D für RS232) hier kann doch was nicht stimmen oder? Was muss in die Klammer? Nur "Pin0" wahrscheinlich oder? Also wenn ich das richtig verstehe muss da praktisch der des Eingangs des RS232 genommen werden und wenn der sich ändert with Subroutine aufgerufen, seh ich das richtig?
3. Muss die Variable AnzahlBytes auf z.B. 8 von mir festgelegt werden? Schon oder?
4. Was soll das eigenlich mit dem Gerät? Gerät ist doch dann das erste empfangene Zeichen vom RS232 oder?

Zitat:

---

Hallo Frank !
Ich halte das für overkill und würd es nicht empfehlen.
die Config serialin=buffer .... - Angabe generiert bei einer ausreichenden Buffergröße eine tadellose, asynchrone Ringbuffer-routine. Mit dem "ischarwaiting" werden write- und read pointer verglichen, bei "=" wird null, sonst 1 zurückgegeben. dadurch kann ein folgendes inkey() auch für transparente daten (inclusive &00) verwendet werden.
Beim Beispiel ist das "print" in der ISR auch nur akzeptabel, wenn gleichzeitig config serialout= ( output ringbuffer) verwendet wird.
Blocking functions in einer ISR sind absolut "pfui"
Das Einzige, was man sich vorstellen könnte, wäre eine Terminator-definition, dh "On CR gosub .. " oder " on fill=70 gosub..." (overflow)
Weil aber der Buffer u. die Pointer eh definiert sind, kann man das auch selbst machen
(sich periodisch um seine Kinderchen zu kümmern, ist im Grunde die einzige Aufgabe der Haupt Do..LOOP Schleife)
*schnauf*

---

Is des schlimm wenn ich davon kein Wort verstehe??? :-s

mfg
jagdfalke

Zitat:

---

Is des schlimm wenn ich davon kein Wort verstehe???

---

überhaupt nicht schlimm, es sei denn, du bist Programmierer, dann schon.

Nee bin ich zum Glück nicht, jedenfalls wenn du professioneller Programmierer meinst.

Kannst du mir dann erklären was das mit dem "Gerät" soll?

Zitat:

---

Zitat von jagdfalke

Nee bin ich zum Glück nicht, ...

---

Sei froh :mrgreen:

"Gerät":
1 du hast recht, soll wohl sein "A", dann aber wohl "Gerät = 65", sonst ist der BasCom stinkesauer
2 der ganze Klammerausdruck ist ein Kommentar. und ich denk, das siehst du völlig richtig
3 keine Ahnung, wo das herkommen kann, vielleicht eine Konstante
4

Ich versteh das Ganze so, daß das erste Byte von der RS232 eine Geräteadresse darstellt ("A")
Ist es nun wirklich ein "A", liest er die nächsten "Anzahlbytes", weil sie sind für dieses Programm/AVR bestimmt
Wenn nicht, gehört die Nachricht ignoriert und weitergeleitet zum nächsten AVR

Du hast aber recht, so wie es konkret geschrieben ist, funktioniert das in der Realität nicht.

Sind wir jetzt wieder Freunde ? :-({|=

Zitat:

---

Sind wir jetzt wieder Freunde ?

---

Waren wir je Feinde? Klang meine Frage irgendwie provokativ? Wenn ja möchte ich mich in aller Form entschuldigen.
Hast du denn ne gute Lösung für ne Kommunikation zwischen PC und AVR parat? Am Besten doch ein RS232-Interrupt oder? Sonst kann ja der Controller nix mehr machen, wenn er ständig auf einen Input wartet.

mfg
jagdfalke

Zitat:

---

Zitat von jagdfalke

Am Besten doch ein RS232-Interrupt oder? Sonst kann ja der Controller nix mehr machen, wenn er ständig auf einen Input wartet.

---

Ja, klar. Der Interrupt macht das Lesen der Bytes (sind ja meist mehrere) völlig im Hintergrund. Erst wenn die Meldung / Kommando komplett ist,
wird das Hauptprogramm in Anspruch genommen. In der Zwischenzeit macht es irgendwas anderes (Schrittmotoren tickern oder sowas)
d.h natürlich, über die RS232 müssen richtige Messages kommen, mit Header und Längenangabe, eventuell + Checksum
Ein bißchen Protokoll halt.
PC muß aber auch mitspielen, klaro.

Zitat:

---

mit Header und Längenangabe, eventuell + Checksum

---

Ähm, naja, wie gesagt ich bin ja kein professioneller Programmierer. Kannst du des genauer erklären? Oder vielleicht ein kurzes code beispiel oder vielleicht n' Tut wo sowas erklärt wird? Es fängt ja schon bei dem Wort "checksum" an, dass ich net check, was des bedeutet.

mfg
jagdfalke

Hallo Jagdfalke,
entschuldige, dass ich nicht "richtigen und lauffähigen" Code geschrieben habe und mich jetzt erst äußere (z.Zt. sehr viel zu tun - wenig Zeit für Privates) . Natürlich ist mit "A" 65 gemeint - war so einfacher zu verstehen. Das in der Klammer bei "enable int0" ist nur Kommentar, wie PicNic schon richtig angemerkt hat - genau wie "schicke weiter zum Gerät B". Es sollte nur klar machen, dass ich den Interrupt bevorzuge anstatt "ischarwaiting" und die Struktur beschreiben.
Danke PicNic für die Beantwotung des Beitrages von Jagdfalke!
=D>
Grüße,

ich glaube ich verstehe: der obige code war ein beispiel für die kommunikation mehrerer Geräte über RS232, richtig? Als erstes wird ein Buchstabe bzw eine Zahl übermittelt um ein bestimmtes Gerät anzusprechen (ähnlich wie die Adresse bei I2C oder?). Dann kommen die Kommandos nach.

@Dr.U.Bianchi:
Hast du die Kommunikation so protokollartig gestaltet wie PicNick es beschrieben hat (Checksum, Längenangabe, Header) ? Ist das wirklich nötig? Ok Längenangabe seh ich ja noch ein, aber checksum? Und was bitte ist mit Header gemeint?

mfg
jagdfalke

Es geht um die Sicherstellung, daß alle Beteiligten, auch wenn einer davon irgendwie ins Schleudern gekommen ist, zumindest bei der nächsten Message sicher sein kann, wo sie anfängt und wo sie aufhört. Das ist ja bei binären Daten auf einer UART nicht selbstverständlich. Der Header bei einer Message ist ein bißchen sowas wie der I2C Start, wo jeder weiß, jetzt kommt wieder eine Device-Adresse.
Die "Checksum" ist eine Kontrollzahl, die der Sender erzeugt und der Empfänger nachrechnet. (CRC, BCC, etc.) Paßt das nicht, schmeißt der Empfänger die gesamte Message weg und verarbeitet sie nicht.

Wie soll so eine kontrollzahl denn generiert werden? Ich könnte mir vorstellen alle ASCII-Codes zu addieren. Aber dadurch stellt man ja nicht 100%ig fest, dass es sich jeweils um den selben String handelt, oder?

Du hast recht, 100% sicher ist nix
Jedes Kontrollverfahren bringt nur eine gewisse Wahrscheinlichkeit, daß die Daten stimmen. Im "richtigen Leben" wird deshalb gerne CRC-16 verwendet, das ist eine 16-Bit Prüfzahl, da klappt das schon extrem sicher. Ist aber alles eine Wissenschaft.
Das von dies genannte Addieren gibt es, das findest du z.B. in der HEX-File
fur den AVR.
Beim BCC (Rs485) werden die Bytes nacheinander mit XOR verknüpft.
Die Sicherheit hängt auch davon ab, wie lange diese Messages sind.

Hallo Jagdfalke,
bisher schicke ich einfach nur den Gerätecode als erstes und dann die Daten, die bei mir aber immer die gleiche "Päckchengröße" haben. Einen "Header" oder eine Prüfsumme habe ich bisher noch nicht eingebaut - bin dabei aber noch im Entwicklungsstadium.
Zur Zeit denke ich noch über einen Kommandosatz nach (so ähnlich wie bei der RN-Motor) und außerdem über die Übermittlung von ganzen Abläufen, bzw. Figuren für die Steppermotoren.
Grüße, :-b

Aja, cool! gleiche Päckchengröße = gleiche Anzahl an übermittelten Zeichen oder?

Genau so ist es gemeint!