mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik amForth auf ATmega1284p


Autor: Christina (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hey Leute,

aktuell versuche ich amForth auf einem ATmega1284p zum laufen zu 
bekommen, allerdings bekomme ich es nicht hin.

Angefangen hab ich mit dem Template. Die Baudrate angepasst, die 
Frequenz angepasst, geht nicht, nichts am UART.

Ein kleines C Programm sendet fleißig, also ist es wohl nicht die 
Schaltung.

Vermutlich sind es die Fuses, falls von euch das jemand am laufen hat, 
würde ich mich freuen wenn er mir seine Fuse Einstellung zeigen könnte.

Vielen Dank

Christina

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab bis jetz mit EESAVE, BOOTRST und CKDIV8 gestellt und alle 
Kombinationen durch und weiß leider nicht mehr weiter.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christina schrieb:
> Vermutlich sind es die Fuses, falls von euch das jemand am laufen hat,
> würde ich mich freuen wenn er mir seine Fuse Einstellung zeigen könnte.

RTFM:

2.14 What about the fuses?
Just set them to the factory defaults and adjust the oscillator settings 
only. amforth uses the self programming capabilities
so if any boot loader works, amforth should do so.

(doc\amforth.pdf, Pg.16)

Sieht für mich eher so aus, als ob Du da was beim Build erhauen hast.
Aber WIE (und auf welchem OS, mit welchen Tools) hast Du leider nicht 
geschrieben ;)

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Antwort. Das FM ist da leider nicht eindeutig.

(doc\amforth.pdf, Pg.10): ... the EESAVE fuse was checked, and the fuse 
for BOOTRST (jump to bootloader on reset) was NOT checked.

Im Default sind die beide gleich. Hab leider keine Erfahrung mit 
Bootloadern.

Zu meiner Toolchain: Ich bin auf Arch Linux und habe das (appl/template) 
mit wine und avrasm2.exe von der Projektwebsite ohne Fehler mit dem 
Makefile kompiliert. Und schließlich Flash und EEPROM mit avrdude 
hochgeladen.

Geändert habe ich im template.asm (wo schon ATmega1284p steht) nur den 
Takt auf 1,8432 MHz, die Baudrate auf 115200 und TX sowie RX Interrupt. 
Zumindest die Clock passt am PB1 mit CKOUT.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christina schrieb:
> (doc\amforth.pdf, Pg.10): ... the EESAVE fuse was checked, and the fuse
> for BOOTRST (jump to bootloader on reset) was NOT checked.
>
> Im Default sind die beide gleich. Hab leider keine Erfahrung mit
> Bootloadern.

Da hast Du Recht. Das ist etwas verwirrend aber (hoffentllich) einfach 
erklärt:

Seite 10 beschreibt das Programmieren mit AtmelStudio.
Bei AS war (ist?)das Programmieren mit dem internen Programmer per 
Default so eingestellt, dass es vorher alles löscht. Darum hatte Karl 
vermutlich das EESAVE gesetzt um das überschreiben beim (nachfolgenden) 
Flashprogrammieren zu verhindern.

Das sollte bei korrekt benutztem AVRdude egal sein. Müsste man mal das 
Makefile checken :/

BOOTRST darf auf keinen Fall aktiv sein. Sonst wird nach einem Reset der 
(bei amForth nicht mehr existierende) Bootloader angesprungen.


Wenn Du am PB1 die SysClk siehst, dann hast Du aber auch noch zusätzlich 
an den Fuses gespielt. CKOUT ist per Default off, oder? Ist da evtl. 
noch versehentlich mehr geändert?


