MEGA8 hat scheinbar falschen Takt

[Igab]

Hallo miteinander.
mein Name ist Ingo, bin 36, Elektrotechniker und ich habe ein Problem mit meinen MEGA8 nach Programupdate.

Ich habe 4 HP-Step Schrittmotorendstufen, bestückt mit MEGA8 Prozessoren und 4MHz Quarzen.
Nach einem Update arbeiten die Prozessoren scheinbar nicht mit dem vollen Takt, was sich durch eine 3-4 fach längere Startzeit bemerkbar mach (ca. 6sek statt knapp 2Sek).
Laut Anleitung des Herstellers sollen die Fuses so gesetzt werden:
Zitat: Für den AVR Mega8 folgende Fusebits programmieren: SPIEN, BODEN, BODLEVEL, SUT1, CKSEL0..3, CKOPT.

Ich habe sie mit AVR Studio4 und AVRISP MKII so gesetzt wie im angehangenem Bild, was laut Auskunft des Herstellers der Karten auch wohl richtig sein soll.
Trotzdem habe ich das Taktproblem, scheinbar laufen die Megas auf internem Takt, aber warum?
Ich probiere jetzt schon eine Woche damit herum und suche im Web nach Lösungen, habe aber bisher nichts passendes gefunden.
Zwischenzeitlich liefen 2 Megas gar nicht mehr, die habe ich aber schon wieder am laufen.
Aus lauter Verzweiflung habe ich heute neue Prozesoren bestellt, möchte aber trotzdem gerne wissen was ich falsch gemacht habe.
Kann mir jemand helfen?

Vielen Dank für Eure Hilfe.
Viele Grüße
Ingo

 

[Hemi]

Vielleicht wurde im Makefile die falsche Frequenz eingestellt? Die Fuses sind eigentlich okay, würde ich sagen.

Grüssle
Heinrich

 

[Oskar01]

Hallo @Igab,
"Programmupdate". Hmmm.. Was wurde da upgedatet? Der AVR-Programmer oder das Programm, mit dem Du jetzt arbeitest mit den Schrittmotoren.
Hier begänne namlich das berühmte Herumstochern im Nebel.
Könntest Du einen Vergleich zwischen Originalprogramm und Update durchführen, wäre das möglich. Offenbar liegt hier nämlich "der Hund begraben".

So long....
Gruß von Oskar01

 

[Dirk]

Hallo Igab,

willkommen bei uns im AVR-PRAXiS-Forum.

Die Fusebits für die Taktquelle CKSEL0..3 (0b1111), CKOPT (0) sind richtig eingestellt.

Noch mal einige Fragen, um die Fehlerquelle ein bisschen eingrenzen zu können...

• Hast du das Applikationsprogramm ugedated, wurde an dem Programm irgendetwas geändert?
• Funktionierte vor dem Update die Motorsteuerungsplatine fehlerfrei, kann man also ein Hardwareproblem auschließen?
• Mit was wurde die Applikationssoftware geschrieben, Assembler, C ...?

Grüße,
Dirk

 

[Igab]

Ui, so viele Antworten habe ich nicht erwartet.

O.K., ich habe geahnt das ich noch was offen gelassen habe.

Also:
Programmupdate, sprich neue Software auf den MEGA8 per AVR-Studio über AVR ISP MKII (USB) verzogen, keine Fehlermeldung erhalten, alle Meldungen waren O.K..
Dann habe ich die Fusebits ausgelesen (bzw. macht AVR Studio scheinbar alleine) und wieder geschrieben (warum ich das auch immer gemacht habe, ich habe danach gelesesn das das nicht erforderlich gewesen wäre).

@ Heinrich: Was ist ein Makefile?
Ich hatte zum flashen eine .hex Datei.

@Oskar
Wie gesagt habe ich das Programm im Mega8 neu eingespielt.
Danach war die Startzeit deutlich länger.
Vorher 2 Sek. danach 6sek.
Zum Test habe ich auch die alte Version wieder installiert, auch da ist es seit dem auch 6sek.
Einen Vergleich zwischen den beiden Programmen?
Wie das? Die hex-Files vergleichen?
Der Hersteller stellt seine Software kostenlos zur Verfügung, schreibt was von Opensource in der Readme, aber eben nur auf seinen Karten.
Soll / darf ich einen Link dahin hier einstellen?

