Ich habe ein bestehendes Projekt mit einem Minicontroller, alle Pins sind belegt. Ich muss irgendwie den Messwert des ADCs (10 bit) "herausbekommen". Einzige Schnittstelle scheint mir eine LED zu sein die von einem Portpin gesteuert wird. Nur stehe ich gerade etwas auf dem Schlauch was den Blinkcode betrifft. Was kann man da machen um sich die Werte 0-1023 über eine LED anzeigen zu lassen?
Mit einer Duo LED. Dann kannst du z.b. Rot/Grün/Aus anzeigen. Rot für 1 Grün für 0 und dazwischen eine aus Pause. Wenn du keine Duo LED zuhause hast kannst du auch einfach zwei einzelne nehmen :)
Naja, wenn du fit im Kopf bist, klappt das über ne LED. Du kannst auch morsen und das automatisiert empfangen :-) Besser wäre was anderes. Z.b. PWM, Manchester-Code oder der hier ausführlich besprochene one-wire von Peter Danegger. Auch Software-UART ist geeignet. Ne LED zum Zählen ist so ziemlich das letzte, was mir eingefallen wäre. Aber es geht natürlich trotzdem, wenn du dir eine geeignete Codierung einfallen lässt
Wenn das häufiger verwendet werden soll, würde ich mir die diversen Funkcodierungen mal angucken, Manchester und Morsen wurde ja schon genannt. Du könntest das auch per Infrarot rausschicken. Wenn Du einfach nur schnell ein paar Werte "von Hand" auslesen willst würd ich das Bitweise rausgeben: 10: $n = 10 20: Zweimal schnell hintereinander blinken, ca. 0.5 sec an, 0.5 sec aus 30: falls $ZAHL & 0x01, LED an 40: warte 2 sec 50: $ZAHL = $ZAHL / 2 60: $n = $n-1 70: Wenn ($n > 0) GOTO 20 dauert ca. 30 sec pro Wert. Aber bei mehr als 5 Werten wirds wahrscheinlich nervig.
Willst du den Wert direkt ablesen können? Sonst würde ich mit einem Fototransistor an die LED gehen und diese bei einer logischen eins im bitmuster für 100µs abdunkeln. das ganze dann mit einem weiteren µC auswerten und anzeigen lassen. Wenn du den wert selbst ablesen willst, kannst du einmal aufblitzen für 1 und zweimal aufblitzen für 0 nehmen. Welchem Zweck dient das denn? Debugging? Oder soll das ein dauerhafter Zustand werden.
Einfach rausmorsen. Vgl. RS232. Startbit und dann deine 10 bit. Das ganze dann per oszi oder logicanalyzer aufzeichnen und von Hand decodieren oder eben sehr langsam morsen.
Ich will das Ding quasi nur einmal auslesen. Das heißt vielleicht 10 Werte oder so aufnehmen zur weiteren Verarbeitung. Daher möchte ich keine zusätzlichen Empfänger basteln, eine Duo LED geht auch nicht. Die Codierung vom "verwirrten Anfänger" ist schon mal ein Ansatz. Einfacher geht es wahrscheinlich nicht, oder? Edit: Das RS232 Morsen werd ich mir gleich mal ansehen. Danke.
Hallo, nimm mal zeitbasis 1 sec, 0 kurz (0,2s) 1 lang (0,8s), pause 5 s, also etwa so wie DCF77. Da kannst du noch mitschreiben. Gruss Reinhard
Oder du gibst es dezimal aus. Jede Stelle repräsentiert durch die Anzahl der Blinkvorgänge. Davor ne Startkennung (z.B. LED lange an) Dann z.B, die Zahl 0723 0 = LED aus. Danach eine Sequenz, die dir den Wechsel auf die nächste Stelle signalisiert. zB. ein Burstpaket durch mehrmaligen schnellen Wechsel zwischen An und Aus. 7 = LED blinkt sieben mal Burstpaket 2 = LED blinkt zwei mal Burstpaket 3 = LED blinkt drei mal Pause = LED aus Aber zum öfteren "zu Fuß" auslesen ist das glaub echt mehr als nervig. Ich würde mir da was für die RS232 Schnittstelle stricken und mit dem einen Pin die TX-Leitung imitieren, und den Messwert einfach in nen Rechner tickern..
Ähh mal ne blöde Frage, wenn du das nur EINMAL verwenden willst, und du in der Entwicklung deines Projektes steckst, warum stöpselst du dann nicht einfach den Debugger dran und schaust nach, was dein AD-Wandler so treibt?
"Minicontroller" Vgl. "Minicomputer", also ein in SSI/MSI aufgebauter Controller? :) Aber welchen Typs?
Bei dem µC handelt es sich um einen Attiny13. Die Umgebung ist low-cost, selbstgebastelter Parallelportprogrammer, programmiert wird in Bascom. Debugging wäre sehr interessant, ist aber nur mit der teuren original Atmel Hardware möglich. Da bin ich einfach zu geizig für ;) Evtl. gibt es ja noch andere Möglichkeiten des Debuggings? Bin für Vorschläge offen.. Den ADC hab ich jetzt über eine Art Binärcode ausgelesen, war am schnellsten gebastelt. Ist aber etwas mühsam und dauert etwa 8s pro Wert.
Hannes schrieb: > Evtl. gibt es ja noch andere Möglichkeiten des Debuggings? Naja, das mit der LED z.B. Perfekt wäre natürlich (wenn du ein paar Pins frei hast) ein Display. Darum nehme ich eig. immer einen grösseren Controller und lasse einen Port frei, da kannst du locker ein Display im 4-Bit Betrieb betreiben und das Debugging ist so sehr komfortabel.
Electronics'nStuff schrieb: > Hannes schrieb: >> Evtl. gibt es ja noch andere Möglichkeiten des Debuggings? > > Naja, das mit der LED z.B. > Perfekt wäre natürlich (wenn du ein paar Pins frei hast) ein Display. Und zur Not, wenn alle Stricke reißen, kann man die Schaltung ja auch erst mal so verändern, dass man einzelne Teilaspekte des Programms unabhängig von allem anderen erst mal testen kann. Auch auf einem Tiny13 kriegt man normalerweise noch die 3 Pins frei, die man braucht um sich mit einem oder 2 595 eine Porterweiterung zu basteln, an die man ein paar 7_segment bzw. ein LCD ansteuern kann. Wenn man tatsächlich nur noch einen Pin hat, könnte man auch mit einer Software-UART und dann wahlweise auf PC und/oder LCD was hinkriegen. Aber im Grunde hat Electronics Stuff schon recht. Die ganz kleinen Tiny, mit ihren 5 nutzbaren Pins, sind im Grunde nicht wirklich zur Entwicklung geeignet, wenn man noch nicht so weit ist, dass man es sich zutrauen würde, auch mal 'im Dunkeln' zu programmieren.
Reinhard Kern schrieb: > nimm mal zeitbasis 1 sec, 0 kurz (0,2s) 1 lang (0,8s), pause 5 s, also > etwa so wie DCF77. Da kannst du noch mitschreiben. So ähnlich mache ich es auch schon seit Langem, hat sich wirklich bewährt! Zur Ausgabe eines Bytes sende ich alle 8 Bits nacheinander, vom MSbit bis zum LSbit. Für ein 1-Bit blinkt die LED lang auf, für ein 0-Bit ganz kurz. Die Ausgabe eines ganzen Bytes dauert dann so grob zwischen 5 und 10 Sekunden. Bei den ersten zwei oder drei Mal musste ich noch mitschreiben, dann hatte ich mich an die etwas seltsame "Zahlendarstellung" gewöhnt. @Karl Heinz: Du hast Recht, die kleinen ATtinys (z.B. ATtiny13A) sind sehr mager, was die I/O-Pins betrifft, aber halt schön handlich, ich mag sie einfach.
Markus Weber schrieb: > Reinhard Kern schrieb: > >> nimm mal zeitbasis 1 sec, 0 kurz (0,2s) 1 lang (0,8s), pause 5 s, also >> etwa so wie DCF77. Da kannst du noch mitschreiben. > > So ähnlich mache ich es auch schon seit Langem, hat sich wirklich > bewährt! Zustimmung. Exakt so mache ich es auch, ein Board hat nur eine LED, und das ist sogar auch noch die LED der LWL-Schnittstelle. Da ich diese oft nicht benötige, lasse ich mir dort einen DIP8-Schalter ausgeben. Allerdings nur 8 mal blinken, 2 mal mehr wäre aber auch kein Thema. OK, ich muß auch überhaupt gar nicht rechnen, sondern nur direkt die Blinkcodes mit den Schalterstellungen vergleichen. Vielleicht hält das jemand für Nonsens, aber die DIP-Schalter sind bei mir auch nur seriell über 2 Pins eingelesen, ich vermutete da früher mal eine Störung. Kontrolle ist eben besser. Ich hatte mir die Blinkerei auch bei DCF77 abgeschaut. Eines meiner Boards mit DCF77-Uhr hat gleich mehrere Status-LEDs, wo ich an einer das Empfangssignal als direkte Sichtkontrolle wieder ausgebe. Als ich noch Telefonanlagen bei Kunden installierte, und auch die kundenspezifische Anwendungsprogrammierung machte, kam mir eine Anlage mal unter, die einen einzelnen Siebensegment-Baustein innen auf der Platine hatte. Das war was ähnliches. Dort wurden zur Anlagenprogrammierung mehrstellige Programmcodes Dezimalzahlen als Einzelziffern auch mit Blinken ausgegeben, man muß dann die Zahl seriell aus Einzelziffern lesen. Hinter einer Zahlenkolonne kam zur Abgrenzung eine Pause. Die Sache wiederholte sich endlos, bis man eine Zahl notiert hatte, und eine Taste am Programmieradapter drückte. Für jede Anlagenfunktion gab es eine eigene Zahl. Im Grunde ist das ähnlich wie mit einer einzelnen LED. Nur muß man bei der LED noch minimal selbst rechnen. Den Anlagentyp sah ich nur seltenst, setzte sich auch nicht groß durch, ich nutzte sie ab und zu als vorläufiges Provisorium für einen Kunden, bis die bestellte gewünschte Anlage geliefert wurde. So macht man das, und signalisiert dem Kunden schon mal mit schneller Hilfe, daß man alles machbare tut. Eine Anlagenbestellung dauerte immer etwas, wie bei Neuwagen. Solche Preisklassen hat man nicht mal eben auf Lager liegen, und muß auch passend abgestimmt werden. Es ist eine Weile her, gut 20 Jahre, die ersten Mikroprozessoranlagen. Den Programmieralgorithmus hatte man noch auf Papier, in der Serviceanleitung. Es geht mal, wenn man nichts anderes zur Verfügung hat, bzw. weil der Anlagenhersteller am Programmierkomfort gespart hat. Das Ding mit dem einzelnen Siebensegment-Baustein war also definitiv eine Sparmaßnahme an Hardware in der Anlage, Entwicklungskosten, Aufwand, aber auch Verkaufspreis. Jedenfalls sah ich so einen Gerätetyp mit dieser Programmiertechnik nur ein einziges mal im Leben. Ein Sinn steckt trotzdem dahinter: Es reicht aber einfach aus, da eine Anlage im Laufe ihres Lebens meistens nur ein einziges mal programmiert wird. Allenfalls 2-3 mal noch ne Kleinigkeit umprogrammiert, bis es dem Kunden gefällt, mehr aber nicht. Einzig der Monteur muß sich damit mal eine Stunde herum schlagen. @ Hannes: Ist dein Notebook kaputt? Mit einer einzigen Tx-Leitung an deiner Schaltung und Masse könntest du dir Werte auch direkt an einem Terminalfenster anzeigen lassen. Voraus gesetzt, eine RS232 am Notebook. Selbst wenn der Pin kein UART ist, aber per Bitbanging.
Wenn du ein Digitaloszilloskop hast, geht das ja sehr bequem wenn du einfach in Binary mit "langen" (1ms?) Pausen zwischendrin das Signal auf die Leitung schickst. Ansonsten halt, wie gesagt, dasselbe Verfahren nur mit langen Pausen und manuellem Mitschreiben. ;) Evtl. kannst du auch mal versuchen das an die Soundkarte zu hängen und mit Audacity auszuwerten. ;)
Warum nicht eine gepulste PWM und ein Oszilloskop? Oder ein Pseudo Oszilloskop über eine SOundkarte? Noch besser wäre ein serielles Protokoll und Anzeige eines 10 Bit Busses mit einem Logic Analyzer.
Oh, ja, wenn du das gleiche Ergebnis periodisch immer wieder ausgibst, geht das auch mit einem analogen Oszilloskop wahrscheinlich sehr gut.
Andere Leute würde einfach mittels Soft-UART dort massenhaft Daten sehr einfach lesbar ausgeben.
Falk Brunner schrieb: > Andere Leute würde einfach mittels Soft-UART dort massenhaft Daten sehr > einfach lesbar ausgeben. So mache ich es. Die LED-Methode, wenn aus irgend einem Grund kein PC verfügbar ist.
(Soft-)UART wurde jetzt schon oft erwähnt. Spricht sehr viel für. Frage mich, was dagegen spricht. Wenn der TO über den Parallelport flasht, wird ein serieller wohl erst recht verfügbar sein. Da ist der Kram mit LEDs doch masochistisch - wenn auch grundsätzlich völlig gerechtfertigt und interessant, darüber nachzudenken.
Malte S. schrieb: > Frage mich, was dagegen spricht. Naja wahrscheinlich kann das der TE nicht. Henning schrieb: > Wie wärs mit nem Schieberegister, und dort ein paar LEDs dranhängen?? An einen Pin?
Hannes schrieb: > Was kann man da machen um sich die > Werte 0-1023 über eine LED anzeigen zu lassen? Nun, man sollte gut im Kopfrechnen sein, um den Blinkcode schnell in eine konkrete Zahl umrechnen zu können. :-) Gruss Harald
Man kann sich auch ein Miniterminal bauen, wenns ohne PC gehen soll: Beitrag "LCD über nur einen IO-Pin ansteuern"
Man könnte - wenn der Rest des Codes damit klarkommt auch den Pin für zB X mal 10 Mikrosekunden anlassen und dann Pause machen - Vorteil ist dass man auf die Weise einen proportionalen Wert auf einem normalen Frequenzzähler ausgeben kann (den man dann natürlich noch mit einem Faktor verrechnen muss ausser man kann in glatten Mikrosekunden oder 10-Mikrosekunden Pins schalten!)....
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.