Bit-Banging vom Uno zu einem UNI/O EEPROM

Hey Leute!

Habe mir ausversehen einen UNI/O EEPROM angeschafft und vergessen das der UNO nur SPI und I²C unterstützt. Jedoch sehe ich das als Chance mich im Bit-Banging zu versuchen.

Ich habe schon einiges darüber gelesen leider nichts um einen UNI/O 1-Wire zu erreichen. Dort wird halt das Manchester Encoding verlangt. Bei den Bus-Typen war dies ja relativ plausibel da man den CLK ja seperat meldet. Jedoch ist bei UNI/O das CLK Timing ja im Signal integriert bzw. wird dort aus den Frequenzen ausgelesen.

Kann mir jemand C/C++ oder Pseudocode geben der mir die UNI/O Vorgehensweise verdeutlicht. Ich weiss das ist schon fast die halbe Miete - aber ohne praktische Beispiele kann ich mir leider selber nichts zusammenreimen.

(Ein Tutorial Verweis wäre natürlich auch super!)

Ich hoffe ich verlange nicht zuviel !

gruß Charlie

https://www.mikrocontroller.net/topic/372106

Was sagt denn Google("Arduino Manchester")?

Ha sehr lustiger Zufall - du hast gerade auf meinen Thread bei mikrocontroller.net verwiesen. Ich habe dort halt den Begriff Bit-Banging erhalten, was schon die halbe Miete ist, leider finde ich darunter nicht wirklich konkretes in Verbindung mit Manchester Encoding - ich finde schon etwas - aber zu abstrakt und nicht deutlich bezogen darauf wie man es praktisch nun macht. Ich finde dutzende Tutorials für I²C oder SPI aber nix für den UNI/O Kram.

Ich möchte ungerne nerven - aber mich juckt es echt in den Fingern und daher möchte ich das Ganze unbedingt hinkriegen :slight_smile:

Ah MOment - "Arduino Manchester" da habe ich noch nicht nach gesucht - scheint einiges zu sein! Bis morgen :D :D

Falke88: Ha sehr lustiger Zufall - du hast gerade auf meinen Thread bei mikrocontroller.net verwiesen.

Haha, dann kommt gleich noch ein lustiger Zufall.

Denn ich verweise auf meine Antwort, die ich Dir im internationalen Bereich des Forums schon gegeben hatte.

Wenn das Lesen von Datenblättern und das Programmieren von neuem Code, den bisher noch niemand geschrieben hat, nicht so Dein Ding ist, besorgst Du Dir lieber ein EEPROM mit Support für einen Bus (I2C, SPI), für den es haufenweise fertigen Arduino-Code gibt, den Du nur per Copy-and-Paste übernehmen brauchst.

Oh nein erwischt :D

Aber du siehst ich werde immer schlauer ;)

Was den EEPROM-Wechseln angeht, dass wäre der letzte Fall den ich anwenden würde. Vorher möchte ich nichts unversucht lassen. Ich verstehe das Manche sowas ungern hören und möchten das man das tut was doch bitte alle machen - aber Rebellen hier und dort bewirken vielleicht auch Wunder. Ich werde wohl nicht dazu gehören - aber immerhin lerne ich viel beim Versuch.

;)

Basics lernen wäre erst einmal angedacht. Ansonsten, Google ist doch mit dem Manchester Code voll genug. https://www.mikrocontroller.net/topic/38924#287947

Ich sehe hier aber noch keine Eigeninitiative mit einem Code.

Google spuckt da doch Treffer aus

Hier gibt es Code in AVR C:

Das verwendet einen Timer um die Zeit bis zur Mitte des Bits zu bestimmen und macht dann einen Flankenwechsel. Wobei Timer0 auf dem Arduino schon belegt ist, aber das kann man auch mit Timer1 oder Timer2 machen.

Und den Teil mit den Bits am Anfang und der Checksumme brauchst du gar nicht.

Ja gut. Also ich wüsste schon wie ich nen I2C ansteuern könnte. Da habe ich immerhin n SCL und n SDA. Aber das Problem mit dem UNI/O und dessen 1-Wire stört mich halt, dass ich nicht weiss ob ich großartig auf das Clocking achten muss oder einfach das Protokoll einhalten muss und der Rest wird synchronisiert. Das ist wie gesagt mein einziges Problem. Ich würde es ja einfach grob versuchen - aber will auch nichts kaputt machen :P

