Hallo, bisher habe ich AVRs mit Atmel Studio in Assembler programmiert und möchte auf STM32 umsteigen. Momentan experimentiere ich mit einem STM32F411RE auf einem Nucleo Board. - Angetestet habe ich System Workbench, TrueStudio und VisualGDB. - System Workbench funktioniert so halbwegs für mich, fühlt sich aber völlig überladen und zu sehr auf C ausgerichtet an. Außerdem ist es ziemlich zickig wenn man viel in den IO Registern / Peripheriemodulen des Simulators herumsucht was bei Assembler zum täglich Brot gehört (klappt immer wieder den Baum zu, vergisst die Werte...). - Keil MDK ist preislich völlig jenseits des Budgets und in der limitierten Version ist ausgerechnet der Assembler nicht verfügbar. - Eigentlich benötige ich nur einen ARM Assembler, Simulator und Programmiertool in einem übersichtlichen Paket ähnlich wie es das Atmel Studio geboten hat. - Preislich liegt die Schmerzgrenze bei 1000 Euro. Eingeschränkte Versionen kommen nur in Frage falls die kommerzielle Nutzung des damit erzeugten Codes erlaubt ist. - Kennt da jemand etwas? Bei Assembler möchte ich bleiben. Ist im wesentlichen nur eine Portierung von einem zum anderen System mit viel zeitkritischem Code (CNC Steuerung). Der weniger kritische Rest drum herum ist nicht so wild dass es das erlernen von C für mich rechtfertigt (Initialisierung des Boards ohne HAL und STM Standard Library rein über Assembler hab ich z.B. soweit schon hinbekommen - ist im Endeffekt kein Hexenwerk sobald man die Register kennt). Christian
Christian K. schrieb: > Bei Assembler möchte ich bleiben. Wer wird dir die selbstgewählten Scheuklappen abnehmen können? Wieviel wirst du an Geschwindigkeit gegenüber C Programmierung gewinnen? Ich postuliere mal einen Daumenpeilwert von 20% max.
Christian K. schrieb: > zum anderen System mit viel zeitkritischem Code Bei diesen trägen, lethargischen STM32-Prozessoren muss man schon höllisch aufpassen dass man nicht zu langsam wird.
Tellerrand Hinausblick schrieb: > Bei diesen trägen, lethargischen STM32-Prozessoren muss > man schon höllisch aufpassen dass man nicht zu langsam wird. Das stimmt allerdings. Deshalb spendieren wir bei uns z.B. jedem STM32 noch einen Coprozessor (AVR tiny oder PIC, was halt da ist) damit es von der Performance her in halbwegs erträgliche Bereiche kommt. Und gemessen an der Leistung und Ausstattung sind die STM32 auch noch zu teuer.... Jetzt aber echt... Bestes Beispiel: STM32F030F4P6 50 ct, eine Frechheit.... :-)
Hallo, vergleicht mal was der Prozessor nur beim setzen eines Ausgangspins zu tun hat. In Assembler geht die LED des Nucleo Boards z.B. so an: ldr r0,=0x40020014U mov r1,#32 str r1,[r0] Danach schaut euch im Disassembler an was aus HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET); wird - da kommen einem die Tränen... Die Funktion schiebt in einer Schleife das Bit an die richtige Position - da gehen zig Takte drauf. Jetzt kann man natürlich einwenden dass man die Sache auch in C mit direktem IO-Zugriff schreiben kann - nur ist man dann im Endeffekt wieder bei einem "Assembler auf Steroiden" und bekommt dennoch Overhead vom Compiler dazu. Der F411RE hat 100MHz, der Atmega328 20MHz. Beide Architekturen setzen einen Großteil der Befehle in einem Takt um. ARM ist Load / Store Architektur ohne direkten Zugriff auf IO Register. Der Atmega328 hat IO Zugriff und macht aus den 3 Zeilen Assembler oben eine einzige: sbi PortA,5 Die Takterzeugungsschleife meiner CNC-Steuerung ist mit lauter so Zeug voll und hat die wichtigsten Variablen dauerhaft in nur dafür vorgesehenen Registern um Speicherzugriffe zu vermeiden was ein C Compiler soweit ich weiss niemals machen wird. Alleine aus dem Grund würde der Atmega auf Assembler dem STM32 mit C / HAL schon davonrennen. Es geht hier nicht um komplexe Sachen wo Hochsprachen ihre Vorteile ausspielen können. Der Controller hat nicht mal eine einzige Division oder gar Fließkommaberechnungen zu erledigen... Multiplikationen beschränken sich auf Shifts... Ein bisschen Addieren, Subtrahieren, Vergleichen und Bits herumschieben - das war es im wesentlichen auch schon - allerdings 160000 mal je Sekunde für jede der 3 Achsen (beim Atmega328 auf 16MHz). Dazu noch etwas serielle Kommunikation und fertig ist die Laube... Christian
Christian K. schrieb: > Danach schaut euch im Disassembler an was aus > HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET); > wird - da kommen einem die Tränen... ... und mir kommen die Tränden wenn du einen HAL Code mit Assembler vergleichst .... keine weiteren Worte notwendig. Mach nur weiter so und erfülle dir deine selbstgesetzten Prophezeihungen. Ich bin dann mal weg.
Es gibt auch noch die SPL, die ist nicht so überladen. Ein Programm besteht nicht nur aus LED an, LED aus. Sobalds von der Hadware-Abstraktion an die Programmlogik geht, ist C ein grosser Schritt nach vorn.
Überzeuge mich... schreibe in C einen Code der GPIOA Pins 1,2,3 einzeln hintereinander setzt, zum Spaß davor jeweils 2 Integer Variablen nach dem Schema A = A+B addiert (insgesamt 6 Variablen) und zum Schluss wieder alle Pins zurücksetzt. Stelle den disassemblierten Code hier rein und dann vergleichen wir... Wenn es weniger als die doppelte Taktzahl benötigt überlege ich es mir ernsthaft auf C umzusteigen. Christian
Na gut, erster Versuch:
1 | void
|
2 | led (int b) |
3 | {
|
4 | static int a, c, e; |
5 | int d = 2, f = 3; |
6 | |
7 | GPIOA->BSR = 1; |
8 | a = a + b; |
9 | GPIOA->BSR = 2; |
10 | c = c + d; |
11 | GPIOA->BSR = 4; |
12 | e = e + f; |
13 | GPIOA->BRR = 7; |
14 | return; |
15 | }
|
mit -Os übersetzt:
1 | 200023c0: 2301 movs r3, #1 |
2 | 200023c2: 4a09 ldr r2, [pc, #36] ; (200023e8 <led+0x28>) |
3 | 200023c4: 8313 strh r3, [r2, #24] |
4 | 200023c6: 4b09 ldr r3, [pc, #36] ; (200023ec <led+0x2c>) |
5 | 200023c8: 6819 ldr r1, [r3, #0] |
6 | 200023ca: 4408 add r0, r1 |
7 | 200023cc: 2102 movs r1, #2 |
8 | 200023ce: 6018 str r0, [r3, #0] |
9 | 200023d0: 8311 strh r1, [r2, #24] |
10 | 200023d2: 6859 ldr r1, [r3, #4] |
11 | 200023d4: 3102 adds r1, #2 |
12 | 200023d6: 6059 str r1, [r3, #4] |
13 | 200023d8: 2104 movs r1, #4 |
14 | 200023da: 8311 strh r1, [r2, #24] |
15 | 200023dc: 6899 ldr r1, [r3, #8] |
16 | 200023de: 3103 adds r1, #3 |
17 | 200023e0: 6099 str r1, [r3, #8] |
18 | 200023e2: 2307 movs r3, #7 |
19 | 200023e4: 8353 strh r3, [r2, #26] |
20 | 200023e6: 4770 bx lr |
21 | 200023e8: 40020000 .word 0x40020000 |
22 | 200023ec: 2001c00c .word 0x2001c00c |
mit -O2 übersetzt:
1 | 200024a0: b4f0 push {r4, r5, r6, r7}
|
2 | 200024a2: 2101 movs r1, #1 |
3 | 200024a4: 2702 movs r7, #2 |
4 | 200024a6: 2604 movs r6, #4 |
5 | 200024a8: 2507 movs r5, #7 |
6 | 200024aa: 4a08 ldr r2, [pc, #32] ; (200024cc <led+0x2c>) |
7 | 200024ac: 4b08 ldr r3, [pc, #32] ; (200024d0 <led+0x30>) |
8 | 200024ae: 8311 strh r1, [r2, #24] |
9 | 200024b0: e9d3 4100 ldrd r4, r1, [r3] |
10 | 200024b4: 4420 add r0, r4 |
11 | 200024b6: 19cc adds r4, r1, r7 |
12 | 200024b8: 6899 ldr r1, [r3, #8] |
13 | 200024ba: 6018 str r0, [r3, #0] |
14 | 200024bc: 3103 adds r1, #3 |
15 | 200024be: 8317 strh r7, [r2, #24] |
16 | 200024c0: 8316 strh r6, [r2, #24] |
17 | 200024c2: e9c3 4101 strd r4, r1, [r3, #4] |
18 | 200024c6: 8355 strh r5, [r2, #26] |
19 | 200024c8: bcf0 pop {r4, r5, r6, r7}
|
20 | 200024ca: 4770 bx lr |
21 | 200024cc: 40020000 .word 0x40020000 |
22 | 200024d0: 2001c00c .word 0x2001c00c |
23 | 200024d4: ffffffff .word 0xffffffff |
24 | 200024d8: ffffffff .word 0xffffffff |
25 | 200024dc: ffffffff .word 0xffffffff |
aber wie willst du jetzt rausfinden, wie viele Zyklen das sind?
Hallo, ldr r0,=0x40020014U mov r1,#1 str r1,[r0] add r2,r3 mov r1,#2 str r1,[r0] add r4,r5 mov r1,#4 str r1,[r0] add r6,r7 mov r1,#0 str r1,[r0] Takte zählen ist jetzt in der Tat nicht ganz easy - keine Ahnung ob das der Debugger kann. Gehen wir einfach von einem Takt je Befehl aus. Ich gebe zu: das Ergebnis des Compilers ist definitiv gut (er hat z.B. die IO Adresse nicht ständig neu geladen). Das mit Variablen in Registern halten ohne auf den Speicher zu gehen war auch definitiv eine Gemeinheit von mir die nur in begrenztem Umfang überhaupt möglich ist. Allerdings eine die ich bei der bisherigen Firmware mit 6 Variablen tatsächlich so handhabe, da das in meinem Fall viel gebracht hat. Du hast mich überzeugt C ernsthaft in Erwägung zu ziehen. Könnte auf C mit Ausnahme der Hauptberechnungsschleife in Assembler rauslaufen. Bleibt halt die Frage ob ich wirklich so viel schneller (gutes) C lerne als meine (zumindest eingebildet sehr guten) Assemblerkenntnisse von AVR auf ARM zu übertragen. Hat jemand zumindest einen Vorschlag für eine IDE die nicht ganz so viel Ballast herumschleppt wie Eclipse? Christian
Christian K. schrieb: > Hat jemand zumindest einen Vorschlag für eine IDE die nicht ganz so viel > Ballast herumschleppt wie Eclipse? QtCreator. Vielleicht kommste dann auch noch zu C++ ...
Christian K. schrieb: > Überzeuge mich... > > schreibe in C einen Code der GPIOA Pins 1,2,3 einzeln hintereinander > setzt, zum Spaß davor jeweils 2 Integer Variablen nach dem Schema A = > A+B addiert (insgesamt 6 Variablen) und zum Schluss wieder alle Pins > zurücksetzt. > > Stelle den disassemblierten Code hier rein und dann vergleichen wir... > Wenn es weniger als die doppelte Taktzahl benötigt überlege ich es mir > ernsthaft auf C umzusteigen. > > Christian Du musst unbedingt Dein veraltetes Wissen auffrischen, denn so wie Du vorgehst, macht man das heutzutage nicht mehr, denn die Welt hat sich bei Mikrocontrollern in den letzten 10...15 Jahren massiv verändert. Schnell Ports setzen um irgendwelche zeitkritischen Bitmuster auszugeben, das macht man definitiv nicht mehr mit I/O Zugriffen aus C (oder auch Assembler), sondern lässt dies vom DMA-Controller im Hintergrund erledigen, erst recht auf einem STM32, welcher dafür optimiert ist. Die HAL mag etwas umständlich erscheinen, aber die Vorteile überwiegen dann doch, bedenkt man die schnellere Entwicklungszeit, die Portabilität innerhalb der STM32 Familien, die funktionstüchtigen Codeblöcke für z.B. USB, was Du definitiv nicht mehr mit Assembler machen willst...
Ich behaupte: Mit gescheitem C Code und der Verwendung von Intrinsics erzeugt der armcc5 besseren Code. Vor allem wegen der hohen Komplexität der ARM basierten MCUs. Bitte keine HAL verwenden, nur CMSIS Header und startup.
:
Bearbeitet durch User
Random .. schrieb: > Bitte keine HAL verwenden, nur CMSIS Header und startup. Das hilft bei Betonköpfen leider nicht. Zitat eines sarkastischen Arbeitskollegen: "Meine Meinung steht fest, bitte verwirren sie mich nicht mit Tatsachen."
Random .. schrieb: > Bitte keine HAL verwenden, nur CMSIS Header und startup. Was findest Du nicht gut an der HAL? Ich finde die HAL zwar auch kein Meisterwerk, aber wie gesagt überwiegen für mich dennoch die Vorteile, insbesondere wenn man etwas komplexere Projekte hat inkl. FreeRTOS und viele Peripheriemodule verwendet oder eine Codebasis, welche für verschiedene Derivate passen soll. z.B. für Standard I2C musste ich nur noch ca. 3 Zeilen Code mit Verwendung der HAL selber schreiben und den Rest hat CubeMX automatisch erzeugt; das ging keine 10 Minuten und funktionierte auf Anhieb einwandfrei.
Ich finde HALs sehr unübersichtlich und meisst zu tief verschachtelt. Wenn man sich komplett drauf einlässt, genug Ressourcen (Flash, RAM, CPU) hat, und wenig Zeit, kann man sicherlich gut die HALs verwenden. Auch für die Portierbarkeit könnte das von Vorteil sein. Allerdings schreibe ich lieber ohne HAL direkt auf den Registern (ggf. mit eigenem Abstraktionslayer), denn schlussendlich muss man oft / meisstens doch wieder selbige direkt programmieren, und dann kann man es gleich von Anfang an richtig machen. Und man lernt so die MCU und ihre Möglichkeiten besser kennen, und kann an kritischen Ecken noch einiges rausholen. Ich verwende trotzdem gerne Libraries für RTX RTOS, TCP/IP, FlashFS, Webserver, USB etc.
:
Bearbeitet durch User
Hallo, HAL, CMSIS oder nicht sollte jeder für sein Projekt entscheiden. Wir benutzen in der Firma maximal CMSIS aber kein HAL, da HAL uns sehr viel Codeplatz im Projekt gekostet hat und für uns nicht genug übrig war. Aus Kostengründen konnten wir auch nicht einfach auf einen anderen uC umsteigen, da wir schon den größten Flash in diesem Gehöuse benutzt haben. Ausserdem benötigen wir die HAL Features nicht in unseren Anwendungen. Wir haben auch ausschliesslich sehr zeitkritische Anforderungen (Regelung Netzteil am Netz), da macht uns die extra Schicht nur Ärger. Wer aber solche Anforderungne nicht hat, kann sicher schnell und komfortabel ein Projekt mit HAL aufsetzen. Das ganze hängt einfach von den Anforderungen der Projektes ab ... Wir benutzen übrigens das TrueStudio von STM -ist ja jetzt offen für Alle und Alles- und vor allem kostenlos. Auch das Debugging mit einem simplen/billigen STLINK (J-Link Software von Segger) funktioniert super, ebenso das "Live" mitlesen von VAriablen, Registern usw. Die Taktzyklen kannst Du mit TrueStudio ansehen, diese bietet viele Infos nebst Stackusage und sonstigem Speicherverbrauch. Nochwas zu Assembler/C: Wir haben viele Jahre die kritischen Dinge in Assembler gemacht (AVR, STM8), mit dem STM32, einer intelligenten Nutzung der Features (DMA, ISR usw.) machen wir nun keine Optimierung per Assembler mehr. Allerdings schauen wir schon mal nach, was beim Compilieren rauskommt (Beispiel: 256 * A oder A << 8). LG GM
Christian K. schrieb: > Danach schaut euch im Disassembler an was aus > HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET); > wird - da kommen einem die Tränen... > Die Funktion schiebt in einer Schleife das Bit an die richtige Position > - da gehen zig Takte drauf. > > Jetzt kann man natürlich einwenden dass man die Sache auch in C mit > direktem IO-Zugriff schreiben kann - nur ist man dann im Endeffekt > wieder bei einem "Assembler auf Steroiden" und bekommt dennoch Overhead > vom Compiler dazu. > > Der F411RE hat 100MHz, der Atmega328 20MHz. > Beide Architekturen setzen einen Großteil der Befehle in einem Takt um. > ARM ist Load / Store Architektur ohne direkten Zugriff auf IO Register. > Der Atmega328 hat IO Zugriff und macht aus den 3 Zeilen Assembler oben > eine einzige: > > sbi PortA,5 > > Die Takterzeugungsschleife meiner CNC-Steuerung ist mit lauter so Zeug > voll und hat die wichtigsten Variablen dauerhaft in nur dafür > vorgesehenen Registern um Speicherzugriffe zu vermeiden was ein C > Compiler soweit ich weiss niemals machen wird. > Alleine aus dem Grund würde der Atmega auf Assembler dem STM32 mit C / > HAL schon davonrennen. Dazu kann ich eine kleine Anekdote erzählen, die ich kürzlich erst selbst erlebt habe. Ich habe ein IC per SPI mit einem F411RE (96 MHz CPU) angesteuert. Code für das setzen von CS ist folgender:
1 | void Spi_ChipSelect(SPI_TypeDef *SPIx, bool select) |
2 | {
|
3 | if(select) |
4 | {
|
5 | if(SPIx == SPI1) |
6 | {
|
7 | GPIO_ResetBits(SPI1_CS_GPIO_PORT, SPI1_CS_PIN); |
8 | }
|
9 | else if(SPIx == SPI2) |
10 | {
|
11 | GPIO_ResetBits(SPI2_CS_GPIO_PORT, SPI2_CS_PIN); |
12 | }
|
13 | else if(SPIx == SPI3) |
14 | {
|
15 | GPIO_ResetBits(SPI3_CS_GPIO_PORT, SPI3_CS_PIN); |
16 | }
|
17 | }
|
18 | else
|
19 | {
|
20 | if(SPIx == SPI1) |
21 | {
|
22 | GPIO_SetBits(SPI1_CS_GPIO_PORT, SPI1_CS_PIN); |
23 | }
|
24 | else if(SPIx == SPI2) |
25 | {
|
26 | GPIO_SetBits(SPI2_CS_GPIO_PORT, SPI2_CS_PIN); |
27 | }
|
28 | else if(SPIx == SPI3) |
29 | {
|
30 | GPIO_SetBits(SPI3_CS_GPIO_PORT, SPI3_CS_PIN); |
31 | }
|
32 | }
|
33 | }
|
Der Ablauf zwischen dem schreiben von 2 Bytes ist dabei folgender: ... WriteByte() ChipSelect(false) VerlasseFunktion() GeheWiederInFunktion() ChipSelect(true) WriteByte() ... Da dieser Teil aber nicht mehr im Release-Build mit -O2 und LTO funktionierte, habe ich es mit dem LogicAnalyzer überprüft und festgestellt, dass zwischen den 2 ChipSelects (trotz mehreren Funktionssprüngen und Verwendung von SPL) NUR 2 Taktzyklen liegen! Der Chip am SPI benötigt aber 3 um zu reagieren. Möchte mal sehen, ob du das genauso gut optimieren kannst wie der GCC ;) mfg
Entschuldigung wenn ich das so sage, aber wer heute noch alles in Assembler macht der sollte endlich mal in Rente gehen und seine Lochkarten mitnehmen. Versuche mal einen Code von einem 8048 nach 8052 nach AVR nach STM32 zu Portieren. Habe ich schon mit einigen Programmen machen dürfen! Auch macht das jedesmal neu schreien von der selben Routine für jeden Prozessor mir absolut keinen Spaß. ZB. der GCC macht es einem so einfach und ob der nun vereinzelt doppelt so lange braucht ist im normal Fall uninteressant bei der Systemgeschwindigkeit. Die HAL ist der letzt Mist die SPL war da wesentlich schöner. Nur leider nutzen heute die recht viele und machen es damit einem schwer. Wenn man was optimieren muss dann sollte man direkt auf die Register zugreifen. Nimm C, deine Nerven und deine Sozialenkontakte werden es dir danken.
Kai schrieb: > Entschuldigung wenn ich das so sage, aber wer heute noch alles in > Assembler macht der sollte endlich mal in Rente gehen und seine > Lochkarten mitnehmen. Aua... :-)) Ich bin 36 ;-) > Auch macht das jedesmal neu schreien von der selben Routine für jeden > Prozessor mir absolut keinen Spaß. Assembler macht mir wirklich Spaß - vielleicht bin ich da einfach etwas "pervers" drauf aber so ist es. Ich verkaufe das Endergebnis zwar auch, angefangen hat es allerdings als reines Hobby und ich sehe es immer noch mehr als Hobby denn als Broterwerb. Bei mir ist es einfach umgekehrt - C macht mir keinen Spaß. C ist Abstraktion - und ich mache gerne das Gegenteil: alles aufdröseln bis ins kleinste Detail. Es macht mir Spaß das letzte Bit auszureizen. Klar - das ist ein Extrem - produktiv und wirtschaftlich ist es nicht unbedingt und dass ich damit in einer Firma nicht durchkommen würde ist mir auch klar - muss ich zum Glück nicht. Wenn ich mir Sachen wie HAL ansehe bekomme ich das kalte Grausen. Kein Wunder dass heute alles unter 8-Kerner @4GHz als lahme Kiste angesehen wird wenn man heute selbst in Microcontrollern derart mit Ressourcen um sich wirft. So manche Taschenlampen App fürs Handy ist größer als mein komplettes CAM inclusive Steuerung - das ist das andere Extrem. Die System Workbench / Eclipse ist auch ein wunderbares Beispiel für das Extrem: Programmpakete von hunderten MB / Rechner mit 4 Kernen und 8GB am ächzen - und wofür: um ein lausiges LED-Blink Testprogrämmchen in Maschinencode zu übersetzen... Eigentlich wollte ich keinen Programmiersprachenkrieg auslösen - bin halt ein bisschen "Old-school". Ich sehe Eure Punkte durchaus und werde wie oben schon geschrieben C ernsthaft in Erwägung ziehen - vielleicht finde ich ja mit der Zeit doch Gefallen daran. Christian
Nun ich habe vor 37 Jahren angefangen und kann nur aus meiner Erfahrung sprechen. Ich habe im Prinzip ja nichts gegen Assembler, solange es spezielle Funktionen sind. Ich kenne nur zu gut das ich heute ein Programm schreibe und in X Jahren muss ich den Prozessor wechseln. Wenn ich das alles in ASM habe dann gute Nacht. Auch benutze ich teilweise den selben Code auf unterschiedlichen Prozessoren. Port Zugriffe mache ich Hardcore mit Macros (AVR-> PORTA |=1 ### STM->PIOA->BSR = 1 ). So bleibt es immer der selbe Code nur die Hardware ändert sich. Habe gerade ein Projekt das auf 3 unterschiedlichen Prozessoren laufen muss, pflege das mal in ASM. Wie gesagt HAL ist gut gemeint, SPL ist besser! Bräuchte die gerade für einen STM32F7, gibt es aber nicht. Als Editor / IDE gibt es neben den klassikern von IAR & Keil auch EmBlitz. Die Entwicklung kommt zwar gerade nicht vorran aber die aktuelle Version ist mehr als brauchbar. Eclipse und ableger gehen auch, aber wie Du schon sagst überladen und langsam. Fazit: C ist einfach besser zu pflegen und leichter zu lesen. Spart am Ende wirklich deine Zeit. VG Kai
Christian K. schrieb: > Bei mir ist es einfach umgekehrt - C macht mir keinen Spaß. C ist > Abstraktion - und ich mache gerne das Gegenteil: alles aufdröseln bis > ins kleinste Detail. Es macht mir Spaß das letzte Bit auszureizen. > Die System Workbench / Eclipse ist auch ein wunderbares Beispiel für das > Extrem: Programmpakete von hunderten MB / Rechner mit 4 Kernen und 8GB > am ächzen - und wofür: um ein lausiges LED-Blink Testprogrämmchen in > Maschinencode zu übersetzen... Darum verwende ich MDK-ARM (µVision, ULINK pro) und CMSIS-Headerfiles und C. Wenn man sich mit C auf µC auseinandersetzt, und sich dazu noch die Compiler-Intrinsics anschaut, kann man verdammt effizient coden. Allerdings muss man sich dann mit seiner IDE (den Debugmöglichkeiten) und der MCU genauestens auseinandersetzen. Und ggf. einfach das Compilat anschauen und danach den C Code optimieren. Ich habe z.B. Teile der TCP/IP Analyse (Antworten, Timeout, Durchsatz, Threading, sowie die Weiterverarbeitung und das Buffern von Daten) auf einem SAM3X mittels Software LogicAnalyzer (über DWT des Cortex-M3) analysiert :-) . Btw: Lädst du dir das SVD file für dein Device, kannst du mittels SVDConv.exe (CMSIS Tool) ein kompaktes CMSIS-konformes Headerfile ohne den ganzen HAL Kram bauen.
:
Bearbeitet durch User
Kai schrieb: > Wie gesagt HAL ist gut gemeint, SPL ist besser! > Bräuchte die gerade für einen STM32F7, gibt es aber nicht. ST hat leider auf ihre C-beschränkte Kundschaft gehört und bietet mittlerweile für so gut wie alle Prozessoren und Peripherie alternative Treiber names "LL" (low-level) an. Siehe etwa hier: http://www.st.com/content/ccc/resource/technical/document/user_manual/45/27/9c/32/76/57/48/b9/DM00189702.pdf/files/DM00189702.pdf/jcr:content/translations/en.DM00189702.pdf Im wesentlichen sind das kleine Wrapper auf direkte Register-Zugriffe, die jeder vernünftige Compiler wegoptimieren sollte. Das ganze Drumherum mit Error-Handling und Status-Abfragen und sonstige HAL-Späße entfallen damit. Was wir natürlich wirklich gebraucht hätten wäre ein vernünftiges C++ HAL, aber dafür müsste man halt a) Tatsächlich platformunabhängige Treiber für seine Kundschaft bereitstellen wollen b) Softwareentwickler einstellen die mehr als nur Register setzen können...
Hallo Christian! ich wollte ebenfalls vom ATMEGA zum STM32 weil der ATMEGA mir zu langsam und auch langweilig wurde. Habe ein STM32-Board (15 Euro) besorgt und getestet ob es mit Assembler noch machbar ist. Also eine LED zum Blinken habe ich zwar in Assembler hinbekommen. Aber dann habe ich die ganze Software für den STM32 vom PC geschmissen und das Board verschenkt. Ich musste einsehen: ohne C ist es sinnlos! Die Dokus für den STM32 ist nur für C ausgelegt und nach meiner Ansicht dahingeluscht. Der PIC32 ist dagegen besser dokumentiert, jedenfalls für Assembler. Mein Wahlspruch ist: "Eigenes Wissen geht vor fremdes Wissen!" Und auch deshalb macht mir Assembler mehr Spaß als C. Vor hundert Jahren habe ich in Turbo-C programmiert. Dann bin ich bei den 16-bitter PIC24/dsPIC gelandet und den setze ich jetzt immer ein. Schau Dir mal die Dokus für die dsPIC-Reihe an! Der Befehlssatz ist Assembler-freundlich und deutlich besser als beim ATMEGA. Und sehr gut dokumentiert. Mit den internen Oszillator benötigen fast alle Befehle mur einen 34ns-Takt. Vor allem der Befehlssatz macht den Prozessor schnell. Mal 2 Beispiele: Für die Bedienung einer Sprungtabelle benötigt der ATMEGA 14 Befehle, beim dsPIC nur einen. Für die Addition von BCD-Zahlen hatte der 8051 den Befehle daa. Beim ATMEGA war dazu ein Unterprogramn mit 100 Befehle nötig. Beim dsPIC ist der Befehl wieder vorhanden. Zum Debuggen / Prorammieren verwende ich den PICkit3 und PICkit3.5. Kosten beim CH-Lieferant etwa 10 Euro. Funktionieren beide! Als IDE verwende ich die alte MPLAB IDE 8.91 Version. Die neuere MPLABX habe ich gleich wieder entsorgt. Den IDE-Editor verwende ich nur beim Debuggen, zum schreiben PSPad. Der dsPIC ist vor allem für Assembler-Programmierer interessant, C-Programmierer merken nichts und werden beim STM32 bleiben. Gruß Peter
Vincent H. schrieb: > Was wir natürlich wirklich gebraucht hätten wäre ein vernünftiges C++ > HAL, gibt es mit mbed, da wirkt nicht nur STM mit. Zu den IDE: https://www.rowley.co.uk/arm/index.htm wurden hier schon lange nicht mehr genannt, die gibt es aber auch immer noch. Da hatte ich mal mit den ARM7TDMI gespielt, das funktionierte da auch auf Anhieb. Persönlich komme ich mittlwerweile mit den Eclipse basierten gut zurecht, man muss für den Start nur mit einem Tutorial anfangen sonst sucht man sich die Finger wund.
Johannes S. schrieb: > Vincent H. schrieb: >> Was wir natürlich wirklich gebraucht hätten wäre ein vernünftiges C++ >> HAL, > > gibt es mit mbed, da wirkt nicht nur STM mit. Nein mbed ist zu "high-level". Das bedient eher die IoT-Schiene. Ich kenn mich damit zwar nicht wirklich aus, aber ich wage zu bezweifeln dass ich damit etwa 3x ADCs initialisieren kann, die mir synchron zu einem Timer Werte via DMA liefern. Theoretisch spräche aber nichts dagegen eine vernünftige C++ Bibliothek anzubieten die genau das kann... Platformunabhängigkeit definiere ich dabei als "innerhalb einer Prozessor-Familie", bzw. "innerhalb eines Herstellers". Dass ich etwa Prozessoren von ST und von NXP für mein ADC/Timer Beispiel unter einen Hut bekomm halte ich auch für illusorisch. Dazu bietet die jeweilige Peripherie zu viele Unterschiede. Aber grad innerhalb einer Firma gibts... wwi 2, 3 oder vielleicht 4 verschiedene Timer "Designs". Da wär schon ein feines Interface drin.
OH die STM32 low-level-lib ist mir noch nie untergekommen, gut ich suche auch nicht jede Woche danach. Sieht auf den 1. Blick nach SPL aus, ein Diff wird dann zeigen was Sache ist. Die PIC Teile sind auch nett. Ein ARM CORTEX M würde ich aber für die meisten Sachen vorziehen.
Kai schrieb: > Versuche mal einen Code von einem 8048 nach 8052 nach AVR nach STM32 zu > Portieren. Ich hab das einmal probiert, von P87C751 (abgekündigt) nach ATmega8, aber die Befehle sind viel zu unterschiedlich. Was man beim 8051 direkt im RAM machen konnte, braucht beim AVR erstmal LD/ST in ein Register. Und auch die vielen Bitbefehle hat der AVR nicht. Auch hatte ich Probleme, mich wieder in die Datenstruktur einzuarbeiten, die ich mir damals ausgedacht hatte. Ich hab dann aufgegeben und es einfach nach C umgeschrieben. Es war gar nicht schwer. Probleme bereitete nur der I2C-Multimasterbug. Da muste ich für das I2C nach langer Buganalyse noch Timeoutüberwachung mit Retry einbauen.
In C besteht überhaupt eine Chance, ein Programm schmerzfrei auf eine andere Plattform zu portieren, in ASM wird das schwierig. Ich bin seit einigen Jahren dabei, meinen eigenen HAL zu entwickeln, aber letztendlich wird das eher eine unendliche Geschichte... Das geht schon bei den Headerfiles los, die man auf einen gemeinsamen Standard hieven muss, um überhaupt die Übersicht zu behalten. Bei manchen Controllern (z.B. Renesas RL78) bleibt sogar nichts anderes übrig, als die Files aus den Datenblättern zu erstellen, da deren IDE ein "exotisches" Binärformat für die Registerdefinitionen nutzt. Und dann geht es weiter: Welchen gemeinsamen Nenner zwischen den Controllerfamilien gibt es, mit dem man praktisch noch etwas anfangen kann? Und es geht noch weiter: Welchen Compiler kann ich benutzen? Für viele Plattformen gibt es den GCC, bei manchen ist die letzte Version schon ein paar Jahre her (HCS12, MSP430), andere wiederum werden nur vom SDCC unterstützt. Kommerzielle Compiler habe ich dabei außer Acht gelassen, da es die meist nur für Windows gibt und damit für mich nicht relevant sind. Aber auch beim GCC musste ich irgendwann einen Stand "einfrieren" (4.92). Die Portpin-Routinen z.B. habe ich meist in ASM geschrieben, für den STM32F0xxx sehen bei mir dann so aus:
1 | //------------------------------------------------------------------------ |
2 | // set Portpin level |
3 | // PAR1 (int) PORT Nr |
4 | // PAR2 (int) PIN Nr |
5 | // PAR3 (int) level |
6 | //------------------------------------------------------------------------ |
7 | set_portpin_level: cmp r2,#0 |
8 | bne set_portpin_one |
9 | |
10 | set_portpin_zero: movs r2,#1 |
11 | lsls r2,r1 |
12 | str r2,[r0,#0x28] //BRR |
13 | bx lr |
14 | |
15 | |
16 | set_portpin_one: movs r2,#1 |
17 | lsls r2,r1 |
18 | str r2,[r0,#0x18] //BSRR |
19 | bx lr |
Wobei die PORT Nr eine Konstante aus dem Chip-spezifischen Headerfile ist. Um einen Portpin als Output zu setzen, wird es schon aufwändiger, da man den Port auch im RCC aktivieren muss. Aber in den meisten Fällen macht man das einmal am Programmanfang. Von den Chipherstellern darf man letztendlich in der Richtung sowieso nichts erwarten, denen geht es mehr darum, die Kunden möglichst fest an sich zu binden. Das wäre ja noch schöner, wenn man seine Projekte einfach auf einen Controller der Konkurrenz portieren kann. Und nach meinen Erfahrungen, das ist wirklich schön...
Beitrag #5465822 wurde von einem Moderator gelöscht.
Vincent H. schrieb: > Was wir natürlich wirklich gebraucht hätten wäre ein vernünftiges C++ > HAL, aber dafür müsste man halt > a) Tatsächlich platformunabhängige Treiber für seine Kundschaft > bereitstellen wollen > b) Softwareentwickler einstellen die mehr als nur Register setzen > können... hat sich eigentlich jemand von euch schon mal https://modm.io/ angeschaut? Mir fehlts da leider an c++-Kentnissen ums wirklich bewerten zu können, aber auf den ersten Blick sieht es nach einem guten Ansatz aus.
Christian K. schrieb: > Kai schrieb: >> Entschuldigung wenn ich das so sage, aber wer heute noch alles in >> Assembler macht der sollte endlich mal in Rente gehen und seine >> Lochkarten mitnehmen. > > Aua... :-)) > Ich bin 36 ;-) Mal ganz nüchtern betrachtet: Ich bin 36 - sagt eigentlich Ggarnichts wenn jemand vom "Werner Syndrom" geplagt ist, ist er biologisch schon längst über die Sechzig :-( Das betrifft dann auch das Cerebrum. Das ist jetzt keine Unterstellung sondern vieleicht eine Erklärung. (und der TO weiß noch gar nichts davon :-(
Dr.Werner schrieb: > Mal ganz nüchtern betrachtet: > Ich bin 36 - sagt eigentlich Ggarnichts wenn jemand vom "Werner Syndrom" > geplagt ist, ist er biologisch schon längst über die Sechzig :-( > Das betrifft dann auch das Cerebrum. > Das ist jetzt keine Unterstellung sondern vieleicht eine Erklärung. > (und der TO weiß noch gar nichts davon :-( Na komm... Ich hätte mir denken sollen dass das Thema alle Zutaten eines Religionskrieges C / ASM beinhaltet - auf der Ebene müsse wir jetzt allerdings nicht diskutieren. Ich wollte einen Assembler für ARM ohne Schnickschnack... Gibt es scheinbar nicht -> Schade aber kann man nichts machen... Hinweis auf C als Alternative -> ist berechtigt... Mein momentanes Fazit ist: C wäre zu viel Zeitverlust. Nicht im Sinne von Prozessortakten - da habt ihr mich überzeugt, sondern im Sinne von: müsste ich erst von Grund auf lernen UND gut darin werden. Bleibt also erst mal alles bei AVR / Assembler. Leistung ist bisher ausreichend und wenn in Zukunft mehr benötigt wird gibt es immer noch die assemblerfreundlichen Xmegas mit 32Mhz, Events, DMA und vielen Timern.
Christian K. schrieb: > Ich wollte einen Assembler für ARM ohne Schnickschnack... > Gibt es scheinbar nicht Was spricht gegen den ARM-Assembler von ARM selbst? Oder den vom GCC? Verstehst du unter einem Linker Schnickschnack?
Der blanke Assembler selbst hat keinen zur Peripherie passenden Simulator. Man kann zwar den Code an sich debuggen, befindet sich allerdings in Bezug darauf was z.B. UART oder Timer gerade machen völlig im Blindflug. Das ist das schöne an AVR Studio Assembler: - Schlanke und sehr schnelle IDE. Ein Built ist in sekundenbruchteilen abgeschlossen und der Simulator läuft. - Alles wichtige vorkonfiguriert und nahtlos eingebunden. Neues Projekt -> verwendeten AVR auswählen -> Assembler auswählen -> alles fix und fertig konfiguriert (der Controller an sich aber noch blank ohne irgendwelche Abstrahierungsmonstren a la HAL). - Ein guter und übersichtlicher Simulator incl. aller Peripheriemodule. Alles vorhanden was (für meine Zwecke) benötigt wird und einem das Leben erleichtert - ohne viel darüber hinaus gehenden Schnickschnack. Passt einfach - hatte mich damals sofort überzeugt während ich in Bezug auf ARM jetzt seit Wochen X Programme von kostenlos bis 8000 Euro getestet habe von denen mir bisher keines auch nur halbwegs gefallen hat. Die mögen vielleicht für abstraktere und komplexere Projekte ganz toll sein wenn man sich drauf einlässt oder lassen muss. Für meine Zwecke mit eigentlich gar nicht sonderlich komplizierter nur recht hardwarenaher Aufgabenstellung war allerdings einfach nichts dabei.
:
Bearbeitet durch User
Christian K. schrieb: > Das ist das schöne an AVR Studio Assembler: > > - Schlanke und sehr schnelle IDE. Ein Built ist in sekundenbruchteilen > abgeschlossen und der Simulator läuft. Was hat die IDE mit dem Assembler zu tun? ARM Assembler sind genau so schnell. Christian K. schrieb: > - Alles wichtige vorkonfiguriert und nahtlos eingebunden. Neues Projekt > -> verwendeten AVR auswählen -> Assembler auswählen -> alles fix und > fertig konfiguriert. Ja, bei den AVR's ist das einfach. Bei der gigantischen Menge an existierenden verschiedenen ARM Cortex-M ist das komplizierter umzusetzen. Aber bei IDE's wie dem Atollic Studio geht das auch. Christian K. schrieb: > - Ein guter und übersichtlicher Simulator incl. aller Peripheriemodule. Bei der komplexen Peripherie der Cortex-M ist so etwas halt schwierig. Aber m.W. hat Keil µVision einen Simulator. Aber der Simulator hat natürlich auch nichts mit dem Assembler zu tun, genau so wenig wie ein Schraubenzieher mit einer Säge zu tun hat. Dank JTAG-Debuggings ist der Simulator auch deutlich weniger wichtig. Christian K. schrieb: > Für meine Zwecke mit > eigentlich gar nicht sonderlich komplizierter nur recht hardwarenaher > Aufgabenstellung war allerdings einfach nichts dabei. Man kann nicht alles haben... Mit ein wenig Einarbeitung sollte man mit den vorhandenen IDE's klarkommen.
Christian K. schrieb: > (der Controller an sich aber noch blank ohne > irgendwelche Abstrahierungsmonstren a la HAL). Will halt kaum einer. Kann man aber auch problemlos haben. Wenn du schon deine Arbeitszeit durch Assembler verfünffachst macht das Deaktivieren der HAL doch auch keinen Unterschied mehr...
> Was hat die IDE mit dem Assembler zu tun? ARM Assembler sind genau so > schnell. Sehr viel wenn die IDE drum herum das gesamte System einbremst. Bringt nun mal nichts wenn der Assembler selbst in ner halben µs fertig ist, das Framework den Computer anschließend aber noch 15 Sekunden blockiert bevor man mit irgendwas weitermachen kann. Klar... kann und muss man bei kostenlosen IDEs verschmerzen - dass es nervt und eigentlich ne schwache Leistung ist wirst du mir allerdings sicherlich zustimmen. Google bringt bei "Eclipse slow" 33 Millionen! Treffer. Scheint nicht nur an meiner "alternden" Geduld zu liegen ;-) > Bei der komplexen Peripherie der Cortex-M ist so etwas halt schwierig. Ja und nein... Bezogen auf ARM im allgemeinen und herstellerübergreifend gebe ich dir völlig Recht. In Bezug auf STM32 konkret sehe ich es anders. Die Peripherie dieser Prozessoren ist so besonders nun auch wieder nicht. Die AVR Xmegas haben ähnlich komplexe Peripherie und werden vom AVR Studio Simulator vorbildlich unterstützt (Xmega wie gesagt - nicht nur die erheblich einfacheren Megas). Ich habe einige Stunden Datenblätter gelesen und mich ständig an die Xmegas erinnert gefühlt. Andere Registernamen, andere Bits, oft ein paar Zusatzfeatures, doch im Endeffekt keine weltbewegenden Unterschiede. Fazit: Atmel hat seit Jahren genau die Kombi Assembler / Simulator die ich schätzen gelernt habe - deswegen habe ich in meinem Eingangsposting auch ausdrücklich "Simulator" dazugeschrieben. Für STM32 gibt es das scheinbar nicht - kein Vorwurf, nur eine Feststellung und für mich natürlich doof wenn ich gewohnt bin intensiv mit Simulator zu arbeiten. > Aber m.W. hat Keil µVision einen Simulator. Aber der Simulator hat > natürlich auch nichts mit dem Assembler zu tun, genau so wenig wie ein > Schraubenzieher mit einer Säge zu tun hat. Wenn du z.B. einen Webserver schreibst ist das in der Tat ziemlich egal - da ist die Hardware nur Beiwerk und wird zu Recht von Sachen wie HAL oder Standard Library erschlagen. Bei Entwicklungen die sich zentral um die Hardware drehen ist ein Simulator allerdings sehr hilfreich auch wenn er mit dem Assembler an sich wenig zu tun hat. Jetzt C lernen und dann auch noch die Peripherie im Blindflug oder nur direkt am Board debuggen zu können ist mir echt zu viel. Nicht alles lässt sich am Board ohne weiteres real ohne größeren Aufwand auslösen was im Simulator ein paar Klicks sind. Mein Fazit aus der Diskussion ist bisher dass STM32 und AVR für verschiedene Anwendungen vorgesehen sind. STM32 scheint mir für komplexere Sachen vorgesehen zu sein wo die Hardwareseite von Firmwarepaketen gehandhabtes Beiwerk ist so dass man sich auf anderes konzentrieren kann. Hardwareseitiges dann eher als Beifang weil man die Plattform halt kennt und das Preis / Leistungsverhältnis so extrem gut ist dass man einfach nen schnelleren Typ wählt und bei HAL bleibt. AVR dagegen die sehr hardwarenahe "bare metal" Seite. Merkt man auch in den Datenblättern und Appnotes -> Beispiele kommen zuerst in Assembler, dann in C. Manchmal auch nur in Assembler...
Christian K. schrieb: > Bringt nun mal nichts wenn der Assembler selbst in ner halben µs fertig > ist, das Framework den Computer anschließend aber noch 15 Sekunden > blockiert bevor man mit irgendwas weitermachen kann Das ist mir noch nie untergekommen. Eclipse kompiliert bei mir in ca 100ms mehrere C, C++ und Assembler Dateien. Christian K. schrieb: > Für STM32 gibt es das scheinbar nicht Doch. Im Keil uVision. Christian K. schrieb: > Bei Entwicklungen die sich zentral um die Hardware drehen ist ein > Simulator allerdings sehr hilfreich auch wenn er mit dem Assembler an > sich wenig zu tun hat. Ich hab schon jede Menge Low Level Treiber ohne Simulator, mithilfe des Debuggers, geschrieben. Hat meistens gut funktioniert. Problematisch sind nur die Dinge, die nicht dokumentiert sind. Die sind aber im Simulator bestimmt auch nicht korrekt umgesetzt. Gerade arbeite ich z.B. mit einem Cortex-A8 Bare Metal, der ist noch viel komplexer als die STM32. Da ist eine Menge Assembler sogar nötig zur Steuerung der MMU bzw. VMSA. Das geht supi in Eclipse unter Linux mit GCC und GNU Assembler.
> Doch. Im Keil uVision. Keil hatte ich ausprobiert und hat auch den besten Eindruck gemacht. Nur wie schon geschrieben: - Keil MDK ist preislich völlig jenseits des Budgets und in der limitierten Version ist ausgerechnet der Assembler nicht verfügbar. Wäre nur dann ein Kandidat falls ich doch irgendwann C lerne und die limitierte Version kommerziell genutzt werden darf. Wäre dennoch ein risky move sich von derart hochpreisiger Software abhängig zu machen. Wenn das kostenlose Angebot irgendwann eingestellt wird und z.B. nach einem PC-Wechsel keine Aktivierung mehr möglich ist hätte ich ein ernsthaftes und teures Problem. Für mich ist das Thema erst mal weitgehend erledigt. Meine Hoffnung war von der sehr einfachen und komfortablen AVR Assembler Simulator Kombi zu einer ähnlichen Assembler Simulator Kombi für STM32 wechseln zu können ohne dabei eine neue Programmiersprache lernen zu müssen oder mehrere tausend Euros los zu werden. Hat sich als falsche Vorstellung herausgestellt, ist allerdings nicht weiter tragisch, da die Leistung der AVRs genügt und mit den Xmegas noch gut Luft nach oben ist. Generell zum Thema ASM / C oder sonstige Programmiersprachen: - Jeder hat sein Steckenpferd das er toll findet - meist die Sprache die man halt mehr oder weniger zufällig gelernt hat ;-) - Ich teile Programmiersprachen weniger in "gut" oder "schlecht", sondern in "zweckmäßig" und "unzweckmäßig" ein. Zu zweckmäßig gehört allerdings nicht nur die objektive Eignung einer Sprache für den konkreten Einsatzfall, sondern auch ob und wie gut man sie beherrscht. - Wenn ich 2 Sprachen habe von denen ich eine sehr gut beherrsche und die andere gar nicht ist letztere zwangsläufig erst mal sehr unzweckmäßig, egal wie gut sie zur Aufgabenstellung an und für sich passen mag. Bringt nichts wenn man erst mal ein Jahr mit lernen und üben verbringt bevor man an die eigentliche Aufgabe ran kann. Hat weniger mit Faulheit oder Weigerung über den Tellerrand zu blicken zu tun als einfach damit dass der Tag nur 24 Stunden hat und es auch noch andere Dinge als Programmieren gibt. (Schadet natürlich dennoch nicht sich mit der Sprache später zu befassen wenn es Zeit und Lust erlauben)
Christian K. schrieb: > Keil MDK ist preislich völlig jenseits des Budgets und in der > limitierten Version ist ausgerechnet der Assembler nicht verfügbar. Ich rede von uVision. Da gibt's ne gratis Version von (bis 32kB wimre). Und die kann natürlich assemblieren und Debuggen. habe ich schon genutzt. Wie eine IDE ohne Assembler funktionieren soll ist eh schleierhaft - wie soll da der vom Compiler generierte Code assembliert werden? Und der Startup Code? Wenn du das kommerziell nutzen willst hast du doch Geld. Da deine Arbeitszeit auch nicht so wichtig ist scheint Wirtschaftlichkeit eh egal zu sein. Würde es wirklich um Geld gehen könntest du mit Eclipse&GCC eine auch kommerziell nutzbare komplett kostenlose Umgebung haben, in der du in C und C++ auch noch viel schneller an Ergebnisse kommst. So kannst du dir nach den nächsten 3 Aufträgen fix eine heiß geliebte Assembler IDE in Vollversion leisten... Was für Kunden sind das, die Projekte in Auftrag geben die man mit AVR's erledigen kann und die bereit sind das Geld für eine Assembler Entwicklung auszugeben? Gibt's da keinen Preiskampf und Konkurrenz?
Christian K. schrieb: > - Ein guter und übersichtlicher Simulator incl. aller Peripheriemodule. Frage: Wieso benötigst du einen Simulator? Ich kann mit dem Debugger sämtliche Register direkt an der Hardware auslesen (ohne der Wahrscheinlichkeit eines Fehlers durch einen Simulator Bug) und gleichzeitig überprüfen, ob die Hardware macht, was ich will. Da scheint mir ein Simulator eher kontraproduktiv. mfg
Christian K. schrieb: > Google bringt bei "Eclipse slow" 33 Millionen! Treffer. > Scheint nicht nur an meiner "alternden" Geduld zu liegen ;-) Es scheint eher an Deinem mittelalterlichen PC zu liegen. Meiner ist nur 5 Jahre alt und ich kann bei Eclipse keinen einzigen Vorgang bemerken (außer dem Start am Morgen [6 Sekunden]) der länger als ein Augenzwinkern benötigt. Wenn bei Dir das Kompilieren 15s länger dauert als ohne IDE dann steckst Du entweder in einer üblen Zeitverzerrungs-Anomalie fest (bekommst Du schon graue Haare während alle anderen noch jung aussehen?) oder irgendwas anderes an Deinem Setup schreit nach dringender Erneuerung.
:
Bearbeitet durch User
Christian K. schrieb: > Für mich ist das Thema erst mal weitgehend erledigt. > Meine Hoffnung war von der sehr einfachen und komfortablen AVR Assembler > Simulator Kombi zu einer ähnlichen Assembler Simulator Kombi für > STM32 wechseln zu können ohne dabei eine neue Programmiersprache lernen > zu müssen oder mehrere tausend Euros los zu werden. Hast du dir schon Embedded Studio und Ozone angeschaut? Embedded Studio sollte alles können, was du dir wünschst und liegt in deinem Preisrahmen: https://www.segger.com/products/development-tools/embedded-studio/ Ozone ist ein reiner Debugger: https://www.segger.com/products/development-tools/ozone-j-link-debugger/
Til S. schrieb: > Embedded Studio sollte alles können, was du dir wünschst und liegt in > deinem Preisrahmen Aber auch nur, wenn er denn schon einen J-Link hat oder dessen Preis unter den Tisch fallen lässt.
Christopher J. schrieb: > Aber auch nur, wenn er denn schon einen J-Link hat oder dessen Preis > unter den Tisch fallen lässt. Früher oder später hat jeder einen J-Link. Man kann den Vorteilen nicht für immer widerstehen, irgendwann hat man einen schwachen Moment, der Widerstand bricht zusammen, dann hat man einen.
Bernd K. schrieb: > (bekommst Du schon graue Haare während alle anderen noch jung aussehen?) > oder irgendwas anderes an Deinem Setup schreit nach dringender > Erneuerung. Sagte ich doch: Den armen Mann plagt das "Werner" Syndrom. Eigendlich sollten wir den armen Kerl helfen seinen "Prozess" so angenehm wie möglich zu gestalten. ;-)
Felix F. schrieb: > Frage: Wieso benötigst du einen Simulator? Ich kann mit dem Debugger > sämtliche Register direkt an der Hardware auslesen (ohne der > Wahrscheinlichkeit eines Fehlers durch einen Simulator Bug) und > gleichzeitig überprüfen, ob die Hardware macht, was ich will. Da scheint > mir ein Simulator eher kontraproduktiv. Du kannst aber mit einem Simulator Dinge in der Hardware sehen, an die kein Debugger kommt... z.B. kann der Simulator der Embedded Workbench auch bei einem Cortex-M0(+) (oder AVR oder ...) ordentliches ETM Trace, was in Hardware an den fehlenden Trace-Pins und der nicht implementierten ETM Unit scheitert ;-)
Andererseits, wer nutzt noch einiger Erfahrung den Simu noch? Am Anfang hab ich den auch verwendet, aber inzwischen seit Jahren nicht mehr. Meist scheitert es daran, dass der Aufwand komplexe Signalverläufe für die Simu zu generieren größer ist als das Ding einfach in Echtzeit zu beobachten und an entscheidenden Stellen Debug Infos über Uart, Display, Oszi oder blinkende LED auszugeben.
Christopher J. schrieb: > Aber auch nur, wenn er denn schon einen J-Link hat oder dessen Preis > unter den Tisch fallen lässt. Nicht unbedingt, es ging ja um ein Nucleo Board mit ST-Link OB, das kann man in einen J-Link umflashen. Aber ansonsten hast du natürlich Recht, das sollte man mit erwähnen.
Bernd K. schrieb: > Früher oder später hat jeder einen J-Link... ...in der Schublade herumsedimentieren. Ja, ich auch (edu), dazu nen ULink (klasse Briefbeschwerer) und diverse auf Evalboards aufgelötete Teile. Auch die sedimentieren so vor sich hin. W.S.
W.S. schrieb: > ...in der Schublade herumsedimentieren. Tut mir Leid für dich, dass du dein Hobby nicht ausüben kannst. Keine Zeit? Familie? Zu viel Stress im Beruf?
Christian K. schrieb: > Ich wollte einen Assembler für ARM ohne Schnickschnack... > Gibt es scheinbar nicht -> Schade aber kann man nichts machen... > Hinweis auf C als Alternative -> ist berechtigt... Für die Assembler-Fans gibt es jetzt mein ARM-ASM-Tutorial. Bietet zwar keine fertige IDE, aber wenn man den dortigen Workflow verstanden hat, ist die IDE ziemlich egal.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.