mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Bodlevel und Boden-Fuse bei Attiny15


Autor: Sigmar Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo
Ich komme mit dem Datenblatt respektive mit Ponyprog nicht zu Rande.
Der Attiny15 soll so laufen, daß eine Spannungsschwankung von +Ub
NICHT zu Reset des Prozessors führt. Weiterhin soll er mit dem 
werksseitigen Takt von 1,6 MHz laufen.
Wie muß ich das bei Ponyprog einstellen?

Gruß
Sigmar

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigmar Walter wrote:
> Hallo
> Ich komme mit dem Datenblatt respektive mit Ponyprog nicht zu Rande.
> Der Attiny15 soll so laufen, daß eine Spannungsschwankung von +Ub
> NICHT zu Reset des Prozessors führt.

So wird er ausgeliefert, Du musst also nichts ändern.

> Weiterhin soll er mit dem
> werksseitigen Takt von 1,6 MHz laufen.

Dann musst Du das individuelle Calibrationsbyte dieses Exemplars mit 
einem ISP-Programm einlesen und auf geeignete Art und Weise in Dein 
AVR-Programm einbinden, welches es beim Reset in das Register OSCCAL 
einzutragen hat.

Dazu gibt es viele Möglichkeiten, ich mache es meist so, wie in den 
Projekten mit Tiny15 hier beschrieben ist:
http://www.hanneslux.de/avr/index.html

> Wie muß ich das bei Ponyprog einstellen?

Das entzieht sich meiner Kenntnis, da ich dieses Programm nicht benutze.

>
> Gruß
> Sigmar

...

Autor: Sigmar Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,
ich habe hier 2 Stück Attiny15, die zwar beide neu waren aber dennoch 
unterschiedliche Fuse - Einstellungen besaßen. Im Datenblatt fand ich 
jetzt auch die Einstellungen für den Auslieferungszustand. Der 1. war 
nicht so, aber der 2. war "´wie neu".

So, aber als ich das Kalibrationsbyte auslas, hatte der eine hex.83 drin
stehen und der andere hex.88. Es kann doch nicht Sinn der Sache sein, 
daß man für jeden MC das Programm ändern muß, denn das Kalibrationsbyte 
steht im EEprom und ich müßte ja für jeden ein extra .eep-File 
"basteln".
Wenn man eine Serienfertigung damit machen wollte, würde man ja verrückt 
werden. ;-)
Ich habe es jetzt tatsächlich erst mal so gemacht und es laufen beide, 
wie sie sollen, aber geht das nicht einfacher?

Gruß
Sigmar

Autor: Sigmar Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich war auf Deiner Seite und habe mir angesehen, wie Du das mittels 
Programmierprogramm gelöst hast. Die Erklärungen zum Tongenerator mit 
Tiny15 sind prima.
Eine Frage allerdings noch: Wenn ich BODEN auf 0 setze und BODLEVEL auf 
1
müßte er doch erst bei einer Spannung <2,7 Volt (Datenblatt) 
"zusammenzucken" und Reset auslösen und bei BODLEVEL auf 0
bei <4 Volt. Habe ich das richtig verstanden?


Gruß
Sigmar

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigmar Walter wrote:
> Hallo Hannes,
> ich habe hier 2 Stück Attiny15, die zwar beide neu waren aber dennoch
> unterschiedliche Fuse - Einstellungen besaßen. Im Datenblatt fand ich
> jetzt auch die Einstellungen für den Auslieferungszustand. Der 1. war
> nicht so, aber der 2. war "´wie neu".
>
> So, aber als ich das Kalibrationsbyte auslas, hatte der eine hex.83 drin
> stehen und der andere hex.88.

Das ist normal, das sind Fertigungstoleranzen. Die Chips werden geprüft, 
ausgemessen, und das ermittelte exemplarabhängige Calibrationsbyte in 
das
- H-Byte des Signature-Space (nichtflüchtig, also unverlierbar),
- in das H- und L-Byte der letzten Flashzelle (löschbar) und in
- die letzte EEPROM-Zelle (löschbar)
geschrieben.

> Es kann doch nicht Sinn der Sache sein,
> daß man für jeden MC das Programm ändern muß,