Aber ich werde jetzt mal was versuchen dann kann ich auch konkretere Fragen stellen!

Bei Manchester Codierung gibt es keinen separaten Takt! Das ist ja vor allem für Funk-Übertragungen gedacht. Wenn ein bestimmter Takt vorgegeben ist, dann bestimmt der die Länge der Bits.

In dem Code aus meinem Link gibt es dafür zwei Konstanten:

/* The time for one bit in µs/cycles */
#define BIT_TIME 400

#define HALF_TIME 200

Wobei man HALF_TIME da eher als BIT_TIME /2 definieren sollte

Dann lässt man den Timer mit einem Takt von 1µs laufen (d.h. Prescaler 16 bei 16MHz) und kann dann abfragen wann die Zeit vorbei ist. delayMicroseconds() ist da doch nicht so gut, da man dann restliche Code-Laufzeit noch berücksichtigen muss. Der Timer läuft dagegen auch so weiter.

Und wozu brauche ich Die HalfTime? Die BitTime habe ich so verstanden, dass dies die den kompletten Clock/Data Takt (ist ja bei Manchester in einem) beschreibt. Und die Half Time ist die Taktmitte - dort wo HighToLow für "0" und LowToHigh für "1" auftritt. Soll ich also immer zur Half Time via TX auf HIGH oder LOW schalten um den Bit zu senden?

Schau dir sendByte() in ManchesterTX.c an

Ah okay...jetzt wirds langsam ein Bild :) Danke Dir! Damit versuch ichs jetzt mal

Du musst halt wie gesagt mit dem Timer aufpassen. Timer0 ist auf dem Arduino schon belegt. Außerdem ist der Code für 8MHz geschrieben. Außerdem gibt es keinen Prescaler 16. Da hatte ich oben nicht aufgepasst :(

Man kann aber einfach den 16 Bit Timer1 nehmen. Bei Prescaler 8 hat man dann 0,5µs Auflösung:

TCCR1A = 0;
TCCR1B = _BV(CS11);
TIMSK1 = 0;

Wenn man dann 400µs braucht kann man auf TCNT1 == 800 abfragen. Das kannst du auch über die #define Konstanten anpassen.

Also wie schnell der Takt geschieht ist doch sowieso egal oder? kann doch (ich meine bewusst millisek) die BitTime = 100millisec und HalfTime = 50ms setzen oder nicht?

Kommt auf dein EEPROM an. Da musst du mal ins Datenblatt schauen. Ein gewisses Fenster wird es da schon geben, aber ich weiß nicht ob es beliebig langsam kein kann.

Hm im Datasheet finde ich da nix, oder ich übersehe es andauernd :D Ich denke aber Max Hz ist das einzige Problem. Langsam findet doch jeder schöner :)

Falke88: Hm im Datasheet finde ich da nix, oder ich übersehe es andauernd

Das minimale und maximale Bitraten-Timing steht doch ganz deutlich sowohl im Datenblatt des EEPROMs als auch im Datenblatt des UNI/O Bus unter der Tabellenüberschrift "AC CHARACTERISTICS" gelistet.

Bit period Min. 10 µs Max. 100 µs

Also nix Millisekunden, sondern es geht auch beim langsamsten Timing um Mikrosekunden!

Also wie schnell der Takt geschieht ist doch sowieso egal oder? 
kann doch (ich meine bewusst millisek) die BitTime = 100millisec  
und HalfTime = 50ms setzen oder nicht?

Wenn Du da mit 10 Hz Daten überträgst dann braucht ein Bit zu schreiben oer lesen ja 3 Sekunden. Kauf Dir um weniger als 2€ ein I2C oder SPI - EEprom und die anze Arbeit ist getan. So Arbeitest Du tage daran herum.

Grüße Uwe

uwefed:
So Arbeitest Du tage daran herum.

Tage?

Wenn jemand bereits drei Tage in Datenblättern liest, und dann das Bit-Timing immer noch nicht gefunden hat, dann wird er ohne fremde Hilfe eher etliche Jahre brauchen. Meine Einschätzung.

Oder so lange, bis ihm jemand fertigen Code postet.