@ Dirk,
Applikationsprogramm?
meinst Du das auf dem MEGA8 oder AVR Studio oder das des ISP MKII?
Vor dem Update bestand kein Problem mit der Startzeit, Hardware dürfte also intakt sein.
Mit welcher Software das geschrieben wurde weiss ich nicht, das zur verfügung gestellte Softwareupdate, bzw. die neue Version liegt als .hex File auf der Herstellerseite zum kostenlosen Download.

Vielen Dank für eure Unterstützung !!!

Viele Grüße
Ingo

 

[Dirk]

Hallo Ingo,

ja mit Applikationsprogramm meinte ich die Software auf dem Atmega8. Du hast also nur ein hex-File vom Hersteller und die Angaben für die Einstellung der Fusebits.

Also die Fusebits stimmen so, wenn diese einmal programmiert wurden, muss man die nicht nochmal programmieren.

Seltsam ist, dass die alte Softwareversion vorher richtig lief und erst nachdem du die neue Version programmiert hast nun nicht mehr richtig läuft. Da würde ich normalerweise auf falsche Fusebit-Einstellungen tippen

Im Anhang mal die Fusebits bezüglich Taktquelle.

Dirk

 

[dino03]

Hi Ingo,

zuerst mal von mir auch "herzlich Wilkommen im Forum"

Ui, so viele Antworten habe ich nicht erwartet.

Da mußt du dich hier im Forum (je nach Thema) wohl dran gewöhnen

Programmupdate, sprich neue Software auf den MEGA8 per AVR-Studio über AVR ISP MKII (USB) verzogen, keine Fehlermeldung erhalten, alle Meldungen waren O.K..
Dann habe ich die Fusebits ausgelesen (bzw. macht AVR Studio scheinbar alleine) und wieder geschrieben (warum ich das auch immer gemacht habe, ich habe danach gelesesn das das nicht erforderlich gewesen wäre).

wenn du die Fuses liest UND DANACH wieder schreibst sollte alles so bleiben
wie vorher. Mit dem Programmer arbeite ich auch. Schnell und Problemlos.

@ Heinrich: Was ist ein Makefile?
Ich hatte zum flashen eine .hex Datei.

Ein Makefile ist zB in C eine Datei die angibt, welche anderen Dateien noch
mit dem eigenen Code zusammengepackt werden sollen und wie der ganze
Übersetzungsvorgang und die Codeerstellung ablaufen sollen. (Grob erklärt)

@Oskar
Wie gesagt habe ich das Programm im Mega8 neu eingespielt.
Danach war die Startzeit deutlich länger.
Vorher 2 Sek. danach 6sek.
Zum Test habe ich auch die alte Version wieder installiert, auch da ist es seit dem auch 6sek.
Einen Vergleich zwischen den beiden Programmen?
Wie das? Die hex-Files vergleichen?
Der Hersteller stellt seine Software kostenlos zur Verfügung, schreibt was von Opensource in der Readme, aber eben nur auf seinen Karten.
Soll / darf ich einen Link dahin hier einstellen?

1. Zu OpenSource gehört für mich auch immer der Quellcode. Sonst nennt
man sowas Freeware Die Hex-Dateien vergleichen hat keinen Nährwert.
Wenn sich an der Ausführungsgeschwindigkeit auch beim alten Proggi was
geändert hat, dann kann es logisch betrachtet nur an den Fuses liegen. Die
scheinen aber OK zu sein

So sehen die Fuses bei mir mit PonyProg aus (lies auch mal die Kommentare) ...


CodeBox Fuses

;

; ========== ATmega8 ==========

;

; * SUT1 und SUT0 (Zustand=11): Start-up Time 65ms nach Reset,

;   Einstellung für Quarzoszillator und langsam ansteigende 

;   Betriebsspannung (Tabelle 5 des Datenblattes)

; * CKSEL3-CKSEL0 (Zustand=1111): Quarzoszillator im Bereich 3-8MHz 

;   (Tabelle 4 des Datenblattes)

; * CKOPT (Zustand=1): schneller Quarzoszillator (Tabelle 4 des Datenblattes)

; * BODEN (Zustand=0): Brown-out einschalten

; * BODLEVEL (Zustand=1): Brown-out Schwelle auf 2,7V setzen

;

;  Unter Beachtung der invertierten Logik der Fuse-Bits sollte man 

;  also die Fuses so setzen wie im folgenden Bild: 

