Seid gegrüßt liebe Elektronik-Freunde, nach langer Zeit habe ich mich mal wieder an ein kleines Projekt gewagt und stecke nun bereits fest. Ich habe vor Daten über eine Leitung zu senden, also Daten und Clock auf derselben. Ich habe mir das für mich so zusammengebastelt, dass Ich den Pegel des Pins am uC auf High setze und dann entweder zwei OVF0 für ein gesetztes bit, bzw. ein OVF0 für ein nicht gesetztes Bit warte, bevor ich den Pegel des Pins wieder auf Low ziehe. Das ganze funktioniert schon wunderbar. Ich habe ein Soundkarten-Oscilloscop an den Controller angeschlossen und das zu sendende Byte, welches ich Hardcoded habe wird auch wunderbar übertragen, sobald ich den Taster, welcher das Senden startet betätige. Das einzige Problem ist nur, dass der uC nicht mehr aufhört Daten zu senden. Mir ist klar, dass es durchaus passieren kann, dass in der Zeit, in der ich den Taster betätige die Sende-Sequenz mehrmals durchläuft. Jedoch hört der uC selbst nach einigen Sekunden nicht auf zu senden, was insbesondere verwirrend ist, da im AVR-Simulator alles Reibungslos klappt. Hier noch die Randdaten: Genutzter uC: attiny2313 Genutzter Compiler: avr-gcc Genutzte IDE: AVR-Studio Genutztes Testboard: Atmel Evaluation Board 2.0 von Pollin. Genutztes "Oscilloskop": Soundkarte mit Spannungsteiler auf Breadboard mit Christian Zeitnitz' Programm (http://www.zeitnitz.de/Christian/index.php?sel=scope_de) Ich würde euch fragen, ob Ihr so gnädig sein würdet mal einen kurzen Blick auf meinen (durchgehend kommentierten) C-Code zu werfen? Dieser ist als C-Datei an diesen Post angehangen. Wahrscheinlich übersehe ich etwas total marginales. mit freundlichen Grüßen Karsten B.
sorg erstmal softwaremäßig dafür das du wirklich nur einmal sendest, so kannst du dann bestimmen ob der fehler im µC oder vielleiciht im pc ist
Da gibts auch schon was: 1-wire Falls du das ganze nicht neu erfinden willst.
Mir ist grad aufgefallen, dass der Quellcode gar nicht mitgekommen ist hehe X-D @willi Am PC liegt es eindeutig nicht. Ich habe an dem Pin zusätzlich eine LED zum Testen mal angehangen. Es macht keinen Unterschied, ob das Soundkarten-Oscilloskop dran hängt oder nicht. Darüber hinaus versuch ich es ja, dass es Softwaremäßig nur ein mal sendet :-) @Gast An sich funktioniert ja das, was ich habe wie 1-Wire. Nur die Timings sind anders und das Signal ist invertiert. mit freundlichen Grüßen Karsten B. PS: Hoffe diesmal kommt die Datei mit ^^
Habs inzwischen schon rausgefunden. Wie gedacht war das Problem mal wieder so einfach, dass man den Wald vor lauter Bäumen nicht sehen konnte. Ich hatte ja beschrieben, dass der interne Pull-Up im uC angeschaltet ist, jedoch hab ich nicht dran gedacht, dass die Taster am Atmel Evaluation Board 2.0 von Pollin externe Pull-Downs hat. Dass das dann nicht klappt mit internem Pull-Up ist klar rot-werd. mit freundlichen Grüßen Karsten B. PS: Wer interesse an dem von mir geposteten Code hat kann diesen gerne nutzen!
Karsten B. schrieb: > ist, jedoch hab ich nicht dran gedacht, dass die Taster am Atmel > Evaluation Board 2.0 von Pollin externe Pull-Downs hat. Dann löte mal schleunigst die Kondensatoren an den Tasten raus. Die ergeben schöne Spikes auf VCC, wenn sie beim Drücken schlagartig geladen werden. Hier wurden deshalb schon "mysteriöse" Resets berichtet. Peter
Hi Peter, hm... hatte mir bis jetzt noch nie wirklich angeschaut, wie das Board aufgebaut ist. Wieso setzt man denn Kondensatoren an Taster? Sollen die etwa zur Entprellung dienen? Seltsame Idee wie ich find. mit freundlichen Grüßen Karsten B.
Nur so als Hinweis, Suchwort LIN Bus. Man muss ja nicht das Protokoll nutzen, es geht ja auch mit einem uart und dem LIN Tranceiver... Gruß, m.
@maddin Danke für den Hinweis... LIN-Bus kannte ich noch gar nicht. Aber an sich versuche ich mein eigenes Ding zu entwickeln, nicht weil ich denke, dass ich dies besser kann als studierte Akademiker, sondern um mich mindestens einmal mit Problemen solcher Entwicklungen auseinandergesetzt zu haben. Das hat den Vorteil, dass man an sich wächst, was (bei mir) nicht so schön funktioniert, wenn man bereits ausgeklügelte Patentlösungen anwendet. Dennoch werde ich mir den LIN-Bus ebenfalls zu Gemüte führen, um weitere Anregungen und Ideen zur Realisierung einer Ein-Draht-Datenübertragung in Erfahrung zu bringen. Ich möchte nur noch mal klarstellen, dass ich nach Ansätzen gesucht habe, warum das Signal nicht abbricht, was ich vorerst in der Logik meines Quelltextes vermutet habe und nicht nach einer bestehenden Lösung für eine Ein-Draht-Datenübertragung. Es tut mir wirklich leid, falls dies aus meinem Startpost heraus nicht erkenntlich war. Es hat sich halt herausgestellt, dass ich einen internen Pull-Up an einem Taster aktiviert habe, der einen Pull-Down hat. Ich würde damit behaupten, dass der Thread damit abgeschlossen ist. @Peter Noch mal vielen Dank für den Hinweis auf die Kondis an den Tastern. Dies wird mir wahrscheinlich noch viel Ärger ersparen. @all Nochmal vielen Dank für die konstruktiven Beiträge ^^ mit freundlichen Grüßen Karsten B.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.