Muss man ja auch nicht. Man kann ja das Programm mit einer Routine 
ausstetten, die das letzte Byte des Flash in das Register OSCCAL 
kopiert. Denn bei jedem neuen Tiny15 steht ja das Calibrationsbyte 
bereits im Flash. Allerdings sollte man sein ISP-Programm so einstellen, 
dass es vor dem Brennen den Flash nicht löscht.

> denn das Kalibrationsbyte
> steht im EEprom und ich müßte ja für jeden ein extra .eep-File
> "basteln".

Das steht nicht nur im EEP, sondern auch im Flash! Es braucht also kein 
EEP-File.

> Wenn man eine Serienfertigung damit machen wollte, würde man ja verrückt
> werden. ;-)

Nö, bei Serienfertigung nimmt man vernünftiges Werkzeug. Da kann man 
einstellen, dass vor dem Brennen das Calibrationsbyte aus dem 
Signature-Space geholt wird und kann auch einstellen, wo es hinkopiert 
werden soll (Adresse im Flash oder EEP). Die Calibration erfolgt daher 
vollautomatisch. Den Rest erledigt dann das AVR-Programm bei jedem 
Reset.

Auch mit Pony geht das. Pony bietet irgendwo im Menü die Option, das 
Calibrationsbyte aus dem Signature-Space des gerade angeschlossenen AVRs 
auszulesen. Und Pony zeigt den Hexdump des zu brennenden Codes an. Wer 
hindert Dich daran, vor jedem Brennen das Calibrationsbyte auszulesen 
und in die beiden letzten Bytes des Hexdumps einzutragen? Das ist eine 
Sache von Sekunden.

> Ich habe es jetzt tatsächlich erst mal so gemacht und es laufen beide,
> wie sie sollen, aber geht das nicht einfacher?

Sicher geht das einfacher, man nehme vernünftiges Werkzeug.

---------

> Ich war auf Deiner Seite und habe mir angesehen, wie Du das mittels
> Programmierprogramm gelöst hast. Die Erklärungen zum Tongenerator mit
> Tiny15 sind prima.
> Eine Frage allerdings noch: Wenn ich BODEN auf 0 setze und BODLEVEL auf
> 1
> müßte er doch erst bei einer Spannung <2,7 Volt (Datenblatt)
> "zusammenzucken" und Reset auslösen und bei BODLEVEL auf 0
> bei <4 Volt. Habe ich das richtig verstanden?

Bei Fuses entspricht (historisch und technologisch bedingt) eine 0 (L) 
einer gesetzten (aktivierten) Fuse und eine 1 (H) eine gelöschte, 
deaktivierte Fuse. Dies steht auch ausdrücklich in einer Fußnote im 
Datenblatt bei den Fuses.

Mit BODEN=0 (L, aktiv) schaltest Du BOD ein

Seite 17 meines Datenblattes sagt zu BOD-Level:

The trigger level for the BOD can be selected by the fuse BODLEVEL to be 
2.7V (BODLEVEL unprogrammed), or 4.0V (BODLEVEL programmed).

Also:

2,7V = 1, H, unprogrammiert
4,0V = 0, L, programmiert

Und wie Pony eine programmierte Fuse darstellt, musst Du selbst 
ergründen, ich benutze Pony nicht und weiß daher nicht bescheid.
Ich benutze mal meinen Eigenbau und mal AVR-Studio (mit STK500), da ist 
das eindeutiger.

Achja, ich habe mal hier im Forum gelesen, dass Pony die Fuses nicht 
automatisch einlesen soll. Du solltest also vor jeder 
Fusebit-Manipulation die aktuellen Fuses von Hand einlesen. anderenfalls 
hast Du Reset mal schnell zum Portpin umgeschaltet, dann geht ISP nicht 
mehr.

...