Ansonsten sollte es eigentlich sollte es gehen :(

BTW: Woher weisst Du eigentlich dass es nicht geht?
Nach dem Reset gibt das amForth ja nur ein paar Zeichen am UART aus und 
wartet dann auf eine Eingabe. Viel Aktivität wirst Du da (ohne 
fleissiges Return-drücken) nicht sehen. Hast Du mal einen Debugger 
rangehängt?

HtH

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 1,8432 MHz

Stimmt das? Ich hätte eher das 10-fache erwartet, zumal ja, wenn ich es 
richtig verstanden habe, amForth ohnehin nicht besonders schnell ist.

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Da hast Du Recht. Das ist etwas verwirrend aber (hoffentllich) einfach
> erklärt:
>
> Seite 10 beschreibt das Programmieren mit AtmelStudio.
> Bei AS war (ist?)das Programmieren mit dem internen Programmer per
> Default so eingestellt, dass es vorher alles löscht. Darum hatte Karl
> vermutlich das EESAVE gesetzt um das überschreiben beim (nachfolgenden)
> Flashprogrammieren zu verhindern.
>
> Das sollte bei korrekt benutztem AVRdude egal sein. Müsste man mal das
> Makefile checken :/
>
> BOOTRST darf auf keinen Fall aktiv sein. Sonst wird nach einem Reset der
> (bei amForth nicht mehr existierende) Bootloader angesprungen.

Danke für die Erklärung, jetz wo du es sagst seh ich es auch, dass das 
EEPROM sowieso jedesmal mit hochgeladen wurde.
Das mit BOOTRST ist mir allerdings jetz unklar, da ich dachte amForth 
wird irgendwie genau da leben, wenn es den Flash im laufenden Betrieb 
schreiben kann.

Andreas H. schrieb:
> Wenn Du am PB1 die SysClk siehst, dann hast Du aber auch noch zusätzlich
> an den Fuses gespielt. CKOUT ist per Default off, oder? Ist da evtl.
> noch versehentlich mehr geändert?

Natürlich hab ich das. Aktuell habe ich das High Fuse auf Default 
(0x99), das Low Fuse auf Full Swing Crystal mit BOD ohne CKDIV8 und 
CKOUT (0xd7) und das Extendend auf BODLEVEL 4,1 - 4,5 V (0xfc)

Andreas H. schrieb:
> BTW: Woher weisst Du eigentlich dass es nicht geht?
> Nach dem Reset gibt das amForth ja nur ein paar Zeichen am UART aus und
> wartet dann auf eine Eingabe. Viel Aktivität wirst Du da (ohne
> fleissiges Return-drücken) nicht sehen. Hast Du mal einen Debugger
> rangehängt?

Einen Debugger hab ich leider nicht, Enter in picocom gedrückt, hab ich 
schon viel. Hab das ganze auch schon auf der μC Seite abgestöpselt und 
genauso an Raspberry Pi – da gings.

S. Landolt schrieb:
>> 1,8432 MHz
>
> Stimmt das? Ich hätte eher das 10-fache erwartet, zumal ja, wenn ich es
> richtig verstanden habe, amForth ohnehin nicht besonders schnell ist.

Das stimmt, hab jetz auch mal einen mit dem zehnfachen, den ich nur als 
liegend SMD hab, die Füße geradegebogen. Hab auch schon niedrigere 
Baudraten ausprobiert nur senden will der μC nicht.

Interresanterweise bekomm ich, wenn ich das Flash und das EEPROM Image 
zu einem .elf File zusammenfüge mit simavr die amForth Bootnachricht. 
Eingaben kann ich keine tätigen. Allerdings immer noch besser als Flash 
und EEPROM als .hex zu laden, dann stürzt simavr ab.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christina schrieb:
> Interresanterweise bekomm ich, wenn ich das Flash und das EEPROM Image
> zu einem .elf File zusammenfüge mit simavr die amForth Bootnachricht.
> Eingaben kann ich keine tätigen. Allerdings immer noch besser als Flash
> und EEPROM als .hex zu laden, dann stürzt simavr ab.

1284p hab ich hier keine rumliegen. Ich kann aber morgen mal minGW 
installieren und das Template für den ATmega328p probieren.
In irgendeiner Ecke liegt bestimmt noch ein altes Arduinoboard rum ;)

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, bin auch mit Forth zugange und ich kann jedem nur raten, sich ganz 
genau anzuschaun, was bei der Initialisierung passiert! Die "millionen" 
Include-Files machen was, aber was??? Ich z.B. fand den Hinweis (altes 
Atmega-Forth) auf keinen Fall das Uart-01 (oder so..) in den Turnky 
aufzunehmen, als völlig unverständlich. Nach langer Sichtung habe ich 
(hoffentlich) verstanden, warum...
Man muß arbeiten! Und dann machts auf einmal Spass!
Gruß Rainer

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Christina schrieb:
>> Interresanterweise bekomm ich, wenn ich das Flash und das EEPROM Image
>> zu einem .elf File zusammenfüge mit simavr die amForth Bootnachricht.
>> Eingaben kann ich keine tätigen. Allerdings immer noch besser als Flash
>> und EEPROM als .hex zu laden, dann stürzt simavr ab.
>
> 1284p hab ich hier keine rumliegen. Ich kann aber morgen mal minGW
> installieren und das Template für den ATmega328p probieren.
> In irgendeiner Ecke liegt bestimmt noch ein altes Arduinoboard rum ;)