; 

; ( )7 ( )6 [ ]BootLock12 [ ]BootLock11 [ ]BootLock02 [ ]BootLock01 [ ]Lock2 [ ]Lock1

;

; [ ]S8535C [ ]WDTON (X)SPIEN [ ]CKOPT  [ ]EESAVE [X]BOOTSZ1 [X]BOOTSZ0 [ ]BOOTRST

;

; [ ]BODLEVEL [X]BODEN [ ]SUT1 [ ]SUT0 [ ]CKSEL3 [ ]CKSEL2 [ ]CKSEL1 [ ]CKSEL0

;  ______________________

; |                      |

; | [X] Bit=0  [ ] Bit=1 | ( ) -> Nicht anwaehlbar  [ ] -> Anwaehlbar

; | progr.     unprogr.  |

; |______________________|

;

Damit läuft er mit externem Quarz (bei mir 16MHz)

@ Dirk,
Applikationsprogramm?
meinst Du das auf dem MEGA8 oder AVR Studio oder das des ISP MKII?
Vor dem Update bestand kein Problem mit der Startzeit, Hardware dürfte also intakt sein.
Mit welcher Software das geschrieben wurde weiss ich nicht, das zur verfügung gestellte Softwareupdate, bzw. die neue Version liegt als .hex File auf der Herstellerseite zum kostenlosen Download.

Keine Änderungen an der Hardware, Fuses eigentlich wieder NACH dem lesen
wieder unverändert zurückgeschrieben, jetzt auch die Probleme mit dem
alten Programm. Evtl hat sich an den Fuses doch was geändert.
Läuft er doch mit internem 1MHz ? Die Fuses werden invertiert dargestellt.
Darum => gelöscht=1 , gesetzt=0.
Und von unter 2s auf ca 6s könnte der Faktor 4MHz Quarz zu 1MHz intern sein. Die Fuses muß man tlw extra einlesen. Die werden also nicht automatisch
gelesen. Wenn man einfach in die Fuses-Einstellung geht, kann es passieren,
daß man die Default-Werte des Herstellers bekommt. Also immer zuerst auf
"Read" klicken.
Der Quellcode wär schon interessant wenn es wirklich an dem Proggi liegen
sollte.

Gruß
Dinno

 

[Igab]

Hallo nochmal und danke an die beiden Willkommen heissenden.
Wenn man hier immer soviel Feedback und Hilfe bekommt soltle ich mich doch nochmal in die ganze Programmiergeschichte begeben.

Ich habe heute, wie ich nach Hause kam, schon die neuen Prozessoren vom Hersteller vorgefunden, wirklich schneller Service.
Natürlich gleich eingebaut und was soll ich sagen?
Startzeit: ihr werdet es nicht glauben: 6sec.

Also gleich angerufen kurzes Telefonat, jetzt sind die 6sec. auf einmal richtig, vorher waren es aber definitiv weniger, denn ich hatte 3 schnell startende Karten und 1 langsame, jetzt habe ich 4 langsame.

Alles etwas seltsam...

@ Dirk,
danke für die beiden Tabellen, die hab ich mir gleich ausgedruckt.

Wenn die Fuses invertiert dargestellt werden muß ich also die die ich setzen will nicht anhaken?
Dann müsste ja alles falsch gesetzt sein ausser der eigentlichen Sesonator Geschichte die ja aus einer Tabelle ausgewählt ist???
Das die Zeitänderung auf 1MHz hindeutet habe ich auch schon vermutet, mein Problem ist eben das wieder auf 4MHz zu bekommen.
Leider habe ich keine Möglichkeit die Frequenz direkt zu messen.

Ich bin mir mittlweile auch nicht mehr Sicher die Fuses nicht verändert zu haben...
Da aber die neuen Prozessoren auch so laufen weiss ich jetzt gar nicht mehr woran ich bin...

@Dino
Danke für deine Erklärungen und deinen Ponyprog Auszug.
Die Komentare geben auf jeden Fall aufschluß, teilweise verwirren sich mich aber auch: Setzen ist logisch 0 und nicht setzt ist Logisch 1?
1:1 setzen wäre wohl zu einfach, oder was hat man sich dabei gedacht? Naja, manches muß man eben so hinnehmen...

An den Quellcode werde ich vermutlich nicht herankommen, ich kann ja aber mal anfragen.

