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
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 ;)
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.
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
> 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.
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.
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 ;)
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
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
und mit ins Makefile geschrieben. Damit kann ich simavr ausführen
1
% simavr -f 16000000 -m atmega32 code.elf
2
Loaded 32638 .text at address 0x0
3
Loaded 134 .eeprom
4
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.
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
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):
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.
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.
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:
1
> amforth 6.7 ATmega328P - The AHz Atmega328p Version
2
> 123 321 + .
3
444 ok
4
>
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
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:
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.
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
