 Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Hallo zusammen,
die RepRap-3D-Drucker werden immer schneller, also müssen die
Steuerungen dort langsam mal vom ATmega auf einen ARM 32-bit umsteigen.
Da viele 32-bit Integer berechnet werden müssen, ist das
vielversprechend. Also habe ich mal einen ersten Entwurf mit einem
LPC1114FN28 (das Ding im PDIP-Gehäuse) zusammen genagelt; so weit, so
gut.
Im Gegensatz zu den AVRs scheint allerdings das hochladen der Firmware
über die serielle Schnittstelle ziemlich aussergewöhnlich zu sein,
obwohl ein entsprechender Bootloader im ROM mitgeliefert wird. Selbst
mit 2 Tagen googlen konnte ich noch kein einziges Kommandozeilen-Tool
ausmachen, das das beherrschen würde. Überall integrierte Umgebungen,
Windows-Zeugs, nur nichts Vernünftiges.
Vernünftig = Open Source und etwas, was man in ein Makefile, besser noch
in die Arduino IDE einbinden kann. Da mit vielen DAUs (Dümmsten
Anzunehmenden Usern) zu rechnen ist, muss das mit zwei, drei Klicks oder
einem einzigen CLI-Befehl funktionieren. Sowas wie Eclipse scheidet da
von vorneherein aus, da viel zu kompliziert. Bislang, bei den AVRs, hat
sich die Arduino IDE etabliert.
Meine bescheidenen bisherigen Erfolge habe ich hier aufgeschrieben:
http://reprap.org/wiki/Gen7_Board-ARM_2.0 . Das manuelle verbinden mit
dem Bootloader habe ich ausprobiert, klappt prima.
Muss ich jetzt so ein Firmware-Hochlade-Tool erst noch schreiben, bzw.
Bossa[1] in diese Richtung erweitern? Oder kann mir jemand weiter
helfen?
Besten Dank,
Markus
[1] Bossa: http://www.shumatech.com/web/products/bossa
Du suchst FlashMagic http://www.flashmagictool.com/ ein eigenes Tool zu
schreiben ist aber auch kein Hexenwerk, das Protokoll wurde Von NXP in
einer Applikation-Note beschrieben.
Markus H. schrieb:
> Selbst
> mit 2 Tagen googlen konnte ich noch kein einziges Kommandozeilen-Tool
> ausmachen
Google nach "lpc1114fn28 boot loader"
2. Treffer :-) => Beitrag "ARM in DIP: CM0 lpc1114fn28 ist da und blinkt!"
Wobei ich beim 1. Treffer Anleihen genommen habe :-)
> Du suchst FlashMagic
Das empfehlen Viele. Jedoch:
- Läuft weder auf Linux noch auf dem Mac, da Wine keine seriellen
Schnittstellen zuordnen kann.
- Closed Source, kann also nicht in andere Projekte eingebunden werden.
- Sehr umständlich zu bedienen.
- Keine Kommandozeile.
> 2. Treffer :-) => Beitrag "ARM in DIP: CM0 lpc1114fn28 ist da und blinkt!"
Den hatte ich auch schon, offensichtlich habe ich ihn nicht genau genug
angeschaut.
Das Zauberwort heisst "lpc21isp". Funktioniert natürlich nicht einfach
so, das bin ich inzwischen gewohnt, aber immerhin mal eine
Implementierung des Protokolls.
"Funktioniert nicht" stellt sich wie folgt dar:
:~/RepRap/Generation 7 Electronics/lpc21isp$ ./lpc21isp.out \
-localecho -debug5 /tmp/build3402789950117874614.tmp/Blink.cpp.bin /dev/ttyUSB0 115200 12000
Local echo in terminal mode.
Turn on debug, level: 5.
lpc21isp version 1.83 |
... das war's, da folgt nichts mehr.
Markus H. schrieb:
>> Du suchst FlashMagic
>
> Das empfehlen Viele. Jedoch:
>
> - Läuft weder auf Linux noch auf dem Mac, da Wine keine seriellen
> Schnittstellen zuordnen kann.
> - Closed Source, kann also nicht in andere Projekte eingebunden werden.
> - Sehr umständlich zu bedienen.
> - Keine Kommandozeile.
Ahh ok bin davon ausgegangen das du was für Windows suchst.
Ich habe mal lpc21isp angehangen das ich immer verwende, das binary ist
auf einem 64Bit-Ubuntu kompiliert worden.
Aufrufen tue ich das mit einem LPCxpresso-Board wie folgt:
[code]./lpc21isp -control ../USBTest/Debug/USBTest.hex /dev/ttyUSB0
115200 12000[code]
Markus H. schrieb:
> ... das war's, da folgt nichts mehr.
Hast Du beide Patches eingearbeitet?
Es funktioniert damit tadellos.
M. K. schrieb:
> Ich habe mal lpc21isp angehangen das ich immer verwende, das binary ist
> auf einem 64Bit-Ubuntu kompiliert worden.
2x gepatcht?
Nö gepatcht habe ich da nichts, hatte die Sourcen runter geladen,
kompiliert und war glücklich ;-)
Die Quelltexte findest du auf Sourceforge
http://sourceforge.net/projects/lpc21isp/
M. K. schrieb:
> Nö gepatcht habe ich da nichts, hatte die Sourcen runter geladen,
> kompiliert und war glücklich ;-)
Schön. Am 10.11. gab es die 1.85 noch nicht.
D. h. mit der 1.85 geht lpc1117 ohne Patchen? Getestet?
In jedem Fall geht aber die 1.83 mit den Patches.
Wenn der TO darauf besteht, dass es mit der 1.83 von 2011 unbedingt
gehen muss, dann muss er halt patchen.
Ich verwende auch Version 1.83, habe gerade erst gesehen das es eine
neuere Version gibt.
LPC1117 kann ich nicht sagen ob es klappt, ist der was spezielles?
LPC1114 hatte ich Anfang des Jahres einmal mit einer Windows-Version auf
der Arbeit erfolgreich getestet.
Privat habe ich einen LPC1769 den ich in den letzten Tagen/Wochen schon
mehrere Dutzend mal damit gebrannt habe.
> Hast Du beide Patches eingearbeitet?
Ich hatte die Version auf Github genommen, die der Brad zur Verfügung
gestellt hat. Manchmal komme ich noch auf die verwegene Idee, dass das,
was die Leute zur Verfügung stellen, auch funktioniert. Und ich habe dem
Brad geglaubt, dass das Original nicht mehr weiter entwickelt wird.
Alles naiv, ich weiss ;-)
Mit der 1.85 von Sourceforge geht's deutlich besser:
$ git svn clone https://lpc21isp.svn.sourceforge.net/svnroot/lpc21isp
[...]
$ cd lpc21isp/
$ make
[...]
$ ./lpc21isp -control -bin /tmp/build3402789950117874614.tmp/Blink.cpp.bin \
/dev/ttyUSB0 115200 12000
lpc21isp version 1.85
File /tmp/build3402789950117874614.tmp/Blink.cpp.bin:
loaded...
image size : 9752
Image size : 9752
Synchronizing (ESC to abort). OK
Read bootcode version: 1
7
Read part ID: LPC1114.../102, 32 kiB ROM / 4 kiB SRAM (0x1A40902B)
Will start programming at Sector 1 if possible, and conclude with Sector 0 to ensure that checksum is written last.
Erasing sector 0 first, to invalidate checksum. OK
Sector 1: ...........................|.........................|.........................|.........................
Sector 2: ...........................|.............
Sector 0: ..........................|.........................|.........................|.........................
Download Finished... taking 1 seconds
Now launching the brand new code
|
Wenn das hochladen hängt, weil er nicht synchronisieren kann, muss man
mal Reset drücken.
An dieser Stelle mal VIELEN DANK für die insgesamt hilfreichen Antworten
hier. Jetzt bin ich mit der ARM-Welt wieder halbwegs versöhnt. :-)
Markus H. schrieb:
> - Läuft weder auf Linux noch auf dem Mac, da Wine keine seriellen
> Schnittstellen zuordnen kann.
Das stimmt nicht, einfach in ~/.wine/dosdevices/ symlinks für die ports
anlegen:
com1 -> /dev/ttyUSB0
Damit tat Flashmagic bei mir. Trotzdem ist n Konsolentool natürlich
schöner.
Ein Arbeitskollege hatte FlashMagic mal aus LabVIEW heraus aufgerufen,
könnte also sein das man FlashMagic ein paar Parameter mit auf den Weg
geben kann.
Kann aber auch sein das er so Windows-Schweinekrams wie ActiveX
verwendet hat.
Als Hardware nehme ich ein FTDI-Breakout Reloaded von Watterott
http://www.watterott.com/de/FTDI-Breakout-Reloaded-V11
mit einem Extraanschluss für RTS (der Arduino-Stecker hat leider CTS!)
DTR -> Reset
RTS -> BOOT (P0_1 bei LPC11xx)
Dann können die Tools automatisch in den Bootlader gehen.
M. K. schrieb:
> LPC1117 kann ich nicht sagen ob es klappt, ist der was spezielles?
Sorry, mein Vertipper: Ich meinte den lpc1114fn28.
> LPC1114 hatte ich Anfang des Jahres einmal mit einer Windows-Version auf
> der Arbeit erfolgreich getestet.
Das kann aber fast nicht der in DIP gewesen sein. M. W. hat dieser eine
andere Chip-ID, deshalb Patch Nr. 1 für 1.83 oder so.
Ist nun aber auch egal :-)
> Privat habe ich einen LPC1769 den ich in den letzten Tagen/Wochen schon
> mehrere Dutzend mal damit gebrannt habe.
Ja, das funktioniert. Für den habe ich lpc21isp momentan auch im
Einsatz.
Momentan, weil: Der Knaller ist stm32f4 discovery als Werkzeug:
Beitrag "Re: ARM in DIP: CM0 lpc1114fn28 ist da und blinkt!"
Für die Leute, denen kaufen zu einfach oder zu doof ist, habe ich mal
meine derzeitige "Schaltung" angehängt. Das ist so gut wie nichts. Alle
Verbindungen, die das Bild verlassen, sind Nutzsignale, die man erst mal
weg lassen kann.
PIO0_1 kann man beim programmieren dauerhaft auf GND lassen, da braucht
man also nicht einmal einen Schalter. Allerdings gefällt mir die Lösung
von Jürgen S. 16:16 Uhr besser :-)
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
- [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
|