Ich denke ich werde heute abend mal die neuen Prozessoren auslesen und gucken wie die gesetzt sind.
Und dann mal etwas testen und ausprobieren.

Wie gesagt steht in der readme.txt zu dem Programm folgendes:
"Zusätzlich müssen einige Fusebits gesetzt werden, u.a. um den externen Oszillator zu aktivieren. Hinweise zu den Fusebits siehe HPSTEP11.ASM. "
"Für den AVR Mega8 folgende Fusebits programmieren: SPIEN, BODEN, BODLEVEL, SUT1, CKSEL0..3, CKOPT"

Das würde also bedeuten das diese Bits nicht gesetzt werden müssen, oder?
Alle anderen dann ja?

Naja, wie gesagt ist meine Verwirrung jetzt perfekt.

Hier mal ein Link zur Schrittmotorkarten Doku: HP-Step

Und hier die neue Software: Software 1.2.4
Da ist auch die Readme drin.

Danke für die Hilfen!!!

Viele Grüße
Ingo

 

[Dirk]

Hallo Ingo,

das mit den Fusebits kann schon sehr verwirrend sein.

Ein Fusebit ist nach Atmel programmiert, wenn es 0 ist. Nicht programmiert ist das Bit, wenn es 1 ist.

Wenn du im AVR Studio im Programmer Userinterface bei einem Fusebit einen Haken setzt, bedeutet es, dass das Bit programmiert wird, also auf 0 gesetzt wird.

Ausgeliefert wird der ATmega8 mit CKSEL3..0 = 0b0001, Taktquelle ist also der interne RC-Oszillator mit 1MHz.

Bei der Einstellung der Fusebits für die Taktquelle solltest du vorsichtig sein, wenn man nicht aufpasst, kann man sich "aussperren", zum Beispiel wenn man den externen Oszillator einstellt, du aber keinen Oszillator, sondern einen Quarz an XTAL angeschlossen hast.

Wie schon erwähnt, die Einstellungen der Fusebits für 4MHz Quarz stimmen eigentlich.

Grüße,
Dirk

 

[dino03]

Hallo Ingo,

Wenn die Fuses invertiert dargestellt werden muß ich also die die ich setzen will nicht anhaken?
Dann müsste ja alles falsch gesetzt sein ausser der eigentlichen Sesonator Geschichte die ja aus einer Tabelle ausgewählt ist???
Das die Zeitänderung auf 1MHz hindeutet habe ich auch schon vermutet, mein Problem ist eben das wieder auf 4MHz zu bekommen.
Leider habe ich keine Möglichkeit die Frequenz direkt zu messen.

Ich bin mir mittlweile auch nicht mehr Sicher die Fuses nicht verändert zu haben...
Da aber die neuen Prozessoren auch so laufen weiss ich jetzt gar nicht mehr woran ich bin...

@Dino
Danke für deine Erklärungen und deinen Ponyprog Auszug.
Die Komentare geben auf jeden Fall aufschluß, teilweise verwirren sich mich aber auch: Setzen ist logisch 0 und nicht setzt ist Logisch 1?
1:1 setzen wäre wohl zu einfach, oder was hat man sich dabei gedacht? Naja, manches muß man eben so hinnehmen...

das mit dem anhaken oder nicht hängt auch mit dem Programm zusammen,
mit dem du die Fuses setzt. Ob du dort wirklich die Bitwerte setzt oder nur
nen Haken setzt für "programmiert".

Das mit dem "programmiert=0" hängt mit dem Speichertyp zusammen. Da
werden beim Löschen die Bits auf 1 gesetzt (Ladung auf das Gate des
Speichertransistors gebracht). Wenn man dann Programmiert kann man nur
diese Ladung entfernen (Also auf 0 setzen). Das kannst Du zB mal beim
Programmspeicher eines neuen AVR sehen. Wenn du den ausliest und dann
die Daten ansiehst dann sind alle Zellen auf 0xFF (alle Bits gesetzt). Das ist
beim FLASH und beim EEPROM so. Also nicht wundern Wenn du auf Erase
klickst und ihn vollständig löscht, dann ist auch wieder alles auf 0xFF.

Bei den Fuses gibt es ein paar gefährliche Fuses ...

- RSTDISBL (Reset Disable)