Das wäre klasse, hab es heute auch mit einem ATmega32 probiert. Benutze 
einen 16 MHz Quartz, hab die Baudrate auf 9600 gestellt und die Fuses 
auf H:0x89 L:0xff. Ein kleines C Echo Programm läuft, amForth nicht.

Auf dieser Seite: 
https://www.embeddedrelated.com/showthread/comp.arch.embedded/121848-1.php 
hab ich das folgende gefunden
  srec_cat template.eep.hex -Intel \
          -fill 0xff 0x00 -maximum-address template.eep.hex -Intel \
          -multiple  -Output eeprom.bin -Binary
  srec_cat template.hex -Intel \
          -fill 0xff 0x00 -maximum-address template.hex -Intel \
          -multiple  -Output code.bin -Binary
  avr-objcopy --rename-section .data=.text,CONTENTS,ALLOC,LOAD,CODE \
          --set-section-flags .eeprom=CONTENTS,ALLOC,LOAD \
          --add-section .eeprom=eeprom.bin \
          --change-section-vma .eeprom=0x810000 \
          -I binary  code.bin  -O elf32-avr code.elf

und mit ins Makefile geschrieben. Damit kann ich simavr ausführen
% simavr -f 16000000 -m atmega32 code.elf
Loaded 32638 .text at address 0x0
Loaded 134 .eeprom
amforth 6.7 ATmega32..

Allerdings hab ich die Bedienung von simavr noch nicht so ganz 
verstanden, da mein C Echo Porgramm hier nicht funktioniert. Wenn ich 
Eingaben auf der Konsole mache, bekomme ich keine bzw. nicht die 
gewünschte Antwort.
Interessant ist allerdings, dass die Ausgabe von amForth grün erscheint. 
Wenn ich mit picocom über /dev/pts/? verbinde bleibt der Curser bis zum 
Enter drücken grün, direkt an Konsole wird er sofort nach drücken einer 
Taste schwarz.
Kann der Fehler auch sein, dass ein CRLF erwartet wird?

Rainer V. schrieb:
> Hi, bin auch mit Forth zugange und ich kann jedem nur raten, sich ganz
> genau anzuschaun, was bei der Initialisierung passiert! Die "millionen"
> Include-Files machen was, aber was??? Ich z.B. fand den Hinweis (altes
> Atmega-Forth) auf keinen Fall das Uart-01 (oder so..) in den Turnky
> aufzunehmen, als völlig unverständlich. Nach langer Sichtung habe ich
> (hoffentlich) verstanden, warum...
> Man muß arbeiten! Und dann machts auf einmal Spass!
> Gruß Rainer

Soweit bin ich leider noch nicht. Wäre es deiner Meinung nach besser 
gleich ein kleines Forth in Assembler vom Scratch zu schreiben?
Bis jetz war ich mit C erfolgreich, Assembler behaupte ich zumindest 
halbwegs lesen zu können.

