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:
1 | :~/RepRap/Generation 7 Electronics/lpc21isp$ ./lpc21isp.out \ |
2 | -localecho -debug5 /tmp/build3402789950117874614.tmp/Blink.cpp.bin /dev/ttyUSB0 115200 12000 |
3 | Local echo in terminal mode. |
4 | Turn on debug, level: 5. |
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:
1 | $ git svn clone https://lpc21isp.svn.sourceforge.net/svnroot/lpc21isp |
2 | [...] |
3 | $ cd lpc21isp/ |
4 | $ make |
5 | [...] |
6 | $ ./lpc21isp -control -bin /tmp/build3402789950117874614.tmp/Blink.cpp.bin \ |
7 | /dev/ttyUSB0 115200 12000 |
8 | lpc21isp version 1.85 |
9 | File /tmp/build3402789950117874614.tmp/Blink.cpp.bin: |
10 | loaded... |
11 | image size : 9752 |
12 | Image size : 9752 |
13 | Synchronizing (ESC to abort). OK |
14 | Read bootcode version: 1 |
15 | 7 |
16 | Read part ID: LPC1114.../102, 32 kiB ROM / 4 kiB SRAM (0x1A40902B) |
17 | Will start programming at Sector 1 if possible, and conclude with Sector 0 to ensure that checksum is written last. |
18 | Erasing sector 0 first, to invalidate checksum. OK |
19 | Sector 1: ...........................|.........................|.........................|......................... |
20 | Sector 2: ...........................|............. |
21 | Sector 0: ..........................|.........................|.........................|......................... |
22 | Download Finished... taking 1 seconds |
23 | 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 :-)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.