damit gewinnst Du einen Portpin aber hast keinen Reset-Pin mehr. Danach
geht nur noch die Programmierung in HighVoltage-Mode. Mit nem AVRISPmk2
also nur ein einziges mal. Danach nur noch mit dem STK500! FINGER WEG !!

Das mit dem Clock auf "external Oscillator" ist zwar gefährlich aber läßt sich
notfalls noch mit Bastlermitteln beheben. Ist aber mit Arbeit verbunden

Gruß
Dino

 

[Igab]

Hallo Ihr Beiden,
danke für die Ausführungen.
Ich habe gerade eben, bevor ist eure letzten Beiträge gelesen habe noch etwas experimentiert.

Interner 8MHz Takt lässt die Startzeit auf 3sek. schrumpfen.
Demnach scheint der Prozessor tatsächlich auf 4MHz zu laufen, seht Ihr das auch so?

Bei den externen Osc. scheint ja ain Quarz gemeint zu sein, da hab ich jetzt einige Werte durchprobiert, da ändert sich nichts spürbares.
Mit der ersten Einstellungsmöglichkeit (Ext. Clock) hab ich mir letztes Wochenende mal 2 Karten lahmgelegt und erst durch anlegen des Taktes einer laufenden Karte auf XTAL wieder neu beschreiben können.

Mit Ext.RC scheint ja vermutlich ein RC-Glied als Schwingkreis gemeint zu sein, oder?

Mittlerweile habe ich das Gefühl als wenn die Startzeit von 6sec. wirklich die richtige zu sein scheint und der Hersteller seine Doku nicht überarbeitet zu haben scheint.
Er sagte was davon das die noch aus C Programmzeiten kommt, das Programm jetzt aber in Assambler geschrieben ist.
Wobei doch eigentlich Assembler die schnellere Sprache ist, oder?

Ich werde im CNC-Forum mal andere User nach der Startzeit fragen, mal sehen was da als Antwort kommt.

Danke erstmal für eure Hilfen.

Viele Grüße
Ingo

 

[dino03]

Hallo Ingo,

Interner 8MHz Takt lässt die Startzeit auf 3sek. schrumpfen.
Demnach scheint der Prozessor tatsächlich auf 4MHz zu laufen, seht Ihr das auch so?

sieht dann danach aus. Wenn das Programm aber für 4MHz geschrieben
ist sollte man nicht unbedingt im Betrieb dann 8MHz verwenden weil dann
das ganze Timing nicht mehr stimmt. Bei Schrittmotoren zB die Anfahr- und
Brems-Rampen, die maximalen Taktraten, usw.

Bei den externen Osc. scheint ja ain Quarz gemeint zu sein, da hab ich jetzt einige Werte durchprobiert, da ändert sich nichts spürbares.
Mit der ersten Einstellungsmöglichkeit (Ext. Clock) hab ich mir letztes Wochenende mal 2 Karten lahmgelegt und erst durch anlegen des Taktes einer laufenden Karte auf XTAL wieder neu beschreiben können.

- external Crystal/Ceramic-Resonator => Quarz oder Keramik-Resonator
- external RC-Oscillator => Externes RC-Glied
- internal Oscillator => Der interne eben
- external Clock => externer Oszillator/Taktgeber

Die Beschaltungen findest du in den Datenblättern. Kapitel ...
"System Clock and Clock Options". Da sind auch die Fuses dafür.

Mit Ext.RC scheint ja vermutlich ein RC-Glied als Schwingkreis gemeint zu sein, oder?

genau

Mittlerweile habe ich das Gefühl als wenn die Startzeit von 6sec. wirklich die richtige zu sein scheint und der Hersteller seine Doku nicht überarbeitet zu haben scheint.

Sowas soll schon mal vorkommen

Er sagte was davon das die noch aus C Programmzeiten kommt, das Programm jetzt aber in Assambler geschrieben ist.
Wobei doch eigentlich Assembler die schnellere Sprache ist, oder?

das kann man so nicht sagen. Wenn man in Assembler Grütze zusammentippt
kannn sogar ein schlechtes Bascom-Programm schneller sein. Ein gut
optimierter Compiler-Lauf von einem gut geschriebenen C-Programm kann
auch schnellen Code erzeugen. Asssembler hat aber den vorteil, daß man
genau vorhersagen kann was nachher im Speicher steht.

Gruß
Dino

 

[Oskar01]

Stimmt!!