Autor: Rainer V. (a_zip)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christina schrieb:
> Soweit bin ich leider noch nicht. Wäre es deiner Meinung nach besser
> gleich ein kleines Forth in Assembler vom Scratch zu schreiben?
> Bis jetz war ich mit C erfolgreich, Assembler behaupte ich zumindest
> halbwegs lesen zu können.

Hi Ch..., das ist d i e Frage.Habe auch noch keinen Plan, wie man mit 
Forth da weitermacht. Von Scratch ist sehr ambitioniert...auf der 
anderen Seite passiert dann wirklich nur das, was man will(oder 
glaubt...)
Hatte in einem anderen Th "angekündigt", dass ich so etwas wie ein Forth 
in Python machen will, mit Crossassembler auf eine "beliebige" 
Prozessorfamilie. Ist natürlich auch "very overamigious", aber ein 
Virtuelles Forth zu versuchen hat was!
Bin gespannt, was du weiter machst!!!
Gruß Rainer

Autor: S. Landolt (Gast)
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
Ist das Problem mit dem ATmega1284P noch aktuell? Wenn ja, anbei .hex- 
sowie .eep-Datei für ebendiesen, 18.432 MHz und 115200 Bd auf USART0, 
erstellt nach dieser Anleitung von Craig Lindley. Bringt auf einem 
Hyperterminal (und zu mehr habe ich keine Lust):
> amforth 6.7 ATmega1284P
>
 ok
>