Autor: Sigmar Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Hannes für Deine ausführlichen Erläuterungen. Ich bin noch nicht 
der
geübteste Mann im Umgang mit den AVR´s. Eigentlich bin ich nur 
Modellbahner
und wollte "mal so" den DCC-Decoder von Maddax aus dem 
Codesammlungsforum
bauen, was ich dann auch mit der Platine nach Paul und dessen letzter 
Programmänderung getan habe. Ich hatte aber mit einem Motor Probleme, 
der
Spannungseinbrüche verursachte und den Prozessor rücksetzte. Da kam ich 
nach Suchen mit dem Oszillographen dahinter und nachdem ich ein wenig in 
dem Datenblatt des Tiny15 gelesen hatte, sah ich, daß man díe 
Resetschwelle
ändern kann. Das Ponyprog macht alles genau "verkehrt herum". :-( Da muß 
man erst mal drauf kommen.
Assembler ist schwer zu lernen, trotzdem will ich mal versuchen, das 
Programm so zu ändern, daß er das Kalibrationsbyte automatisch herholt 
und dahin speichert, wo es das Programm erwartet. Der Befehl LDS scheint 
gut dafür zu sein, mal sehen.

Schönen Abend noch an Dich und ich schauen meiner Lok noch ein wenig zu.

Sigmar

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigmar Walter wrote:
> Danke Hannes für Deine ausführlichen Erläuterungen.

Nix zu danken.

> Ich bin noch nicht
> der
> geübteste Mann im Umgang mit den AVR´s.

Waren wir alle mal, ist da kein Problem.

> Eigentlich bin ich nur
> Modellbahner

Schau mal auf /gbahn auf meiner Startseite. ;-)

