Reset Pin am ATtiny nutzen

  • Hi,
    ich spiele momentan ein wenig mit einem ATtiny84 rum und habe gelesen, man könnte -auch ohne die Fuse permanent zu programmieren- den Reset Pin des ATtiny für I/O Zwecke benutzen. Meistens hieß es dann "Benutze doch einen Bootloader", aber nie wurde ins Detail gegangen, was man denn letztendlich tun muss. Ich will auf jeden Fall die Fuse nicht permanent setzen, da ich keinen High Voltage Programmer habe.
    Kann mir vielleicht jemand von euch sagen, wie ich das mit einem Bootloader schaffe, PB3 als I/O Pin zu nutzen?
    Danke

  • Zum Thema ATTiny und bootloader stöbere ich auch gerade herum.
    Ich hätte da evtl. zwei interessante Links, die ich mir gerade "reinziehe" ;) ...

    Guckst Du -> hier <- das ist eine GUI für avrdude ... finde ich extrem praktisch gerade in Hinsicht auf die fuses ...
    Dann guckst Du -> hier <- ... da wird Fastboot von Peter Dannegger beschrieben ...

    cheers,
    -ds-

  • Das verwirrt mich leider mehr, als dass es hilft :-/

    Als ich letztens die Boards in Arduino IDE importiert habe (https://github.com/arduino/Arduin…ds-support-urls), dachte ich, das wären Bootloader... Sind es aber nicht?

    Leider hängt hier meiner Meinung nach die Dokumentation von dem ganzen Kram der Entwicklung sehr weit hinterher. Könntest du mir n bisschen Klarheit bringen, wenn du Zeit dazu hast? Wär super! Muss auch nicht direkt sein. Über die prinzipielle Funktion eines Bootloaders bin ich mir schon im Klaren, nur, wie das jetzt läuft, da bin ich mir unsicher. Wenn ich zB einen einfachen Sketch auf den ATtiny hochlade, der eine LED blinken lässt, ist der grad mal 86 Bytes groß. Dachte, allein der Bootloader wäre schon größer.... Überschreibe ich den Bootloader dann wieder mit dem Sketch, oder wie ist das?


    EDIT: Und noch eine Frage generell: Den Abblockkondensator lieber möglichst nah an VCC oder an GND?

    Einmal editiert, zuletzt von KrawallKurt (5. März 2016 um 20:43)

  • Hi Kurt,


    Das verwirrt mich leider mehr, als dass es hilft :-/


    hm ... das war eigentlich nicht Sinn und Zweck der Übung ;) ...


    Als ich letztens die Boards in Arduino IDE importiert ... Sind es aber nicht?


    Naja ... in gewisser Weise auch ... Diese Pakete bringen Tools, libraries und was weiss ich noch alles mit. Da sind u.a. durchaus angepasste bootloader dabei. Der ganze Krempel steht dann unter ~/.arduino15.
    Ich muss mich da jetzt auf Linux beziehen, weil ich Windows schon lange in Rente geschickt habe ;)
    Das ist es übrigens wert sich zu merken. Hast Du mal Deine IDE-Konfiguration verballert, dann einfach das ganze Verzeichnis leeren, die IDE aufrufen, die Boardmanager neu eintragen und dann sauber nachinstallieren.
    Dann noch die Libraries über den Manager installieren und die Umgebung ist wieder sauber.

    Bootloader in der ARDUINO-IDE heisst immer Arduino-bootloader.


    ... da bin ich mir unsicher. Wenn ich zB einen einfachen Sketch auf den ATtiny hochlade, der eine LED blinken lässt, ist der grad mal 86 Bytes groß. Dachte, allein der Bootloader wäre schon größer.... Überschreibe ich den Bootloader dann wieder mit dem Sketch, oder wie ist das?

    Nö ... das ist ja der Sinn vom bootloader. Die IDE redet mit dem booloader, der empfängt den Sketch und schreibt ihn ins Flash.
    Den bootloader kannst Du afaik nur per ISP oder z.B. einem STK500 ... überschreiben.
    Der bootloader von Dannegger z.B. lauscht für eine kurze Zeit auf eine Anforderung eines Programmers ein Programm zu schicken, bevor der µC (z.B. ein tiny) "normal" startet. Dadurch kannst Du den Tiny über z.B. zwei Drähte via Rx/Tx programmieren. Du kannst Dir also das übliche MISO/MOSI/SCK ... Gesumse sparen.


    EDIT: Und noch eine Frage generell: Den Abblockkondensator lieber möglichst nah an VCC oder an GND?


    weder noch ... so nah wie möglich an den µController ...

    Ich hoffe, das hat ein bisschen Klarheit gebracht,
    cheers,
    -ds-

  • Hi ds,
    danke für deine Mühe.


    Bootloader in der ARDUINO-IDE heisst immer Arduino-bootloader.


    Kannst du mir erklären, was du damit meinst?


    Nö ... das ist ja der Sinn vom bootloader. Die IDE redet mit dem booloader, der empfängt den Sketch und schreibt ihn ins Flash.
    Den bootloader kannst Du afaik nur per ISP oder z.B. einem STK500 ... überschreiben.
    Der bootloader von Dannegger z.B. lauscht für eine kurze Zeit auf eine Anforderung eines Programmers ein Programm zu schicken, bevor der µC (z.B. ein tiny) "normal" startet. Dadurch kannst Du den Tiny über z.B. zwei Drähte via Rx/Tx programmieren. Du kannst Dir also das übliche MISO/MOSI/SCK ... Gesumse sparen.


    Kurz zu meinem Setup: Linux PC -> USB Kabel -> Arduino Uno (als ISP) -> ATtiny. Also ich programmiere sowieso immer über ISP. Kann ich einen ATtiny aus der Arduino IDE auch anders programmieren?
    Mein Vorgehen bisher: Mein Board auswählen, Bootloader brennen, Sketch hochladen. Wobei mir auch der Unterschied zwischen "Hochladen (Strg+U)" und "Hochladen mit Programmer (Strg + Shift + U)" nicht ganz klar ist. Wird, wenn ich das so mache der Bootloader wieder überschrieben, oder nicht? Immerhin ist das ja programmieren über ISP...

    Nach dem Upload sagt mir Arduino IDE dann immer sowas wie "Der Sketch verwendet 86 Bytes (1%) des Programmspeicherplatzes. Das Maximum sind 8.192 Bytes."



    weder noch ... so nah wie möglich an den µController ...


    Schon klar, aber wenn die Beinchen am µC nicht nebeneinander liegen, was dann? Lieber möglichst nah ans VCC Beinchen oder ans GND Beinchen? :)

    Viele Grüße


  • danke für deine Mühe.


    Gerne ... ;)


    Kannst du mir erklären, was du damit meinst?


    ähm ... naja, Arduino ist afaik so ein Kunstwort. Damit kann imho die IDE, die Programmiersprache, der AVR mit einem Arduino-bootloader, ... was weiss ich noch alles gemeint sein ( das ist die Kunst dabei ... deshalb ja Kunstwort ;) ).
    Arduino hat einen bootloader, Dannegger einen anderen und wenn Du mal recherchierst wirst Du feststellen, dass es noch einen ganzen Sack vol anderer bootloader gibt.
    Ein AVR mit Arduino-bootloader kann halt mit der IDE "reden" ... würdest Du einen AVR mit z.B. Danneggers fastboot bestücken, dann würde das mit der Kommunikation bootloader <-> Arduino IDE nicht mehr klappen. Du könntest den Chip mit der IDE mehr umprogrammieren.
    Macht aber nix, dafür gibts dann z.B. fboot oder eben andere loader-Programme, die das leisten.
    Und um noch mal auf Deine Frage mit dem Reset zurückzukommen: wenn Du den Tiny mit dem fastboot ausstattest, wird das vermutlich funktionieren ... weil ja der fastboot initial erst mal wartet, ob er eine Programmieranforderung an den als Rx/Tx definierten Pins empfängt.
    Wie das allerdings mit dem Arduino-loader aussieht, vermag ich nicht zu sagen ...


    ... Kann ich einen ATtiny aus der Arduino IDE auch anders programmieren?


    Klar, mit einem passenden Programmer, z.B. ein stk oder diesem ... Tinyprog glaub' ich heisst das Ding ...
    Es gibt übrigens auch eine kleine Platine von Digispark, auf der ein Tiny85 verbaut ist. Die kann man direkt in den USB-Port des Laptops einstecken. Mit einer zusätzlichen Boardmanager-URL auf "digistump" kannst Du das Ding dann direkt flashen.


    Mein Vorgehen bisher: Mein Board auswählen, Bootloader brennen, Sketch hochladen.


    Das booloader brennen brauchst Du nur einmal machen. Danach reicht das hochladen des sketches ...


    Wobei mir auch der Unterschied zwischen "Hochladen (Strg+U)" und "Hochladen mit Programmer (Strg + Shift + U)" nicht ganz klar ist.


    Da bin ich allerdings auch überfragt ... für mich sieht das gleich aus ...


    Wird, wenn ich das so mache der Bootloader wieder überschrieben, oder nicht? Immerhin ist das ja programmieren über ISP...


    Das hat erst mal nichts damit zu tun, auf welche Art und Weise Du den Code auf den µC hochlädst.
    ISP ist nur eine Möglichkeit die sich ATMEL mal ausgedacht hatte, um auch verbaute µC flashen zu können.
    Es ist wieder eine Frage des bootloaders, auf welche Art und Weise er mit dem Programmer kommuniziert. Das kann über einen oder zwei Drähte sein oder eben über SPI ...
    Ist kein bootloader drauf, wird der Kram halt einfach ins Flash geschrieben und gut ists ...
    Ist einer drauf, kann man ihn auch wieder überschreiben. Das funktioniert - logischerweise - allerdings nicht so, dass Du dem bootloader sagst, er soll sich selbst überschreiben. Das würde sowieso nicht gehen und der bootloader wäre ganz schön blöd, wenn er das machen würde.
    Fazit: Du kannst einen µC (meist/oft) auf mindestens zwei Arten flashen: über den bootloader (recommended für Arduino & Co.) oder unter Umgehung desselben. Dann muss der Programmer den µC zum Flashen allerdings direkt ansteuern.


    Nach dem Upload sagt mir Arduino IDE dann immer sowas wie "Der Sketch verwendet 86 Bytes (1%) des Programmspeicherplatzes. Das Maximum sind 8.192 Bytes."


    Passt ja ... um so eine LED blinken zu lassen braucht es nicht viel. Du verwendest für den sketch halt 1% des verfügbaren Flash-Speichers. Da hast Du halt noch jede Menge Platz ...


    Schon klar, aber wenn die Beinchen am µC nicht nebeneinander liegen, was dann? Lieber möglichst nah ans VCC Beinchen oder ans GND Beinchen? :)


    Naja ... was heisst "nicht nebeneinander" ;)
    Im Allgemeinen dürfte das egal sein ... im Zweifelsfall verbaust Du halt zwei ... einen vom VCC-Pin auf Masse und einen vom GND-Pin auf 5V (oder whatever Deine Stromversorgung ist).

    So ... ich hoffe, ich hab' jetzt nicht zuviel Mist erzählt ... ;)
    Aber ich denke, das passt soweit schon ...

    cheers,
    -ds-

  • So langsam lichtet sich der Nebel :) Was mich halt wundert, ist: "Der Sketch verwendet 86 Bytes (1%) des Programmspeicherplatzes. Das Maximum sind 8.192 Bytes." Die 8192 Bytes sind doch inklusive Bootloader, oder nicht? Sollte dann nicht weniger zur Verfügung stehen, wenn der Bootloader schon drauf ist? Deswegen hab ich mich gefragt, ob das Programm den Bootloader wieder überschrieben hat...
    Außerdem steht in deinem Link zu FastBoot

    Zitat von PeDa

    Normalerweise wird der Programmcode des Mikrocontrollers mit einem ISP-Dongle in den Flash gebrannt.

    Das klingt für mich, als könne man über ISP auch ein Programm ohne Bootloader flashen.

    Zitat von dreamshader

    würdest Du einen AVR mit z.B. Danneggers fastboot bestücken, dann würde das mit der Kommunikation bootloader <-> Arduino IDE nicht mehr klappen


    Ich könnte auch nicht mehr über Arduino IDE wieder einen Arduino-Bootloader brennen?

  • Immer noch fleissig ;) ...


    So langsam lichtet sich der Nebel :)


    Na siehste :thumbs1: alles halb so wild ...


    Die 8192 Bytes sind doch inklusive Bootloader, oder nicht? Sollte dann nicht weniger zur Verfügung stehen, wenn der Bootloader schon drauf ist? Deswegen hab ich mich gefragt, ob das Programm den Bootloader wieder überschrieben hat...


    Ne ... der bootloader kommt in einen speziellen, geschützten Bereich des µC ... meist nur um die 256 Byte oder so ... es gab/gibt auch bootloader in eigenen ICs ... aber das ist, glaube ich, eher old fashion ;) (früher waren die gesamten Programme in einem eigenen EPROM ... so mit UV-Licht zum Löschen und so ...).
    Ob der Controller dann direkt oder über einen bootloader startet, kanns Du über die fuses einstellen (wie z.B. auch externe clock usw.).


    Außerdem steht in deinem Link zu FastBoot

    Das klingt für mich, als könne man über ISP auch ein Programm ohne Bootloader flashen.


    Klar kannst Du ... hatten wir, glaube ich, schon. Kein Problem. Nur wenn vorher ein booloader drauf war, läuft Dein Programm mit aller Wahrscheinlichkeit nicht. Dazu müsstest Du die fuse wieder zurücksetzen


    Ich könnte auch nicht mehr über Arduino IDE wieder einen Arduino-Bootloader brennen?


    Doch ... weil der nicht über den bootloader sondern direkt ins Flash geschrieben wird.

    Ich hab' übrigens -> hier <- noch was gefunden, das auch zur Klärung beitragen könnte.

    cheers,
    -ds-

  • Da hast Du wohl recht ... die Tiny sind da scheinbar Ausreisser ... die haben auch keinen geschützen Bereich für den bootloader.
    Ich hab' Dir mittlerweile vermutlich eh alles erzählt, was ich zu dem Thema weiss. Und der Tiny geört da leider nicht dazu ... ich sagte ja schon, dass ich mir den gerade selbst erst erarbeite :) ...
    Ich hatte bisher nur mit MEGAs zu tun.

    Ich bin jetzt davon ausgegangen, dass der Tiny, so er einen Arduino-loader drauf hat, eben über diesen geflasht wird. Und m.E. sollte man ihn auch einfach überbügeln können. Es sei denn, man hat sich durch verfusseln ausgesperrt ... aber da versuch' ich mich gerade reinzudenken.
    Hintergrund: ich hätte eben gerne Danneggers fastboot auf einem Tiny85 ... und zum Flashen von Programmen dann eben fboot statt der Arduino-IDE.

    cu,
    -ds-

  • Moin Kurt ....

    also ... ich hab' mir jetzt zusätzlich erst mal einen Tiny-Progger aus einem Pro-Mini gebastelt.
    Ich versuche jetzt als Nächstes SELFPRGEN auf enable zu setzen und dann Dannegger's fastboot auf den Tiny zu schieben.
    Wenn der bootloader drauf ist und auch funktioniert, sollte ich den Tiny über eine serielle Verbindung über den - im bootloader definierten - Rx- und Tx-Pin flashen können.
    Für Dich wäre dann interessant, ob sich der Tiny mit RSTDISBL (External Reset disable) auf 1 noch über SPI bzw. den bootloader flashen lässt.
    Da der Tiny ja scheinbar nur einen "Pseudo-bootloader" unterstützt, entfällt das Setzen weiterer fuses.
    Habe ich das richtig verstanden?

    Ach ja: -> netter Rechner für die Fuses <-

    cheers,
    -ds-

  • Jaaa... Also, eigentlich wäre für mich interessant, ob ich den Tiny mit RSTDISBL überhaupt noch flashen kann. Muss nicht über SPI sein, wenn ich dem Uno auch beibringen kann, über TX/RX zu flashen. Warum meinst du, das Setzen weiterer Fuses entfällt?
    Gruß

  • Hi,


    ... mit RSTDISBL überhaupt noch flashen kann.


    genau ... schrub ich doch, oder?


    ... Warum meinst du, das Setzen weiterer Fuses entfällt?


    weil der Tiny, im Gegensatz zum Mega, eben keinen Hardware-Support (wie den geschützten Bereich, dessen Grösse usw.) für Bootloader hat.
    Ausser dem Selfprogramming-Bit wüsste ich jetzt erst mal nicht, was ich da Setzen sollte.
    Naja ... und wenn der bootloader funktioniert, halt RSTDISBL ...

    //EDIT: scheint sich tatsächlich so zu verhalten, wie ich dachte: -> click <- ... ohne bootloader aber mit RST-enable ist der Tiny erst mal nur mit einem HV-Programmer zu retten.

    Ich bin selber mal gespannt,
    -ds-

  • Hi

    Ich hab jetzt zwar nicht alles genau durchgelesen und verstanden denke aber dass ich vielleicht dennoch ein bischen Klarheit schaffen kann. :)
    Könnte aber sein dass nicht alles 100%ig korrekt ist. Bin da auch kein Spezialist.

    Zitat

    ich spiele momentan ein wenig mit einem ATtiny84 rum und habe gelesen, man könnte -auch ohne die Fuse permanent zu programmieren- den Reset Pin des ATtiny für I/O Zwecke benutzen.

    Wusste ich gar nicht. :)
    Der Pin lässt sich aber was ich gerade gelesen hab nur als sehr beschränkter ADC Input nutzen und nicht als normaler I/O Pin. Für die meisten Anwendungen imho uninteressant und eher gefrickel.
    Reset Pin als gewöhnlicher I/O (ADC) Pin verwenden geht nur über das entsprechende Fusebit.

    Wenn du einen Bootloader verwenden willst musst du die Fuses so einstellen wie du sie brauchst bevor du den Reset Pin umfunktionierst und den Bootloader flashst.
    Wenn der Reset Pin weg ist kommt man nur noch mit einem HV Programmierer an die Fuses.
    Die können auch nicht über einen Bootloader geändert werden. Das ist wenn ich mich nicht irre nur bei größeren AVR's möglich und gilt auch nicht für alle Fuses.

    Was man ohne Reset Pin und mit Bootloader noch beachten muss ist dass man den Bootloader ja auch irgendwie triggern/starten muss. Wenn der Reset Pin weg ist bleibt nur Strom kurz wegnehmen oder ein Software-Reset.


    Wenn man die ATtinys mit der Arduino IDE programmiert wird soweit ich weiß nie ein Bootloader verwendet. Man braucht zum programmieren deshalb auch immer einen ISP Programmierer.
    Der wichtigste Vorteil des Bootloaders ist ja das man eben keinen ISP Programmiere mehr braucht sondern den µC einfach über eine Serielle Schnittstelle programmieren kann.

    Der unterschied zwischen "Upload" und "Upload using programmer" ist dass im ersten Fall der Sketch über den Bootloader geflasht wird und im zweiten über den ISP Programmierer.
    Was die IDE genau macht kommt aber auch auf das eingestellte Board an.
    Da beim ATTiny kein Bootloader verwendet wird versucht die IDE in beiden Fällen den Sketch über den ISP Programmierer zu flashen.

    Wenn als Board "ATTiny" eingestellt ist und du auf "Burn Bootloader" klickst wird kein Bootloader geschrieben sondern nur die Fuses entsprechend dem eingestellten Takt gesetzt.
    Den Schritt Bootloader brennen kannst du dir daher sofern du nicht den Takt verstellt hast sparen.

    Tipp: Aktiver mal unter "Einstellungen" die Ausgaben für den Upload und das Kompilieren dann zeigt die IDE genau was sie macht. ;)

    --

    Zitat

    Ein AVR mit Arduino-bootloader kann halt mit der IDE "reden" .


    Genauer gesagt mit avrdude. Das ist das programm das die IDE verwendet um Sketche auf den µc zu laden.
    Du brauchst die IDE nicht zwingend sondern kannst eigentlich auch alles händisch über die Kommandozeile machen.

    Zitat

    Jaaa... Also, eigentlich wäre für mich interessant, ob ich den Tiny mit RSTDISBL überhaupt noch flashen kann.


    Mit Bootloader (und gesetztem SELFPRGEN Fuse) ja, ohne nein.


    Fastboot hatte ich auch schon auf einem tiny13 am laufen. Ist allerdings schon ein paar Jahre her. Ich weiß noch wie erstaunt ich war dass das Hochladen der Programme so schnell ging. Den One-Wire Modus hatte ich auch mit erfolg getestet. Ich weiß jetzt nicht mehr genau wieso hab mich dann aber nicht mehr weiter damit beschäftigt. Ich weiß nur noch dass das hochladen nicht allzu zuverlässig geklappt hat. (Heute glaube ich aber dass es damals hauptsächlich an meinem wackeligen Steckbrett Aufbau lag. )

    DON'T PANIC!

  • Hi joh ...
    das passt soweit schon und deckt sich mit meinen bisherigen Ergebnissen.
    Fastboot habe ich jetzt etliche Male probiert ... leider erfolglos :( ...

    Aaaaber ... ich hab' da noch den micronucleus gefunden. Der braucht vermutlich mehr Flash, wird aber u.a. von Digispark und dem "digistump" (dieses Mini-Tiny-Entwickler-Board) verwendet.
    Da kämpf' ich allerdings auch gerade wieder ... *grumpf* ...

    Stecke ich das Digistump Dingens nach Aufforderung vom Loader ein, findet er das Board und flasht dann z.B. das Blink-Demo auf den Tiny.
    Verbinde ich aber jetzt per USB-Kabel die Pins Vcc, GND, PB3 und PB4 kann ich hin- und herstecken wie ich will ... das Board wird nicht erkannt.
    Jetzt hab' ich mir mal den Schaltplan von dem Digistump rausgesucht und dort gesehen, dass u.a. ein Pullup von 1k5 an PB3 verbaut ist.
    Aber auch mit dem funktioniert das "rückwärts" nicht :wallbash:
    Jetzt hab' ich noch die 68 Ohm Widerstände mit reingenommen und das Ganze auf einem Breadboard zusammengesteckt ... immer noch Fehlanzeige :@
    Jetzt bau' ich diesen Adapter einfach mal nach ... so mit Z-Dioden und dem Ganzen anderen Kram. Dann muss es ja gehen.

    Wenn ich das hinbekommen habe, bin ich ja mal gespannt ...

    Ach ja: wen es interessiert ... das Digistump-Board ist CC und der Schaltplan ist z.B. -> hier <- verfügbar.


    cheers,
    ich halt' Euch auf dem Laufenden ...
    -ds-

  • Hey,
    Dann ist ja gut :)

    Was ich geschrieben hab bezog sich nur auf fastboot und den "damellis" attiny core.

    Die Digitstamp Dingens kenn ich. Davon gibt es eine ganze Menge. :)
    Die funktionieren aber ganz anders. Die meisten (wenn nicht alle) dieser Boards nutzen dass hier:
    https://www.obdev.at/products/vusb/index.html

    Zitat


    V-USB is a software-only implementation of a low-speed USB device for Atmel’s AVR® microcontrollers, making it possible to build USB hardware with almost any AVR® microcontroller, not requiring any additional chip.


    Wie ich finde eines der genialsten Projekte die es überhaupt gibt. ;)

    Das ganze ist aber etwas "tricky". Ich habs nur zum laufen gebracht als ich die Versorgungsspannung angepasst habe. Mit den 3.6V Z-Dioden die ich mir extra dafür bestellt hatte hat es seltsamerweise nicht geklappt.
    Versuchs mal so: (der linke Teil) https://www.obdev.at/Images/vusb/circuit-zoomed.gif
    Dioden waren(sind) zwei 1n4148.
    Was bei mir auch geklappt hat war ein LM317 auf 3.6V eingestellt.

    Soweit ich weiß ist das Hauptproblem bei dem ganzen dass viele USB Host Controller empfindlich auf ungenaue Spannungspegel auf den Datenleitungen reagieren und deshalb den Dienst quittieren.
    Was da hilft ist einen USB Hub dazwischen zuhängen. Die sehen das wohl nicht so eng. :)
    Bei meinem alten Desktop PC hat es auch nur mit HUB dazwischen geklappt. Bei vielen(hab nur ca. 5 getetstet) anderen PCs und Laptops aber auch ohne.

    DON'T PANIC!

  • Hi,
    ja genau ... die Z-Dioden habe ich (weil nicht verbaut) auch in Verdacht.
    Naja ... 3.6 hab' ich nicht ... mal sehen, vielleicht funktionieren ja auch 3.3er.
    Das mit dem Hub ist jedenfalls ein Super-Tipp :thumbs1:

    Naja ... ich forsche da mal weiter ...
    Den Micronucleus krieg ich schon irgendwie zum Laufen ...

    //EDIT: Täterätääää ... läuft wie meine Nase ;) ...
    Einfach genial ... das Ding meldet sich als USB-Device ...
    Die Zener-Dioden waren tatsächlich der Knackpunkt ... wenn ich das gewusst hätte ...
    Naja ... passt ja ... aber jetzt ist Feierabend :)


    cheers,
    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!