mehrere MC seriell über Datenbus verbinden (1Draht)

[Peter D. (peda)]

Manchmal will man mehrere MC verbinden, ohne großen Aufwand.

Das hier ist ein sehr einfacher Bus, sogar ein ATtiny13 kann ihn 
implementieren.
Der CPU-Takt muß auch nicht quarzstabil sein, ein Fehler von +-15% ist 
zulässig.

Ich nenne ihn 124Bus, weil die Pulse 1, 2 oder 4 Zeiten lang sind.
Die Pulse haben folgende Bedeutung:
1 * T: 0-Bit
2 * T: 1-Bit
4 * T: Synchronisationsbit

Es wird nur ein Pin benötigt. Man kann aber auch 2 Pins nehmen, wenn man 
z.B. die MCs über Optokoppler galvanisch trennen will.

Es ist ein Single-Master Bus. Nimmt man das erste Byte als Adresse, 
können 256 Slaves angeschlossen werden.

Empfang und Senden erfolgen bequem im Hintergrund über Interrupts. Das 
Main muß also nur die Empfangspakete auswerten und die Sendepakete in 
den Puffer stellen.

Die Bitrate hängt davon ab, wieviel Zeit andere Interrupts benötigen.
Das Beispiel benutzt 10kHz bei 8MHz CPU-Takt.
50kHz habe ich auch erfolgreich getestet, aber für andere Interrupts ist 
dann kaum Zeit übrig.

Die Beispiele sind für den AVR geschrieben, es gehen aber auch beliebig 
andere MCs.

Zum Test wurde ein STK500 mit 3 AVRs verwendet.
Für den ATmega48 gibt es noch ein 2.Beispiel, wo der Timer für den 
124Bus noch gleichzeitig eine PWM macht.
Beim ATtiny261 habe ich auch eine Fallgrube entdeckt.


Peter Dannegger

[sum (Gast)]

Hallo Peter,

danke für das Teilen Deines Codes. Ich finde Deine Idee, das mit dem PWM 
Modus zu "modulieren" sehr interessant. Vielleicht sollte ich meinen Bus 
(Autopilot, siehe suart) auch mal darauf umstellen. Das spart die 
Hälfte aller Interrupts ;-) weil man nicht auschalten braucht...

Schöne Grüße,
 Clemens

[chris (Gast)]

Hallo Peter,

mit der Kommunikation über einen Pin habe ich mich auch schon 
beschäftigt:

Beitrag "Re: Unidirektionale Datenübertragung, 1 Leitung, kein Quarz"

Gruß,
chris

[Knut B. (Firma: TravelRec.) (travelrec)]

Peter Dannegger schrieb:
> Ich nenne ihn 124Bus, weil die Pulse 1, 2 oder 4 Zeiten lang sind.
> Die Pulse haben folgende Bedeutung:
> 1 * T: 0-Bit
> 2 * T: 1-Bit
> 4 * T: Synchronisationsbit

Habe so etwas Ähnliches auch als Debugschnittstelle laufen, ist aber 
eher ein 123-Bus, da das Sync-Bit 3 0-Bit-Längen entspricht ;-)

[Peter D. (peda)]

Knut Ballhause schrieb:
> Habe so etwas Ähnliches auch als Debugschnittstelle laufen, ist aber
> eher ein 123-Bus, da das Sync-Bit 3 0-Bit-Längen entspricht ;-)

Das verringert aber die erlaubte Toleranz der Taktfrequenz.

Ich habe deshalb auch die Schwelle auf die relative Mitte (1,4) gelegt 
und nicht auf die arithmetische Mitte.


Peter

[chris (Gast)]

Bei meinem BUS-Protokoll war das Entwicklungsziel eine möglichst 
schnelle Datenübertragung zu realisieren. Ursprünglich wollte ich 
1Mbit/s erreichen.
Ich habe ein Ping-Pong-Verfahren zwischen den zwei Prozessoren 
implementiert: Es wird ein Byte vom Master zum Slave gesendet und als 
Antwort sendet der Slave ein Byte zum Master. Damit hat man automatisch 
eine bidirektionale Kommunikation realisert.
Die Geschwindigkeit für ein PING-PONG lag schließlich bei 10-20KHz ( bei 
16 effektiv übertragenen Bits also max ca. 360KBit/s).