> und wollte "mal so" den DCC-Decoder von Maddax aus dem
> Codesammlungsforum
> bauen, was ich dann auch mit der Platine nach Paul und dessen letzter
> Programmänderung getan habe. Ich hatte aber mit einem Motor Probleme,
> der
> Spannungseinbrüche verursachte und den Prozessor rücksetzte. Da kam ich
> nach Suchen mit dem Oszillographen dahinter und nachdem ich ein wenig in
> dem Datenblatt des Tiny15 gelesen hatte, sah ich, daß man díe
> Resetschwelle
> ändern kann. Das Ponyprog macht alles genau "verkehrt herum". :-( Da muß
> man erst mal drauf kommen.

Bei einer älteren Pony-Version stand das aber am Fuse-Dialog dran.

> Assembler ist schwer zu lernen,

Ich persönlich finde ASM (auf dem AVR, nicht auf dem PC oder anderen 
Plattformen!) einfacher und vor allem eindeutiger als BASIC.

> trotzdem will ich mal versuchen, das
> Programm so zu ändern, daß er das Kalibrationsbyte automatisch herholt
> und dahin speichert, wo es das Programm erwartet. Der Befehl LDS scheint
> gut dafür zu sein, mal sehen.

Nein, LDS lädt aus SRAM (hat der Tiny15 nicht) und aus memory-mapped 
Bereichen, also Register und I/O-Bereich.

Du willst aber aus dem Flash (Program-Memory) laden, da brauchst Du LPM.

Die Routine, die Du brauchst, sieht so aus:
;--- Calibration des internen RC-Oszillators.
;    Kann bei Betrieb mit Quarz entfallen...
;
;Das Calibrationsbyte muss von der Programmer-Software aus dem Signature-
;Bereich des AVR gelesen werden und in das Low-Byte der letzten
;Flash-Zelle geschrieben werden.

 ldi zl,low(2*flashend)     ;Adresse auf Kalibrationsbyte L
 ldi zh,high(2*flashend)    ;und H 
 lpm                        ;Kalibrationsbyte lesen
 ser zl                     ;Referenz für Vergleich auf Gültigkeit
 cpse r0,zl                 ;Kalibrationsbyte gültig? (nein wenn $ff...)
 out osccal,r0              ;ja, Chip kalibrieren...
;--- Ende Calibration...

Die Routine gehört an den Anfang der Reset-Routine. Sie lädt das Byte 
aus dem Flash mit LPM über den Z-Pointer, prüft es auf $FF (dann ist es 
ungültig, also die Flash-Zelle leer, weil der Operator es nicht 
reinkopiert hat) und schreibt es bei Gültigkeit ins Tuning-Register des 
Taktgebers.

Tip: Wenn Du in AVR-Studio mit ASM arbeitest, kann die F1-Taste sehr 
hilfreich sein, wenn der Textcursor auf einem ASM-Befehl platziert ist.


>
> Schönen Abend noch an Dich und ich schauen meiner Lok noch ein wenig zu.

Geht da dito. Ich muss noch 'nen Fahrtregler für Gartenbahn bauen.

>
> Sigmar

...    <---  (was soviel heißt wie: Beste Grüße, Hannes)

Autor: Sigmar Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch ein Verständnisproblem mit dem Stück Programm:

ldi zl,low(2*flashend)     ;Adresse auf Kalibrationsbyte L
       ldi zh,high(2*flashend)    ;und H
       lpm                        ;Kalibrationsbyte lesen
 ===>  ser zl                     ;Referenz für Vergleich auf Gültigkeit
    cpse r0,zl                 ;Kalibrationsbyte gültig? (nein wenn 
$ff...)
 out osccal,r0              ;ja, Chip kalibrieren...

Es wird die Adresse, an der das Kalibrationsbyte sitzt in das 
Doppelregister Z geladen. Dann wird das Kalibratonsbyte gelesen. Das 
sitzt dann im Register R0. ABER DANN wird der niederwerige Teil vom 
Z-Register mit Einsen voll geladen, so daß der nachfolgende Vergleich 
Cpse immer schief geht und er immer FF in das Register OSccal schreibt. 
Wo denke ich hier falsch?

Gruß
Sigmar

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigmar Walter wrote:
> Ich habe noch ein Verständnisproblem mit dem Stück Programm:
>
> ldi zl,low(2*flashend)     ;Adresse auf Kalibrationsbyte L
>        ldi zh,high(2*flashend)    ;und H
>        lpm                        ;Kalibrationsbyte lesen
>  ===>  ser zl                     ;Referenz für Vergleich auf Gültigkeit
>     cpse r0,zl                 ;Kalibrationsbyte gültig? (nein wenn
> $ff...)
>  out osccal,r0              ;ja, Chip kalibrieren...
>
> Es wird die Adresse, an der das Kalibrationsbyte sitzt in das
> Doppelregister Z geladen.

Das Doppelregister Z ist ein Pointer (Suchbegriff für Datenblatt), es 
zeigt also auf die Adresse, auf die der pointerorientierte Befehl LPM 
zugreifen soll.

Die Konstante "flashend" wird in der Include-Datei (die der Hersteller 
mitliefert) definiert und gibt die letzte Adresse des Flash (also das 
Flash-Ende) an. Das Verwenden dieser Konstante spart das jeweilige 
Errechnen, denn es gibt auch größere AVRs, die calibriert werden. Siehe 
dazu auch die entsprechende AppNote bei ATMEL.

Es wird also die Adresse der letzten Flash-Zelle in den Pointer Z 
geladen, aber mal 2, weil der Flash 16-Bit-organisiert ist, LPM aber nur 
8-Bit. Das untere Bit in ZL wählt bei LPM das Byte aus (oberes oder 
unteres). Flashend * 2 zeigt also auf das Low-Byte der letzten Adresse.

> Dann wird das Kalibratonsbyte gelesen. Das
> sitzt dann im Register R0.

Richtig. Und es hat dann irgendeinen Wert in der Mitte des 
Zahlenbereichs, eben einen gültigen Calibrationswert. Ist dieser Wert 
aber $FF (255), dann ist davon auszugehen, dass das einfach nur der Wert 
der "leeren" Flash-Zelle war, denn eine "leere" Flash-Zelle hat 
(technologisch bedingt) gesetzte Bits (keine gelöschten), enthält also 
$ffff (65535, leer) und nicht 0.

> ABER DANN wird der niederwerige Teil vom
> Z-Register

Das Z-Register hat (nach LPM) seine Aufgabe als Pointer erfüllt und ist 
nun wieder frei für andere Zwecke verfügbar. Es liegt also nahe, es zu 
benutzen. Man hätte auch jedes andere obere Register (r16..r31) benutzen 
können.

> mit Einsen voll geladen,

Ja, mit Einsen, weil ein ungültiges Calibrationsbyte aus lauter Einsen 
besteht.

> so daß der nachfolgende Vergleich
> Cpse immer schief geht

CPSE = CpmPare, Skip if Eaquel (Vergleiche, überspringe wenn gleich)

Es wird also der Inhalt von r0 (also das mit LPM gelesene 
Calibrationsbyte) mit dem Inhalt von ZL (dem Wert 255) verglichen und 
bei Gleichheit (Calibrationsbyte = 255) das Schreiben nach OSCCAL 
übersprungen.

> und er immer FF in das Register OSccal schreibt.

Nein, es wird ja das Schreiben von r0 nach OSCCAL übersprungen, wenn r0 
255 enthält, also ungültig ist, weil der Bediener des ISP-Programms 
vergessen hat, das Calibrationsbyte aus dem Signature-Space in das 
Low-Byte der letzten Flash-Zelle zu kopieren...

Du kannst den ganzen Mist auch vereinfachen, bist dann aber nicht 
flexibel, wenn das Programm auf mehreren Exemplaren laufen soll:
 ldi r16,$83        ;das individuelle Calibrationsbyte Deines AVRs
 out osccal,r16     ;ins Trimmregister schreiben

Dann musst Du aber den Programmcode bei jedem Exemplar anpassen.

Du kannst auch aus meiner Routine die Überprüfung auf $FF rauswerfen, 
aber dann kann es passieren, dass durch ein vergessenes Eintragen des 
Calibrationsbytes mit 255 calibriert wird, was vermieden werden muss, da 
es zur Übertaktung führt und Probleme beim EEP-Zugriff (und 
Flash-Zugriff) geben soll. Um diese Probleme zu verhindern, ist dieser 
Vergleich drin.

> Wo denke ich hier falsch?

Ich hoffe, es ist jetzt verständlicher.
Auch das Benutzen des Simulators des AVR-Studios könnte beim 
Nachvollziehen solcher kleinen Routinen sehr hilfreich sein. ;-)

