mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie geht USBAVR-ISP + AVRDUDE + Linux?


Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt hätt' ich auch mal 'ne kurze Frage ;-)

Ich versuche gerade, USBAVR-ISP aus

  http://www.ullihome.de/index.php/USBAVR-ISP/de

unter Linux zu benutzen, und zwar zusammen mit dem AVRDUDE. Bis jetzt
funktioniert das bei mir so gut wie nicht, aber ich bin voller
Optimimus, dass sich das bald ändern könnte :-)

Erst mal Lob und Dank an die Entwickler von AVRDUDE, den ich seit
längerem erfolgreich mit meinem Parallelportdapter benutze, und
USBAVR-ISP der diesen aus der Mode gekommenen Adpater nun ersetzen
soll. Jörg und Christian sind hier im Forum ja häufig anzutreffen.
(Ich hoffe insgeheim ein wenig, dass genau diese beiden mein
Monster-Posting lesen werden. ;-) )

Vielleicht liegt's nur an meiner eigenen Dummheit (dann geht's ganz
kurz), deswegen zwei Fragen vorweg:

- Hat jemand schon mal die Kombination USBAVR-ISP + AVRDUDE + Linux
  gebändigt? Dem folgenden Thread

    Beitrag "USB AVR ISP"

  nach zu schließen, geht USBAVR-ISP + AVRDUDE wohl generell noch
  nicht, auch nicht mit Windows, nur dass die Fensterer nicht ganz so
  sehr auf den AVRDUDE angeweisen sind.

- Gibt es unter Linux eine andere Programmer-Software, die mit
  USBAVR-ISP funktioniert? Ich kenne nur noch UISP (der seit 2,5
  Jahren nicht mehr gepflegt zu werden scheint) und Ponyprog. Von
  keinem habe ich im Netz poitive Erfahrungsberichte mit USBAVR-ISP
  gefunden.

Falls ihr eine der beiden Fragen mit Ja beantworten könnt, hat sich
alles erledigt, und ihr braucht nicht weiter zu lesen. Wenn nicht:


Ich habe mich in meiner Naivität hingesetzt und wollte einfach mal
schnell einen Tiny45 programmieren. Folgende Schritte habe ich
unternommen:

- Programmer-Board an den PC angeschlossen
  Ergebnis: Das Board wird tatsächlich als ACM-Device erkannt, und es
  erscheint ein /dev/ttyACM0

- AVRDUDE 5.4 aufgerufen mit

    avrdude -p attiny45 -c avrisp2 -P /dev/ttyACM0 -t

  um in den interaktiven Modus des AVRDUDE zu gelangen
  Ergebnis:

    avrdude: ser_send(): write error: Invalid argument

  Das gleiche passiert, wenn ich root bin.

- In Minicom "menue\n" eingegeben, um in den Terminalmodus von
  USBAVR-ISP zu gelangen. Ergebnis: Weder Terminalausgabe noch
  blinkende LED.

- AVRDUDE aufgerufen mit

    avrdude -p attiny45 -c avrisp2 -P usb -t

  weil ich irgendwo gelesen habe, dass man für das STK500 "usb" als
  Port angeben soll.
  Ergebnis:

    avrdude: usbdev_open(): did not find any USB device "usb"

- Sourcecode vom AVRDUDE angeschaut und festgestellt: -P usb
  fragt die Vendor- und ProductID von Atmel ab. Der USBAVR-ISP hat
  aber eine andere.

- Sourcecode vom AVRDUDE gepatcht, dass auch der USB-AVR-ISP erkannt
  wird. Ergebnis:

    avrdude: usbdev_open(): error setting configuration 1: could not \
    set config 1: Device or resource busy
    avrdude: usbdev_open(): did not find any USB device "usb"

- Auf http://www.obdev.at/products/avrusb/avrdoper.html gelesen, dass
  CDC mit Low-Speed die USB-Spezifikation vergewaltigt, deswegen keine
  Funktionsgarantie. Nach längerer Nachforschung festgestellt, dass
  der Linux-Kernel ab 2.6 im UHCI-Treiber dies tatsächlich abfragt und
  verhindert.