Autor: S. Landolt (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
PS:
Ich vergaß die Fuses: l: F7, h: D1, x: FE.

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. Landolt schrieb:
> Ist das Problem mit dem ATmega1284P noch aktuell? Wenn ja, anbei .hex-
> sowie .eep-Datei für ebendiesen, 18.432 MHz und 115200 Bd auf USART0,
> erstellt nach dieser Anleitung von Craig Lindley. Bringt auf einem
> Hyperterminal (und zu mehr habe ich keine Lust):> amforth 6.7
> ATmega1284P
>>
>  ok
>>

Vielen Dank, hab den 128er wieder in die Schaltung gebaut und es 
probiert. Es ist zum mäusemelken, es funktioniert nicht.
Wahrscheinlich sitzt das Problem, wie so oft, vor dem Bildschirm. Werd 
es wohl nochmal neu aufbauen.

Falls jemand ein Common Mistake oder Pit Fall einfällt, für solcherlei 
Ratschläge wär ich dankbar.

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Merkwürdig. Da bei Ihnen die serielle Verbindung in Ordnung ist, sonst 
würde das C-Programm ja nicht laufen, andererseits ein ATmega1284P mit 
den beiden Dateien bei mir läuft, kann es doch eigentlich nur noch am 
Laden mit dem avrdude liegen. Da kann ich allerdings leider nicht 
weiterhelfen, da ich nur über ein selbstgebautes Programmiergerät, 
gesteuert per HyperTerminal, verfüge.

Autor: S. Landolt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
PS:
Avrdude hat doch wohl kein Problem mit der großen Lücke zwischen 0x0464 
und 0xF000?

Autor: Andreas H. (ahz)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Christina schrieb:
> Falls jemand ein Common Mistake oder Pit Fall einfällt, für solcherlei
> Ratschläge wär ich dankbar.

Huhu

Sry 4 te delay. Meine Erkältung hat mich böse erwischt.

However: Wie versprochen habe ich das ganze mal für einen alten Arduino 
UNO (ATmega328p) kompiliert. Win7/64, AS 7.0 aber mit MinGW übersetzt.
Statt AVRdude habe ich das Atmel cmdline tool (atprogram.exe) benutzt.

Ging relativ unblutig und meldet sich mit:
> amforth 6.7 ATmega328P - The AHz Atmega328p Version
> 123 321 + .
444  ok
>
Den geänderten Title gibts (s.u.) nicht nur wegen meiner unbestreitbaren 
Eitelkeit, sondern um mal zu schauen ob der Flow auch Änderungen 
verarbeitet. Tut er^^

Zwei Kleinigkeiten sind aufgefallen:

1. In avr8/devices/atmega328p/device.asm musste die Definition von SPMEM 
entfernt werden (redefinition).

2. Das Default-Makefile scheint nicht die Device zu löschen bevor 
reprogrammiert wird. Das sollte man (steht auch so im Makefile, wie 
clever^^) vor dem Programmieren per Hand machen (make uno.era beim 
Arduino UNO board).

Das gab hier ein paar sehr lustige Effekte, z.B. Endlessloop der 
Titelausgabe (darum die obige Änderung) aber auch KEINE AUSGABE auf dem 
UART (kommt Dir bekannt vor?).

KA wie das intern wirkte aber nach PowerOff, Device Clean  und neuer 
Programmierung lief alles.

Makefile habe ich Dir angehängt. Vielleicht fällt Dir ja auf, was bei 
dir schiefgeht.

HtH
AHz

Autor: S. Landolt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Vorab: welches Programmiergerät wird eigentlich verwendet?

Nächster Versuch: die Programm-Intel-Hex-Datei vom letzten Mal ist hier 
aufgespalten in den unteren und den oberen Programmblock.
ATmega1284P, Quarz mit 18432000 Hz, Terminal mit 115200 Bd an USART0, 5 
Volt

Vorgehen:
0. Fuse-bytes programmieren: low= 0xF7, high= 0xD1, extended= 0xFC
1. Funktionstest mit exakt dieser Anordnung:
   einfaches C-Programm sendet ein paar Zeichen an das Terminal
2. avrdude: chip-erase
3. avrdude: EEPROM laden: SL1284.eep
4. avrdude: unteren Programmblock laden: SL1284low.hex  !ohne chip-erase!  ('-D'?)
5. avrdude: oberen Programmblock laden: SL1284high.hex  !ohne chip-erase!  ('-D'?)

Autor: Christina (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> Christina schrieb:
>> Falls jemand ein Common Mistake oder Pit Fall einfällt, für solcherlei
>> Ratschläge wär ich dankbar.
>
> Huhu
>
> Sry 4 te delay. Meine Erkältung hat mich böse erwischt.
>
> However: Wie versprochen habe ich das ganze mal für einen alten Arduino
> UNO (ATmega328p) kompiliert. Win7/64, AS 7.0 aber mit MinGW übersetzt.
> Statt AVRdude habe ich das Atmel cmdline tool (atprogram.exe) benutzt.

S. Landolt schrieb:
> Vorab: welches Programmiergerät wird eigentlich verwendet?
>
> Nächster Versuch: die Programm-Intel-Hex-Datei vom letzten Mal ist hier
> aufgespalten in den unteren und den oberen Programmblock.
> ATmega1284P, Quarz mit 18432000 Hz, Terminal mit 115200 Bd an USART0, 5
> Volt

Danke nochmal für die vielen Antworten, leider habe ich die Tage ein 
bisschen wenig Zeit. Habs nochmal mit dem arduino Makefile probiert und 
auch mal die zwei getrennten Flash Dateien versucht. Auch mit einem 
anderen 1284p. Keine Chance.

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christina schrieb:
> Auch mit einem
> anderen 1284p. Keine Chance.

Dann ist da vermutlich bei Deinem Setup insgesamt irgend etwas nicht ok.
Zumindest die Dateien von S. Landolt laufen ja zumindest bei ihm.

Da bleibt eigentlich nur die HW oder das Loading.

Magst Du mal das gesamte Projekt zippen und zusammen mit einem 
Schaltplan Deines Aufbaus hier posten?
Dann kann man es ja mal nachbauen und schauen wo es klemmt. Einen 
Atmel32 hab ich bestimmt auch noch irgendwo rumliegen und ein 1284p 
sollte man auch mal mitbestellen können.

Wär doch gelacht wenn man das nicht hinkriegt ;)

/regards

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.

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