Welche Datenrate wird bei euren Verfahren erreicht?

[Blackbird (Gast)]

So ähnlich ist der Sony Control A1 Bus  (oder (S-Link) aufgebaut:
600µs, 1200µs und 2400µs Pasuse auf einer 1-Draht-Leitung.

Wer also Sony-Audio-Geräte mit Control- A1-Bus hat, kann damit einen 
Konverter zum PC bauen und seine Geräte per PC/Notebook steuern, 
abfragen, usw.


Blackbird

[Manuel (Gast)]

Hallo Peter!

Ich verwende deinen 124BUS und habe eine Frage.

wenn ich rx_init() ausführe, wird doch der nächste Timerinterrupt auf 
4*T gesetzt ( Also auf Startbit )

Wenn man nun in dem Timerinterrupt nachschaut, kann man erkennen, dass 
er in die Abfrage " if( rx_idx != DATA_SIZE * 8 )  // receive successful 
" hineingeht, und er somit meint, die Übertragung ist schon fertig.

Gehe ich recht in der Annahme, oder habe ich einen kleinen Kniff 
übersehen?
Aufgrund dessen dass der Ruhepegel bei dir immer + ist, wird ja nur das 
Stopbit ausgeführt, und das Startbit existiert ja eigentlich nicht, 
deshalb könnte ich das nicht auswirken, stimmt das?

Danke

Lg
Manuel

[Peter D. (peda)]

Manuel schrieb:
> Wenn man nun in dem Timerinterrupt nachschaut, kann man erkennen, dass
> er in die Abfrage " if( rx_idx != DATA_SIZE * 8 )  // receive successful
> " hineingeht, und er somit meint, die Übertragung ist schon fertig.

Nur wenn vorher genau die richtige Anzahl an Datenbits gelesen wurde, 
bedeutet das Sync-Bit auch das Ende des Empfangs.
Ansonsten ist es eben nur ein Sync-Bit und setzt den Bitzähler zurück.


Peter

[Manuel (Gast)]

Hallo!

Ok das heißt also, egal ob ein Startbit kommt oder ein Stopbit, das ist 
erstmal egal.

Es würde rein theoretisch auch ohne gehen richtig?

Ich brauche nämlich zwecks der Datenübertragung per Optokoppler ein low 
als Ruhezustand, dabei habe ich im Timer Interrupt einfach eine Abfrage 
auf Low gemacht, passt oder?

Lg
Manuel

[Manuel (Gast)]

Oder wäre es besser einfach den Optokoppler gegen + als gegen Masse zu 
schalten?

Ansonsten ist ja einiges am Programm zu ändern, dass der Ruhepegel 0 
ist.

Was meinst du ist besser ?

Danke
Lg
Manuel

[Peter D. (peda)]

Manuel schrieb:
> Oder wäre es besser einfach den Optokoppler gegen + als gegen Masse zu
> schalten?

Ja, dem Optokopller dürfte es egal sein.
Allerdings solltest Du bei einem Optokoppler 2 Leitungen benutzen, da 
der ja nicht bidirektional ist. Und dann ist der Ruhepegel egal, man muß 
nicht mehr zwischen Senden und Empfang umschalten.


Peter

[Manuel (Gast)]

Hallo!

Ja ich verwende natürlich zwei!

Naja der Ruhepegel ist insofern nicht egal, als dass ich mehrere 
Optokoppler parallel betreibe, und die somit im Ruhezustand immer Strom 
verbrauchen würden, würde bei einigen Parallel schon einiges ergeben, 
und das muss ja nicht sein.

Ich habe jetzt folgendes geändert:

Statt Set on Compare hab ich überall Clear on Compare.
Danach die Abfrage, dass er solange ein High ist noch nicht die 
Interrupt deaktiviert.

Zusätzlich da ich ja jetzt 2 Pins verwende, habe ich die Abfrage bei 
tx_init auf das warten des Pins bis es high ist weggelassen.

Und ich habe eine neue variable eingeführt, um zu erkennen, ob der Timer 
Interrupt fürs Senden oder fürs Empfangen ist ( War ja vorher direkt per 
DATA_DDR abgefragt)

Hab ich das einigermaßen richtig gemacht?

Danke dir!
Lg
Manuel

[Manuel (Gast)]

Hallo nochmal!

Kann es sein, dass die Slaves es nicht mögen, wenn der Master zu schnell 
hintereinander sendet? Es kommen immer viele Timeouts zustande, wenn ich 
den Master direkt nach dem empfangen & abarbeiten senden lasse, wenn ich 
allerdings 100ms Abstand lasse, geht es besser.

Trotz dessen gibt es noch häufig Time Outs, wie ist das zu erklären?

Danke!

Lg
Manuel

[Manuel (Gast)]

Hallo nochmal!

Ich habe mittlerweile herausgefunden, dass die Slaves immer senden ( 
also antworten )

Der Master aber auf einmal ein Timeout einleitet. Woran das liegt ist 
mir schleierhaft, das Programm ist genau deines!

Hast du eine Idee wie das sein kann ?

Lg
Manuel

[Peter D. (peda)]

Vielleicht braucht eine andere Routine sehr viel Zeit oder blockiert die 
Interrupts. Geh mal mit der Datenrate runter.

Oder ist vielleicht bei einem das Cal-Byte zerstört und der liegt total 
daneben. Laß mal auf beiden eine 1s Blink-LED laufen und prüfe mit ner 
Stoppuhr. Oder setze beim Master die CLK-OUT Fuse und takte damit den 
Slave.

Wenn nichts hilft, poste mal den kompletten Code von Master/Slave (als 
ZIP).


Peter

[Manuel (Gast)]

Hallo!

also nachdem ich in den PCINT1 Interrupt Aufruf ein "ISR_NOBLOCK" 
geschrieben habe, funktioniert alles einwandfrei!

Woran kann das liegen, ein Interrupt kann nur durch ein 4T ausgeführt 
werden, kommt aber nie vor?

Komisch ist auch, wenn ich den Code lasse wie bei dir, aAntworten die 
Slaves schneller als wenn ich den Code invertiere ( mit Clear on Compare 
und so ) aber ich seh da keinen logischen Grund außer, dass das 
Synchronisationsbit am Schluss statt am Anfang eines Frames kommt.

Lg
Manuel

[Peter D. (peda)]

Manuel schrieb:
> Woran kann das liegen

Was erwartest Du, ohne den kompletten Code zu zeigen?
Im Hellseherlehrgang habe ich ne 6 gekriegt.


Peter

[Manuel (Gast)]

Hallo!

Tut mir Leid.

Habs angehängt, die Änderungen sollten für dich eh gut sichtbar sein!

Lg
Manuel

[Peter D. (peda)]

Manuel schrieb:
> also nachdem ich in den PCINT1 Interrupt Aufruf ein "ISR_NOBLOCK"
> geschrieben habe, funktioniert alles einwandfrei!

Ich habs ja auch so in mein Beispiel geschrieben. Die Datenrate ist 
recht hoch, da können andere Interrupts zu lang sein. Brauchst Du 
wirlich diese hohe Datenrate?


Peter

[Peter D. (peda)]

Manuel schrieb:
> Habs angehängt, die Änderungen sollten für dich eh gut sichtbar sein!

Man postet immer ein compilierbares File und keine Schnipselchen!
Welches Target überhaupt?

    TCCR0A = 1<<COM0B1;// | 1<<COM0B0;             // set on compare
///////////////////////////////////////////////////////////////////////////////////////////
  if( DATA_PIN == 1 )
      return;

Dann hast Du nur eine Sache geändert, kann also nicht gehen.
Nimm besser erstmal das Beispiel mit 2 Timern, die sind etwas einfacher 
zu verstehen.
Und setze die Datenrate runter.



Peter

[Manuel (Gast)]

Hallo!

Ja ich weiß. Es ist für einen AtMega644

Ja die hohe Datenrate brauche ich.

auch wenn ich

if( DATA_PIN == 0 )

mache, funktioniert es kein Stück besser.
Das meintest du doch hoffentlich oder ?

Aber könntest du mir noch bitte sagen, wieso ein anderer Interrupt 
dazwischenfunken sollte ? Es sind doch keine anderen aktiv, lediglich 
der PCINT und der für 2.8*T, selbiger kann nicht auslösen. Und den PCINT 
wollen wir doch.

Danke für deine Hilfe!

Lg
Manuel

[Peter D. (peda)]

Manuel schrieb:
> Ja ich weiß. Es ist für einen AtMega644

Na dann kannst Du doch 2 getrennte Compare eines Timers benutzen und 
mußt nicht zwischendurch umschalten (Slave1.c).


Manuel schrieb:
> Ja die hohe Datenrate brauche ich.

Welche und bei welcher Frequenz?


Peter

[Peter D. (peda)]

Du mußt aufhören, Programme als großen monolithischen Block zu 
betrachten.
Wenn etwas nicht funktioniert, mußt Du debuggen. Dazu muß man das 
Programm in einzelne Teile zerlegen und diese testen. Z.B. beide 
Datenrichtungen getrennt testen. Auch kann man erstmal kritische Timings 
runter setzen.

Die Routine (slave1a.c) mit nur einem Compareregister ist durch die 
Umschaltung komplexer und benötigt auch mehr CPU-Zeit. Sie sollte man 
wirklich nur auf dem ATtiny13 einsetzen, wenn der Timer noch anderes 
machen soll.
Beim ATmega644 ist dieser Geiz mit Timern aber nicht nötig.


Peter

[Manuel (Gast)]

Hallo nochmal Peter!

Also auf dem Master, dem AtMega644 verwende ich ja auch deine Master 
Software mit den getrennten Timer Compare.

Trotzdem funktioniert es ausschließlich einwandfrei ( Ohne oft einen 
TimeOut zu bekommen ) Wenn ich "ISR_NOBLOCK" einfüge.

ISR_NOBLOCK heißt ja, dass der Interrupt durch einen anderen Interrupt 
unterbrochen werden darf, da direkt am start ein "sei()" eingefügt wird.

Das heißt also entweder COMPA oder COMPB wird ausgeführt.

Da beim empfangen der COMPA nicht verwendet wird, existieren also nur 
der PCINT und COMPB, COMPB wird allerdings nur beim Synchronisationsbit 
ausgeführt. Deshalb sollte der COMPB den PCINT ja überhaupt nicht stören 
und es sollte keinen Unterschied machen, ob ich "ISR_NOBLOCK" beim PCINT 
Interrupt hinzufüge oder nicht.

Bin ich auf dem Holzweg?

Liebe Grüße
Manuel

[Manuel (Gast)]

Hallo Peter !

Ich habe den Fehler herausgefunden, wie ich es lösen kann zwar noch 
nicht, aber ich möchte dir mal den Fehler erklären.

Undzwar ist es die zeit zwischen PCINT aufruf und dem TCNT0=0.

Wenn dazwischen hier ein Interrupt aufgerufen wird, der eigentlich das 
Synchronisationsbit detektieren soll, stimmt die Zählung nichtmehr. 
Nachdem im PCINT Interrupt rx_idx auf 0 gesetzt wurde, also als start, 
geht gleich darauf der COMPB Interrupt an, und setzt rx_idx wieder auf 
255, womit beim nächsten Aufruf von PCINT wieder bei 0 angefangen wird, 
und somit alles falsch ist.

Kannst du verstehen was ich meine?
Hast du eventuell eine Idee selbiges zu umgehen?

Lg
Manuel

[Peter D. (peda)]

Manuel schrieb:
> Kannst du verstehen was ich meine?

Nein.

Nochmal, ich weiß nicht, welchen Code auf welchen AVRs Du benutzt.
Ich kann nicht hellsehen.

Und hör auf, Deine Codeänderungen beschreiben zu wollen, damit kann 
keiner was anfangen.

Wenn eine Änderung eine Wirkung hat, die Dir unklar ist, dann mach 2 
komplette Projekte, einmal mit und einmal ohne die Änderung.
Oder ein Projekt, wo die Änderung mit einem Define umgeschaltet wird.

Und dann kannst Du auch darauf Bezug nehmen (folgende Änderung in File 
x.c, Zeile y habe ich gemacht ...).


Peter

P.S.:
Target, Taktfrequenz, Compilerversion, Compileroptionen, 
Anschlußbelegung usw. gehören selbstverständlich zu den Angaben, die im 
Projekt enthalten sein müssen.

[Manuel (Gast)]

Hallo nochmal!

Ich habe mich echt bemüht dir zu erklären wo der Fehler liegt.

Ich kann dir auch sagen, wieso der Fehler bei dir nie aufgetreten ist, 
aber bei mir schon, dennoch hilft es nichts wenn ich den kompletten Code 
einfüge. Aber ich werde es einmal Versuchen.

Original:

ISR( TIMER0_COMPB_vect )                // sync received
{ if( rx_idx == DATA_SIZE * 8)          // receive successful
  {  PCMSK1 = 0;      // disable further receive
  }
  rx_idx = 255;                         // detect sync transition
  if( rx_timeout ){            // timeout answer from slave
    rx_timeout--;
    TCNT0 = 0;
  }
}

Testcode:

ISR( TIMER0_COMPB_vect )                               
{ if( rx_idx == DATA_SIZE * 8 || rx_idx == DATA_SIZE * 8 - 1) 
  {  PCMSK1 = 0;                      
  }
  rx_idx = 255;                       
  if( rx_timeout ){            
    rx_timeout--;
    TCNT0 = 0;
  }
}

So beim Testcode schaltet er ebenfalls ab, wenn einmal eine Flanke 
gefehlt hat ( Eben wenn besagter Fehler auftritt ), dann tritt nie ein 
Timeout auf!

Ich habe es mit dem Oszilloskop überprüft ob es tatsächlich daran liegt, 
und es liegt daran.

In der Zeit zwichhen dem

ISR( PCINT1_vect )

 Aufruf und

TCNT0 = 0;

 kommmt ein Timer0 Compare B Interrupt und setzt rx_idx NACH BEDINGUNG 
des Pin Change Interrupts fälschlicherweiße auf 255.

Erklärung warum bei dir der Fehler nicht auftritt:
Bei deinen Slaves kommt das Synchronisationsbit am Anfang, das heißt 
zuerst 4T und danach die Daten, bei mir ist es Programmtechnisch 
umgekehrt, zuerst die Daten dann das Synchronisationsbit, aus diesem 
Grund kann der Fehler bei dir nicht auftreten, bei mir aber schon.

Erklärung warum es bei hinzufügen von

ISR_NOBLOCK

 bei der

ISR ( PCINT1_vect )

 Routine zu keinem Fehler kommt:
Nachdem der Compiler ja als bald als möglich den Interrupt mit

sei()

 wieder frei gibt, hat der

ISR( TIMER0_COMPB_vect )

 Interrupt in der kritischen Phase eine Eingriffsmöglichkeit, und somit 
kann fast kein Fehler mehr auftreten, der Aufgrund der Wartezeit vom 
Compare B Interupt auftritt.

Peter, ich hoffe, dass ich es ausführlich, verständlich und genau 
erklärt habe. Ich weiß, dass ich hier nichts von Compilerversion, Target 
etc. geschrieben habe, da es in diesem Fall keine Auswirkung hat. Ich 
hoffe, dass du damit einverstanden bist, wenn nicht, bitte sag es mir 
nochmal ich werde versuchen die Erklärung zu verbessern, auch wenn ich 
momentan keine Ahnung habe wie ich es noch verbessern sollte.

Dankesehr Peter!

Lg
Manuel

[Peter D. (peda)]

Manuel schrieb:
> Bei deinen Slaves kommt das Synchronisationsbit am Anfang, das heißt
> zuerst 4T und danach die Daten, bei mir ist es Programmtechnisch
> umgekehrt, zuerst die Daten dann das Synchronisationsbit,

Warum sagst Du denn nicht gleich, daß Du am Master-Code rumgefriemelt 
hast?
Das kann ja nicht funktionieren!

Du brauchst zu Anfang eine Flanke und die ist eben das Ende des 
Sync-Bits und der Start des 1.Datenbits.
Ich kann Dir versichern, ich habe mir dabei was gedacht, es so zu machen 
und nicht anders.

Du kannst Dir natürlich ein anderes Protokoll ausdenken, aber dann 
kannst Du meinen Code nicht mehr verwenden.


Peter

[Manuel (Gast)]

Hallo Peter!

Tut mir Leid, ich habe es so verstanden, dass es egal ist, ob das 
Synchronisationsbit am Anfang oder am Ende kommt. Danke dass du mir das 
jetzt erklärt hast.

Im Anhang befindet sich meine Testdatei.

Ziel ist ein Attiny13, selbiger soll nur Aussenden.
Ich verwende AVR Studio mit AVR-GCC die neueste Version.

Da ich Sendeleitung und Empfangsleitung getrennt habe, gibt es ein 
kleines Problem und zwar hier:

void tx_data( uint8_t addr, uint8_t data )
{
  PCMSK = 0;            // disable receive
  DATA_DDR = 0;                                 // input
  DATA = 1;                                     // pullup on
  while( DATA_PIN == 0 );                       // wait until pin high
...

Du setzt hier den Data Pin auf Eingang, legst einen Pull Up auf High und 
wartest bis er auf 0 gezogen wird.

Die Frage ist nun, wie wird er jetzt auf 0 gezogen?

Ich brauche ja nicht auf Eingang schalten und warten, da ich diesen PIN 
ja sowieso nur als Ausgang verwende, aber ein einfaches umschreiben auf:

void tx_data( uint8_t addr, uint8_t data )
{ 
  PCMSK = 0;
  DATA_DDR =1;
  DATA = 1;
...

funktioniert ja nicht.

Kannst du mir eventuell erklären wieso es auf 0 gezogen werden soll, 
bzw. wie ich es in meinem Fall umschreiben kann, dass es auch 
funktioniert wenn ich einen Optokoppler am Ausgang gegen Masse habe?

Ich sitze wirklich nun schon seit ca. 12 Uhr da und versuche es. Es tut 
mir Leid, dass ich nicht der Profi Programmierer bin, und ein wenig 
Hilfe brauche, ich hoffe du kannst es verstehen, und siehst auch, dass 
ich mich wirklich bemühe es selbst zu schaffen.

Großen Dank Peter!

Lg
Manuel

[Peter D. (peda)]

Wenn der ATtiny13 von sich aus sendet, ist er natürlich der Master und 
der andere der Slave, er muß ständig empfangsbereit sein.
Du kannst den Sendeausgang dann ständig eingeschaltet lassen.
Ein Timeout muß dann länger sein, als der Master zwischen dem Senden 
maximal Pause macht.

Wenn Du Modifikationen vornimmst, ist es ratsam, mit einem Oszi das 
Signal anzusehen.


Peter

[Manuel (Gast)]

Peter Dannegger schrieb:
> Wenn der ATtiny13 von sich aus sendet, ist er natürlich der Master und
> der andere der Slave, er muß ständig empfangsbereit sein.
> Du kannst den Sendeausgang dann ständig eingeschaltet lassen.
> Ein Timeout muß dann länger sein, als der Master zwischen dem Senden
> maximal Pause macht.
>
> Wenn Du Modifikationen vornimmst, ist es ratsam, mit einem Oszi das
> Signal anzusehen.
>
>
> Peter

Hallo!

Ja das ist klar, ich habe das Programm geschrieben, da mir lediglich der 
Sendevorgang Sorge bereitet! Momentan sende ich nur mit dem Attiny13 und 
schaue mir den Ausgang am Oszilloskop an.

Wenn ich auf das warten bis der Pin "0" wird verzichte, dann 
funktioniert es nur jedes zweite mal.

Also 1. Sekunde richtig, 2. Sekunde falsch.

Falsch äußert sich dahingehend, dass das Synchronisationsbit nicht 
gesendet wird, und auch das letzte Bit nicht gesendet wird.

Beim dritten mal passt es wieder, beim 4. nicht,...

Ich kann es mir nicht so recht erklären, wieso es jedes zweite Mal 
funktioniert, da hier ja nirgends etwas umgeschalten wird, nach jedem 
mal senden, zumindest sehe ich das so.

So leid es mir tut, dich nochmals Fragen zu müssen, ob du eventuell 
einen Tipp hast, wieso selbiges Phänomen auftritt.

Danke
Lg
Manuel

[Peter D. (peda)]

Ein Sync-Bit ist per meiner Definition >=4*T, nach oben hin gibt es 
keine Grenze.
Also wenn eine Sekunde lang nichts gesendet wird, ist das ein astreines 
Sync.

Ein zusätzliches Sync schadet aber nicht, für die Anzahl gibt es auch 
keine obere Grenze.


Peter

[Manuel (Gast)]

Folgende Änderung:

void tx_data( uint8_t addr, uint8_t data )
{
  PCMSK = 0;            // disable receive
  DATA_DDR = 1;                                 // input
  DATA = 1;                                     // pullup on
  //while( DATA_PIN == 0 );                       // wait until pin high

  OCR0B = TCNT0 + (uint16_t)(BIT_TIME * 4 + 0.5);      // sync: 4T
  TCCR0A = 1<<COM0B0;                           // toggle on compare
  //DATA_DDR = 1;                                 // tx output on
  TIFR0 = 1<<OCF0B;                             // clear earlier interrupts
  DATA_INT = 1;                                 // enable tx interrupt
  volatil(tx_idx) = 0;                          // point to first bit
  volatil(tx_buff[0]) = addr;
  volatil(tx_buff[1]) = data;
  while( DATA_INT );                            // until tx done
}

führt zum "Erfolg" im Anhang.

Ausgesendet soll zweimal eine "1" werden.

Beim 1. Bild passt alles einwandfrei
beim 2. Bild fehlt Synchronisationsbit und letztes Bit.

Lg
Manuel

[Manuel (Gast)]

Hallo Peter!

ICh sollte mich schämen, hab ich doch glatt etwas vergessen zu ändern:

ISR( TIM0_COMPB_vect, ISR_NOBLOCK )           // Transmit/Sync interrupt
{
  uint8_t *dp;          // locals for faster access

  if( DATA_DDR )
  {
    if( tx_idx < DATA_SIZE * 8 )
  {
      OCR0B += (uint16_t)(BIT_TIME + 0.5);      // 0-bit: 1T
      dp = &tx_buff[tx_idx++ / 8];              // get byte address
      if( *dp & 0x80 )                          // msb first
        OCR0B += (uint16_t)(BIT_TIME + 0.5);    // 1-bit: 2T
      *dp <<= 1;                                // shift bits
      return;
    }
    OCR0B += (uint16_t)(BIT_TIME * 4 + 0.5);    // Sync:  4T
    TCCR0A = 1<<COM0B1 | 1<<COM0B0;             // set on compare
    if( DATA_PIN == 1 )
      return;
  }

Das:

TCCR0A = 1<<COM0B1 | 1<<COM0B0;             // set on compare

war zuvor:

TCCR0A = 1<<COM0A1 | 1<<COM0A0;             // set on compare

Dummer dummer Fehler :( Tut mir leid.

hab jetzt ein Oszi Bild in den Anhang gestellt.

Das passt nun so richtig, wie du den 124Bus Designed hast richtig?

Lg
Manuel

[H.Joachim S. (crazyhorse)]

Hat schon mal einer einen slave auf dem Tiny25 gebastelt?

[H.Joachim S. (crazyhorse)]

Mit Timer0 (OC0A, PB0 und PCINT0) klappt es wunderbar.
Nur mit dem Timer1 bekomme ich es nicht hin.
Platinen schon fertig, der Bus müsste auf PB4/OC1B/PCINT4.
Nach wie vor läuft der Timer1 in der Simualtion AVR-Studio 4.19 nicht 
:-(

Naja, werde jetzt erstmal die Platinen umverdrahten, 2 Tage mit dem Mist 
zugebracht...

[H.Joachim S. (crazyhorse)]

Also mit dem Mist meine ich den Timer1 vom Tiny25, nicht die Software 
von PeDa, nicht dass hier Missverständnisse aufkommen....
Klappt wunderbar, und so kompakt hätte ich es selbst sicher nicht 
hinbekommen.

Eine Anmerkung trotzdem:

TIMSK = 1<<OCIE1A;                            // sync interrupt
o.ä.
kann natürlich leicht zur Falle werden.
Löscht andere Timer Int-Freigaben und man sieht schlecht, dass es auch 
darauf ankommt, dass OCIE1B gelöscht wird. Besser wäre:

 TIMSK = (TIMSK | 1<<OCIE1A) & ~ (1<<OCIE1B);    //OCIE1A on, OCIE1B off

löscht sichtbar OCIE1B und lässt die andern Bits in Ruhe.

[Johannes (Gast)]

Hallo, hat jemand den Bus schonmal auf einem ATtiny10 zum laufen 
gebracht?

Ich bin recht frisch im Microcontroller programmieren und würde gerne 
von einem Raspberry Pi aus mehrere ATtiny10 ansteuern die dann je einen 
Servo steuern.
Könnte mir jemand sagen ob ich mit dem 124Bus auf dem richtigen Weg bin?

Ich habe versucht den Slave2 für den ATtiny10 zu kompilieren, dies 
schlägt aber mit einigen Errors fehl:

Severity  Code  Description  Project  File  Line
Error    recipe for target 'main.o' failed  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\Debug\Makefile  79
Error    'CS12' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  46
Error    'CS12' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  46
Error    'CS11' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  46
Error    'CS11' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  46
Error    'CS10' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  46
Error    'CS10' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  46
Error    'DDRA' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  52
Error    'OCR1C' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  71
Error    'TCCR1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  79
Error    'PCMSK1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  86
Error    'TCCR1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  87
Error    'TIFR' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  94
Severity  Code  Description  Project  File  Line
Error    'OCF1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  94
Error    'TCNT1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  95
Error    'OCR1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  96
Error    'OCR1C' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  97
Error    'TCCR1A' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  98
Error    'COM1B1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  98
Error    'COM1B0' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  98
Error    'FOC1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  99
Error    'TIMSK' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  103
Error    'OCIE1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  103
Error    'TCNT1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  120
Error    'TIFR' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  126
Error    'OCF1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  126
Error    'PCMSK1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  138
Error    'PCMSK1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  143
Error    'TCCR1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  148
Error    'TCCR1A' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  152
Error    'TIFR' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  153
Error    'OCF1A' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  153
Error    'OCF1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  153
Error    'TCNT1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  154
Error    'OCR1B' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  155
Error    'OCR1A' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  156
Error    'TIMSK' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  158
Error    'OCIE1A' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  158
Error    'PCMSK0' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  160
Error    'PCMSK1' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  161
Error    'PCINT11' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  161
Error    'GIFR' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  162
Error    'PCIF' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  162
Error    'GIMSK' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  163
Error    'PORTA' undeclared (first use in this function)  NextSerialTest  C:\Users\Abc\Documents\Atmel Studio\7.0\NextSerialTest\NextSerialTest\main.c  170

Ich vermute das hier die Bezeichnung für die Pins des Tiny10 anders 
sind.

Zusammengefasst noch mal meine Frage: Lohnt sich der Weg über den 124Bus 
für einen ATtiny10, gibt es ggf. einfachere Ansätze oder kennt jemand 
eine Lösung für die Raspberry Pi -> ATtiny10 Kommunikation die ich mir 
anschauen könnte.

Vielen Dank im Vorraus,
Johannes