- Abfrage auskommentiert, Kernel neu gebaut
  Ergebnis:
    Terminalmodus geht
    AVRDUDE mit -P usb bringt die gleiche Meldung wie vorher
    AVRDUDE mit -P /dev/ttyACM0 meint:

      avrdude: Device signature = 0x000000
      avrdude: Yikes!  Invalid device signature.

- "Yikes, welche Überaschung!" hab' ich mir gesagt nochmals wie
  verlangt die Anschlüsse doppelt geprüft, aber ohne Erfolg.

- AVRDUDE mit -vvvv aufgrufen, STK500v2-Spezifikation runtergeladen,
  beides verglichen und stutzig geworden. Source vom USBAVR-ISP
  (stk500protocol.c) angeschaut und noch stutziger geworden:

    case STK_CMD_SPI_MULTI:
      {
      ...
        for (i = 1;i<lentx+1;i++)
        {
          if (i >= rxstart)
          {
            Buffer[STK_TXMSG_START + 1 + rxpos] = 
                ISP_transmit(progMultiParam->txData[i]);
            rxpos++;
          }
          else
            ISP_transmit(progMultiParam->txData[i]);
        }
  

  Yikes ;-), da wird ja das erste Byte von txData gar nicht an den AVR
  übertragen, laut der AVRDUDE-Ausgabe müsste aber der 4-Byte-Befehl
  zur Signaturabfrage vom in txData[0..3] landen. Die obige Routine
  überträgt aber txData[1..4] an den AVR. Ergebnis: AVRDUDE und
  USBAVR-ISP scheinen die Protokollspezifikation unterschiedlich
  auszulegen. Wie kann es dann aber sein, dass sowohl IAVR Studio mit
  USBAVR_ISP als auch AVRDUDE mit dem STK500-Board zusammenarbeiten?

- Überlegt, und zu folgender Vermutung gekommen: Das AVR Studio
  überträgt zusätzlich zu den Befehlsdaten ein führendes Nullbyte,
  vielleicht um das SPI-Datenregister auf dem Target-AVR "durchzu-
  spülen". Da es kein Kommando 0x00 gibt, wird das Byte vom AVR
  ignoriert. Wenn hingegen keine führende 0x00 (wie beim AVRDUDE)
  gesendet wird, wird eben schon das erste Byte als Kommando
  interpretiert.

- Basierend auf dieser Vermutung den AVRDUDE gepatcht, dass er die
  führende 0x00 sendet
  Ergebnis: Die drei Signaturbytes werden richtig gelesen und kommen
  beim AVRDUDE an

  RIESIG FREU

- Nun schnell mal eine Software auf den AVR zu spielen versucht
  Ergebnis (nach ein paar Sekunden ungeduldigen Wartens):

    Writing | ##        ...                      | 3% 2.48s
    avrdude: stk500v2_command(): unknown status 0x81
    avrdude: stk500v2_paged_write: write command failed

   Grrr! Also doch noch nicht.

   Den Returncode 0x81 (STATUS_CMD_TOUT, Warning: Command timed out)
   gibt's laut Spezifikation tatsächlich, wird vom AVRDUDE nur nicht
   ausgwertet. Normalerweise dürfte es aber gar nicht erst zu diesem
   Timeout kommen, da liegt wohl noch etwas anderes im Argen.


So, an der Stelle habe ich eine Frickelpause eingelegt und wollte mal
gerne die Stellungsnahme derjenigen abwarten, die sich damit
auskennen. Frickel ich überhaupt in die richtige Richtung oder habe
ich die einfache und naheliegende Lösung des Problems in meinem Eifer
vielleicht total übersehen?

Viele Dank schon mal!

PS: Falls jemand nun fragen sollte, warum ich nicht einfach den
AVR-Doper nehme: Ich brauche das Feature von USBAVR-ISP, im
Normalbetrieb des Target-AVRs bidirektional UART-Daten über USB
übertragen zu können. AVR-Doper kann das laut Webseite vom Target zum
PC, aber nicht umgekehrt.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, ich hab zwar schon gemerkt das die CDC im Linux nicht geht hab aber 
noch nicht weiter gesucht. Vorab, du bist da um Lichtjahre weiter als 
ich je gesucht hab.