>
> Gruß
> Sigmar

...

Autor: Sigmar Walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, jetzt habe ich´s begriffen. Hinter dem letzten Befehl "out 
osccal..." müßte dann aber noch irgend eine Marke stehen, damit er nicht 
"in´s Leere" springt.
Den Quelltext habe ich als.asm-Datei in das AVR Studio eingelesen aber 
simulieren kann ich nicht, weil etliche Fehler erscheinen:
C:\Versuch.asm(1): error: Undefined symbol: zl
C:\Versuch.asm(1): error: Undefined symbol: flashend
C:\Versuch.asm(1): error: Invalid register
C:\Versuch.asm(2): error: Undefined symbol: zh
C:\Versuch.asm(2): error: Undefined symbol: flashend
C:\Versuch.asm(2): error: Invalid register
C:\Versuch.asm(4): error: Undefined symbol: zl
C:\Versuch.asm(4): error: Invalid register
C:\Versuch.asm(5): error: Undefined symbol: zl
C:\Versuch.asm(5): error: Invalid register
C:\Versuch.asm(6): error: Undefined symbol: osccal

Ich dachte, die Namen der Befehle und Register sind genormt und das 
AVR-Studio würde sie kennen. :-(

Bisher konnte ich mit dem AVR-Studio nur mit vorhandenen .asm-Files ein
Projekt anlegen und das dann übersetzen lassen. (Hat mir ein ehemaliger 
Kollege beigebracht) Den Simulator habe ich nie in Gang bekommen, so daß 
ich die Dateien .hex und.eep zum Ausprobieren immer in den MC 
"´gebrannt" habe.

Auf jeden Fall habe ich erst mal das AVR-Assembler Tutorial im Netz 
gefunden. Da wird man auch geholfen ;-)

Gruß
Sigmar

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigmar Walter wrote:
> Aha, jetzt habe ich´s begriffen. Hinter dem letzten Befehl "out
> osccal..." müßte dann aber noch irgend eine Marke stehen, damit er nicht
> "in´s Leere" springt.

Warum soll da eine Marke stehen? Skip überspringt den OUT-Befehl. Der 
Programmcode geht dahinter weiter, denn Du hast ja sicher auch noch 
einige Dinge zu initialisieren, oder?