Hallo,
was @Dino... soeben sagte, ist völlig richtig.
Nur zur Ergänzung:
Wenn irgendwo im Programm-"Kopfteil" .equ-Anweisungen stehen, die sich irgendwie auf die Taktfrequenz beziehen, kann ein Compiler auch mal "falsch" rechnen. Deswegen nicht zu viele derartige Variablen verwenden, lieber "zu Fuß" rechnen. D.h. die Timing bestimmenden Variablen voll ausformulieren.
Bei Zeitschleifen gibt es sonst oft Probleme, wenn "Overrun" entsteht.
Da bin ich auch mal voll drauf reingefallen.
So hatte ich die Berechnung einer 16-Bit Zeitschleife einmal dem Assembler alleine überlassen. Es kamen Rechenwerte von 900000 raus. Dabei kann ein Doppel-Register höchstens 65535 als Maximalwert verkraften. Der Assembler ist aber meistens schon so schlau und setzt dann von sich aus den Maximalwert ein.
Nur wundert man sich hinterher, wenn das gewünschte Timing nicht stimmt.


Nur, wie gesagt, kleine Ergänzung.

Gruß von Oskar01

P.S.: BASCOM-, C- oder ASM-Programmierung ist eigentlich keine Geschwindigkeitsfrage.
Wie schon von @Dino... gesagt, kommt hinterher ja ein flashbares Intel-Hex-File bei raus.
Nur, man kann aktiv und voll bewußt bei ASM die Befehlsabfolge in der Mnemonikform selber bestimmen, eventuell einiges an Programmlaufzeit einsparen, wenn alternative Befehle verwendet werden, die "schneller" zum gewünschten Ziel führen. Einige "Atomic"-Actions
sind im zugehörigen Handbuch der ATMEL-AVRs ja auch bewußt in ASM geschrieben, wenn
zum Beispiel ein U(S)ART eingerichtet wird, und die Aktion innerhalb von 4 Taktzyklen über die Bühne gehen sollte. Ebenso bei der Änderung des Watchdogs aus dem laufenden Programm heraus. Nur so als Beispiele.

 

[Igab]

Hallo Dino, hallo Oskar,
zunächst einmal Danke für eure Beiträge.

Die ganze Geschichte entstand ja jetzt nur, weil ich anfangs 3 Endstufen hatte die binnen 2sec. Startbereit wearen und eine die 6sec. brauchte.
Nach dem Update brauchten alle 6 sec., da war halt die große Frage warum.
Dazu kommt das meine Schrittverluste immer größer werden.

Die Endstufen sind in erster Linie quasi nur Befehlsempfänger und Signalverstäker, sie haben selber keinen Einfluß auf Taktraten und Flanken etc. diese Wete werden alle per Impulse als Takt- und Richtungsinformation eingespeisst und auf 4A Verstärkt in anderer Form an die Schrittmotoren ausgegeben.
Klar, wenn die Endstufe in 1/8 Schritt Betrieb mit hoher Geschwindigkleit läuft werden die Schritte bis herunter zum Vollschritt verändert und genau da dachte ich liegt der Hund begraben.
Wenn der Prozessor zu langsam ist könnten dort massive Schrittverluste entstehen.

Bisher habe ich leider noch keine Antworten andere HP-Step User was die Startzeit angeht, aber ich hoffe drauf.

Nicht jedes Forum wird mit solch engagierten Usern beglückt wie es hier der Fall ist.

Von daher muß ich sagen das ich mich hier sehr gut aufgehoben und wohl fühle.

Viele Grüße
Ingo

 

[Igab]

Hallo zusammen.
die Ergebnisse der Anfrage an andere HP-Step User sind eher mager:
2x 2sec., 1x 4sec.
Aber alle schneller als meine, warum auch immer.
Naja, wie auch immer, ich scheine die Ursache meiner Schrittverluste an der falschen Stelle gesucht zu haben, denn weit ich am USB-Controller der Frassoftwäre das Ausgangssignal invertiert habe ist es vorbei mit den Schrittverlusten.
Ich habe jetzt noch nicht ausgiebigst gestestet, aber die ersten Versuche sind sehr vielversprechend.

Nochmals vielen Dank an alle Helfer.
Ich werde mich wohl in naher Zukunft näher mit dem Thema µC bzw. AVR beschäftigen, hoffendlich kann ich dann wieder auf euch zählen.

Viele Grüße

Ingo