Das mit dem Kerneltreiber ist echt schade damit hat sich CDC unter Linux 
wohl erledigt. Ich werde bei Gelegenheit mal einen Modus einbaun der 
über HID arbeitet da gibts ja auch 1-2 protokolle die der avrdude 
unterstützt.
oder siehst du noch ne andere Möglichkeit ohne den Kernel zu patchen ?

Den Fehler in der ISP Multi beseitige ich gleich.

>Wie kann es dann aber sein, dass sowohl IAVR Studio mit
>USBAVR_ISP als auch AVRDUDE mit dem STK500-Board zusammenarbeiten?

für avrdude kann ich das nicht beantworten aber das AVR Studio benutzt 
ISP Multi überhaupt nicht ich hab es lediglich für avrdude implementiert 
und nie getestet. Laut aussage anderer soll es unter Windows aber mal 
funktioniert haben wie kann ich nicht sagen.

>So, an der Stelle habe ich eine Frickelpause eingelegt und wollte mal
>gerne die Stellungsnahme derjenigen abwarten, die sich damit
>auskennen. Frickel ich überhaupt in die richtige Richtung oder habe
>ich die einfache und naheliegende Lösung des Problems in meinem Eifer
>vielleicht total übersehen?

Mhmm, ich bin dafür das du weiter eiferst aber auf die schnelle könntest 
du die USBasp Firmware draufspielen die benutzt einen HID Modus der auch 
von avrdude unterstützt wird. Damit lassen sich keine geschwindigkeiten 
einstellen usw aber flashen soltest damit erstmal können.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Antwort kam aber fix! Ich hätte im optimistischten Fall mit einer
Stunde gerechnet, bis jemand das Posting aufmacht, es durchliest und
dann auch noch eine Antwort schreibt.

> Das mit dem Kerneltreiber ist echt schade damit hat sich CDC unter
> Linux wohl erledigt.

Wenn ich das richtig gesehen habe, betrifft das wohl nur die Treiber
für die UHCI-Host-Controller (für Intel und VIA). Beim OHCI-Treiber
(für alle anderen Hersteller) habe ich eine entsprechende Abfrage
nicht gefunden.

> oder siehst du noch ne andere Möglichkeit ohne den Kernel zu patchen ?

Genau genommen ist nicht das CDC für Low-Speed verboten, sondern die
Bulk-Transfers. Ich habe von USB keine Ahnung, aber gibt es vielleicht
eine Möglichkeit, CDC ohne Bulk-Transfers zu implementieren? Oder wird
das zu langsam?

Ansonsten könnte man ja mal eine freundliche Anfrage an die Linux-
Entwickler richten, die Abfrage aus dem Treiber zu entfernen. Der
Linux-Kernel ist ja schließlich nicht damit beauftragt, den Standard
zu überwachen. Wenn ein Gerät standardkonform ist, wird es ohne
die Abfrage genauso funktionieren wie vorher, insofern ergeben sich
keine Nachteile. Ich werde mach nachschauen, ob es vielleicht schon
einen entsprechenden Antrag gibt.

> Den Fehler in der ISP Multi beseitige ich gleich.

> ... das AVR Studio benutzt ISP Multi überhaupt nicht ich hab es
> lediglich für avrdude implementiert und nie getestet.

Das erklärt einiges :-)

> Mhmm, ich bin dafür das du weiter eiferst ...

Ich werde mal sehen, was ich noch finden kann. Ach ja, da ist mir noch
eine Kleinigkeit aufgefallen: In Zeile 227 von stk500protocol.c steht:
          if ((i&8)==8)
            usbPoll();
Sollte das nicht eher
          if((i&7)==7)
oder (
          if(i&7)==0)
Ich nehme an, du möchtest alle 8 Schleifendurchläufe den USB bedienen.
Das ist zwar kein Bug, aber vielleicht geht das Flashen mit der
Änderung ein paar µs schneller ;-)

> ... auf die schnelle könntest du die USBasp Firmware draufspielen
> die benutzt einen HID Modus der auch von avrdude unterstützt wird.