> Den Quelltext habe ich als.asm-Datei in das AVR Studio eingelesen aber
> simulieren kann ich nicht, weil etliche Fehler erscheinen:
> C:\Versuch.asm(1): error: Undefined symbol: zl
> C:\Versuch.asm(1): error: Undefined symbol: flashend
> C:\Versuch.asm(1): error: Invalid register
> C:\Versuch.asm(2): error: Undefined symbol: zh
> C:\Versuch.asm(2): error: Undefined symbol: flashend
> C:\Versuch.asm(2): error: Invalid register
> C:\Versuch.asm(4): error: Undefined symbol: zl
> C:\Versuch.asm(4): error: Invalid register
> C:\Versuch.asm(5): error: Undefined symbol: zl
> C:\Versuch.asm(5): error: Invalid register
> C:\Versuch.asm(6): error: Undefined symbol: osccal
>
> Ich dachte, die Namen der Befehle und Register sind genormt und das
> AVR-Studio würde sie kennen. :-(

Sind sie auch. Und sie werden dem Assembler über die mitgelieferten 
Include-Dateien bekannt gemacht. Diese musst Du aber auch einbinden. Was 
ich Dir hier gab, war kein komplettes Programm, sondern eine einzelne 
Routine (Sequenz von zusammengehörenden Befehlen). Damit die läuft, muss 
sie in einen Programm-Body integriert werden. Siehe die Beispiele auf 
meiner HP.

>
> Bisher konnte ich mit dem AVR-Studio nur mit vorhandenen .asm-Files ein
> Projekt anlegen und das dann übersetzen lassen. (Hat mir ein ehemaliger
> Kollege beigebracht) Den Simulator habe ich nie in Gang bekommen, so daß
> ich die Dateien .hex und.eep zum Ausprobieren immer in den MC
> "´gebrannt" habe.

Ok, aber diese (fremden) ASM-Dateien hatten sicher auch die 
Portdefinitionen per .include eingebunden, oder?

>
> Auf jeden Fall habe ich erst mal das AVR-Assembler Tutorial im Netz
> gefunden. Da wird man auch geholfen ;-)

Das hier?
http://www.mikrocontroller.net/articles/AVR-Tutorial
Das sollte eigentlich zur Pflichtlektüre gehören.

>
> Gruß
> Sigmar

Gruß,
Hannes

Autor: Sigmar Walter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Hannes,

das kommt davon, wenn man gleich losstürzt, ohne zu wissen, was man 
eigentlich macht. (Alter Trottel ich!)
Ich habe das Tutorial gemeint:
http://www.avr-asm-tutorial.net/avr_de/index.html

Jetzt habe ich auch noch eine "Bedienungsanleitung" für das AVR-Studio 
gefunden:
http://www.talentraspel.de/portal/index.php?id=199...

...und gleich die Nerven verloren und mal etwas ausprobiert. ;-)
(Siehe Anhang)
Mein erstes eigenes Programm (STOLZ!!)

Du hast mir Appetit gemacht.

Schöne Pfingsten.

Gruß
Sigmar


Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sigmar Walter wrote:
> Hallo Hannes,
>
> das kommt davon, wenn man gleich losstürzt, ohne zu wissen, was man
> eigentlich macht. (Alter Trottel ich!)

Grins...

> Ich habe das Tutorial gemeint:
> http://www.avr-asm-tutorial.net/avr_de/index.html

Das hat sich aber rausgemacht!!! Das war auch mein Anfang, aber offline 
und mit dem Stand von vor einigen Jahren, da war es noch sehr 
spartanisch.

>
> Jetzt habe ich auch noch eine "Bedienungsanleitung" für das AVR-Studio
> gefunden:
> http://www.talentraspel.de/portal/index.php?id=199...

Naja, das AVR-Studio ist schon recht komplex. Und seitdem es auch den 
GCC unrerstützt, ist es völlig überladen. Schade eigentlich...

>
> ...und gleich die Nerven verloren und mal etwas ausprobiert. ;-)
> (Siehe Anhang)
> Mein erstes eigenes Programm (STOLZ!!)

Schöne Bitspielerei...
Von da bis zum DCC-Decoder ist aber noch ein langer Weg.
Den würde ich aber ad hoc auch nicht aus dem Hut zaubern. Zumal ich 
selbst keine Modellbahn betreibe und daher keine Motivation habe.

Aber jetzt erschließt sich Dir erstmal ein breites Aufgabenfeld abseits 
der Digitalisierung. So z.B. die Blinker für Bahnübergänge, Feuerwehr, 
die Ampeln der Straßenkreuzungen, die Lichtschalterei in den Wohnhäusern 
und Vieles mehr. Da wirdt Du vermutlich noch vielen Tinys und Megas 
Leben einhauchen, und zwar erstmal für Dinge, die nichts mit der 
Fahrerei zu tun haben und daher kein Sicherheitsrisiko darstellen. Das 
sind die dankbarsten Lernobjekte.

>
> Du hast mir Appetit gemacht.

Das freut mich.

>
> Schöne Pfingsten.

Wünsche ich auch...

>
> Gruß
> Sigmar

Gruß,
Hannes

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.