Zum Programmieren kann ich auch meinen alten Parallelportadapter
verwenden (geht eben nicht mehr an jedem PC). Weswegen ich mich vor
allem nach etwas Neuem umgeschaut habe, ist der Wunsch, über ein
Kabel (USB) Programmieren und anschließend ohne Umstöpseln mit der
Anwendung auf dem Target kommunizieren zu können. Oder geht das mit
USBasp auch? Bisher habe ich ein Parallel- (zum Programmieren) und ein
RS-232-Kabel (zum Kommunizieren) benutzt, aber neuere Laptops haben
eben oft nur noch USB-Schnittstellen.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich nehme an, du möchtest alle 8 Schleifendurchläufe den USB bedienen.
>Das ist zwar kein Bug, aber vielleicht geht das Flashen mit der
>Änderung ein paar µs schneller ;-)

Nee, da hast du nen Denkfehler wenn ich usb nur jedes 9. mal bediene 
geht das flashen schneller. Der Wert ist aber "frei nach Schnauze" 
implementiert. Du kannst ja testen ob es mit jedem 12. oder 20. mal 
immernoch sauber funktioniert dann wirds schneller. Allerdings flash ich 
öfter mal atmega64 damit die ziemlich voll sind und die paar sekunden 
fürs flashen haben mich noch nicht gestört.

>Genau genommen ist nicht das CDC für Low-Speed verboten, sondern die
>Bulk-Transfers. Ich habe von USB keine Ahnung, aber gibt es vielleicht
>eine Möglichkeit, CDC ohne Bulk-Transfers zu implementieren? Oder wird
>das zu langsam?

Also soweit ich weiss ist CDC generell nur für Bulk Transfers gedacht, 
was macht es für einen sinn, versteh ich jetzt gar nicht. Du kannst ja 
mal dienen Patch an die Kernel Mailinglist schicken mal sehn was 
passiert.

>ohne Umstöpseln mit der
>Anwendung auf dem Target kommunizieren zu können. Oder geht das mit
>USBasp auch?

nein, natürlich nicht dazu wäre die CDC ja auch zwingend erforderlich 
...
Oder wärs für dich auch OK über HID z.b. libusb mit deinem Target zu 
komunizieren ? Das könnt ich bei der HID Implementierung mit machen...

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Ich nehme an, du möchtest alle 8 Schleifendurchläufe den USB
>> bedienen. Das ist zwar kein Bug, aber vielleicht geht das Flashen
>> mit der Änderung ein paar µs schneller ;-)
>
> Nee, da hast du nen Denkfehler wenn ich usb nur jedes 9. mal bediene
> geht das flashen schneller.

Ob jedes 8. oder 9. Mal, spielt sicher keine große Rolle. Aber
((i&8)==8) ist wahr für i==0bxxxx1xxx, also für 8, 9, 10, 11, 12, 13,
14, 15, dann wieder für 24, 25, 26, 27, 28, 29, 30, 31 usw.
Du rufst also usbPoll() in sehr ungleichen Zeitabständen auf, was
sicher nicht beabsichtigt ist.

> Oder wärs für dich auch OK über HID z.b. libusb mit deinem Target zu
> komunizieren ? Das könnt ich bei der HID Implementierung mit
> machen...

Das wäre fast genauso gut. Das einzige, was damit nicht geht, wäre die
Kommunikation über ein Terminalprogramm, aber darauf könnte ich auch
verzichten.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Du rufst also usbPoll() in sehr ungleichen Zeitabständen auf, was
>sicher nicht beabsichtigt ist.

Ist mir vorhin auch aufgefallen, mir kommt das auch etwas unbekannt 
naja.
Beim pagemode müsste manns eh viel seltener aufrufen auf die schnelle 
fällt mir dazu aber auch nix wirklich Geniales ein.

>Das wäre fast genauso gut. Das einzige, was damit nicht geht, wäre die
>Kommunikation über ein Terminalprogramm, aber darauf könnte ich auch
>verzichten.

ist notiert ich weiss aber nicht wann ich dazu komm das mal zu 
implementiern.Ist eigentlich kein großes ding aber die paar Stunden 
wolln auch abgezwackt sein.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ist notiert ich weiss aber nicht wann ich dazu komm das mal zu
> implementiern.Ist eigentlich kein großes ding aber die paar Stunden
> wolln auch abgezwackt sein.

Nur keine Eile, aber ich danke dir schon mal für deine Bereitschaft!
Mit dem Abzwacken der Stunden habe ich gerade auch so meine Probleme.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zur USB bulk endpoint Problematik siehe auch: 
http://sourceforge.net/mailarchive/message.php?msg...

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Hintergrundinformation!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:

>> ... das AVR Studio benutzt ISP Multi überhaupt nicht ich hab es
>> lediglich für avrdude implementiert und nie getestet.
>
> Das erklärt einiges :-)

Das ist praktisch historischer Ballast bei avrdude.  avrdude hat ja
mal als ISP-Programmiersoftware angefangen, die das komplette ISP
selbst macht (an einfachen Parallelport-Dongles).  Als dann jemand
(ich glaube, es war Brian Dean selbst) STK500-Support gebraucht hat,
hat er das implementiert, indem er die existierende ISP-Implementierung
in SPI-Multi-Kommandos des STK500 umgesetzt hat. :-/  Manches davon
ist zwar mittlerweile in echte STK500-Kommandos gewandelt worden
(zum Beispiel alles, was als paged operation ablaufen kann/muss),
aber einige Überreste des alten SPI-Multi-Salats sind halt immer noch
da.

Wenn das jemand in echte STK500-Kommandos umwandeln will: nur zu!

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@yalu

Done.
In der Bootloader Software ist jetzt ne USBasp kompatible Firmware dabei 
die aus jedem aktuelleren avrdude nutzbar sein sollte die hat auch 
entsprechende Bootloaderspezifische Erweiterungen und die 
Debugschnittstelle ist auch drüber nutzbar. Ich mach noch n kleines 
Beispielprogramm wie man mit libusb an die Debugschnittstelle rankommt. 
Wenn dus schneller haben willst kannst du dir die nötigen infos auch aus 
dem Firmware Source holen...

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, hört sich gut an!

Ich werd's am Wochenende mal ausgiebig testen, vorher komme ich leider
nicht dazu, weil ich die meiste Zeit außer Haus bin.

> Wenn dus schneller haben willst kannst du dir die nötigen infos auch
> aus dem Firmware Source holen...

Wie gesagt, vor Wochenende passiert sowieso nix, dann werde ich
schauen, was schon alles tut :-)

Auf jeden Fall schon mal vielen Dank für die Arbeit, die du
reingesteckt hast und die sicher nicht wenig war. Ich bin gespannt
auf's Wochenende ...

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joa, kannst mich ja dann per mail anschreiben zu den details.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, jetzt:

Ich habe jetzt deine neue Firmware kompiliert und auf einen Mega168
gespielt. Hat ein Bisschen gedauert, weil ich erst rausfinden musste,
welches die für meinen Zweck richtigen Quellcodemodule und Defines
sind. Das steht ja alles in den aps-Dateien, wie ich irgendwann
rausgefunden habe, da ich aber kein AVR-Studio habe, musste ich mich
von Hand durch den XML-Code wühlen. Mit den richtigen Informationen
wurde das Programm aber ohne Probleme gebaut.

Der avrdude -c usbasp hat den Programmer dann auch sofort erkannt, nur
nicht den als Target angeschlossenen Tiny13, was aber an dem relativ
hohen defaultmäßigen SPI-Takt von 750 kHz lag.

Als ich den kleiner gemacht habe, funktionierte alles perfekt! Und das
ohne jegliche Patches an deiner Firmware, am avrdude oder am
Linux-Kernel. So gefällt mir das :-)

Als Nächstes wollte ich die Ausgabe von Debug-Informationen über die
serielle Schnittstelle des Targets testen. Wie ich deinem Quellcode
entnommen habe, werden die vom Programmer über den UART empfangenen
Zeichen gepuffert und über den USB ausgegeben. Ich muss mich jetzt mal
USB- und libusb-mäßig etwas schlauer machen. Dann wollte ich ein
kleines Programm schreiben, das diese Zeichen auf dem Bildschirm
ausgibt.

Aber da gibt es ja noch das AVRISPTool, zu dem ich bisher nur den
Quellcode und ein paar Screenshots gefunden habe. Es scheint in
Freepascal geschrieben zu sein, was auf meinem Rechner aber (noch)
nicht installiert ist. Da gibt es die Möglichkeit, verschiedene
Parameter des Programmers zu setzen. Und in folgendem Screenshot

  http://www.ullihome.de/images/Avrisptool4.png

ist rechts unten ein leeres weißes Feld zu sehen. Werden hier
vielleicht die Debug-Daten angezeigt? Wenn ja, werde ich mir den
Quellcode mal etwas näher ansehen (obwohl mein Pascal schon vor
Urzeiten ausgetrocknet ist :_)) und den Freepascal-Compiler saugen.

Geht die serielle Übertragung eigentlich auch anders herum, also vom
PC über den Programmer zum Target?

Auf jeden Fall noch einmal vielen Dank für deine Arbeit. Ich glaube,
dass das mein künftiger Standard-Programmer werden wird, da er alles
hat, was ich mir von so einem Teil erhoffe und ich mittlerweile auch
etwas Einblick in seine Interna habe. Ich muss mir nur noch die
Hardware ordentlich aufbauen (Im Moment habe ich nur eine geliehene
und eine breadboardbasierte :-)).

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich muss mich jetzt mal
USB- und libusb-mäßig etwas schlauer machen. Dann wollte ich ein
kleines Programm schreiben, das diese Zeichen auf dem Bildschirm
ausgibt.

Ja, ist aber kein grosses problem den Code kannst fast komplett aus dem 
AVR-ISP Tool übernehmen endweder du stutzt ihn nur zurecht und machst ne 
kleine freepascal kommandozeilen app.
oder du übersetzt dir das ganz noch nach c was auch in 5 min erledigt 
sein sollte...
wenn du probleme hast sags ruhig dann mach ich mal n sample.

>Aber da gibt es ja noch das AVRISPTool, zu dem ich bisher nur den
>Quellcode und ein paar Screenshots gefunden habe.

Da hast aber schlecht geguckt :p

http://www.ullihome.de/index.php/USBAVR-ISP-Downlo...

Da findest Windows und Linux Versionen vom AVR-ISP Tool macOS kommt 
nächste Woche vielleicht da hab ich noch etwas Probleme mit libusb

>Es scheint in
>Freepascal geschrieben zu sein, was auf meinem Rechner aber (noch)
>nicht installiert ist.

jain, genauer ist es mit Lazarus geschrieben das ist quasi n 
Plattformunabhängiges Delphi welches Freepascal als compiler verwendet. 
lazarus.freepascal.org da gibts packages für linux, windows und macos.

>Da gibt es die Möglichkeit, verschiedene
>Parameter des Programmers zu setzen. Und in folgendem Screenshot
>http://www.ullihome.de/images/Avrisptool4.png
>ist rechts unten ein leeres weißes Feld zu sehen. Werden hier
>vielleicht die Debug-Daten angezeigt?

Ja

>Wenn ja, werde ich mir den
>Quellcode mal etwas näher ansehen (obwohl mein Pascal schon vor
>Urzeiten ausgetrocknet ist :_)) und den Freepascal-Compiler saugen.

Naja Pascal ist ja gut genug lesbar als das es jeder der mal n bissle 
programmiert hat lesen können sollte

>Geht die serielle Übertragung eigentlich auch anders herum, also vom
>PC über den Programmer zum Target?

ja ist in der firmware implementiert nur im avr-isp tool noch net

>Auf jeden Fall noch einmal vielen Dank für deine Arbeit. Ich glaube,
>dass das mein künftiger Standard-Programmer werden wird, da er alles
>hat, was ich mir von so einem Teil erhoffe und ich mittlerweile auch
>etwas Einblick in seine Interna habe. Ich muss mir nur noch die
>Hardware ordentlich aufbauen (Im Moment habe ich nur eine geliehene
>und eine breadboardbasierte :-)).

Joa, gibt ja auch schon n paar andere Firmwares und ist kaum noch Arbeit 
ne neue Firmware zu implementieren wenn man mal was braucht hab letzte 
woche in 4h nen i2c logger dazugebastelt.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.