Hallo,
ich befasse mich nach rund 12 Jahren PICsen mit mehr als 100
privat/beruflichen Designs nunmehr seit Jahresbeginn rein im
Hobbybereich mit dem ARM7 von NXP. Vorher habe ich vom 16er PIC bis zum
18er PIC mit dem CCS Compiler gearbeitet, der eine komplette HAL
beinhaltet. Code ist nicht portierbar aber das war auch nie nötig,
ebenso wenig wie die Interna eines PIC verstehen zu müssen bis auf
Ausnahmen wie SPI und UART. I2C per Hand programmieren wäre ein Drama
gewesen, durch die HAL ist das Ergebnis in Minuten fertig und die I2C
Bausteine reagieren wie gewünscht. Assembler war nie ein Thema, das habe
ich das letzte Mal 1995 benutzt auf dem 8051 und als altmodisch, nervig,
unstrukturiert und extrem unlesbar abgetan seitdem Speicher und
Geschwindigkeit keine Rolle mehr spielen. Angefangen habe ich mit
Handumrechung in Tabellen 1983 auf dem 8048 und einem Z80 Board mit Hex
Tastatur von keil als diese gerade gegründet waren.
Ich bezeichne mich als guter Programmierer, habe früher auch sehr grosse
Windows Programme unter Visual C++ geschrieben wo natürlich keine
Hardwareprogrammierung erforderlich ist, es gibt keine Register, eher
muss man wissen welche der hundertausend Bibliotheken im Windows System
hat die Funktion, die ich brauche.
Mit dem ARM7 aber geht es nicht so recht rund, statt flüssig Code zu
schreiben sitze ich stundenlang am Verständnis der Register, Interrupts,
der Bitsschieberei und Ausmaskiererei usw. Die Uart, beim PIC ein
einfach zu verstehendes Teil ist beim ARM7 geradezu überladen mit
Funktionen, tausend IRQs, die unter irgendwelchen Bedingungen erzeugt
werden, einer sogar wenn 3.5 - 4.5 Perioden der Baudrate kein Zeichen
ankam usw. Viele IRQ Register ändern ihren Wert beim blossen Lesen, beim
SCS Register führt ein direkter Schreibzugriff zum Systemstillstand, ich
kann nur read-modify-write machen. Sicher, die enorme
Rechengeschwindigkeit ist beeindruckend, 32 Bit machen was her, kein
Gehampel mehr mit zu wenig Speicher, klotzen statt kleckern.
Es erinnert mich an Linux, alles installiert, vier Wochen lang erkundet
und eingerichtet, sogar die Konsole ansatzzweise verstanden aber dann
immer weniger benutzt, weil unter Windows alles viel schneller läuft und
einfacher zu verstehen ist, keine Skripte, kein Herumstochern in
Systemeinstellungen, kein Theater mit USB Geräten. Schliesslich flog
Linux von der Platte. So ähnlich gehts mir grad mit dem ARM7, entweder
weitermachen oder doch wieder in die Schublade, weil mit den PICs ja
doch alles funktioniert, einfacher und schneller zum Ergebnis.
Wie waren Eure Erfahrungen, wer hat den Umstieg gut gemeistert und wer
ist doch wieder beim 8 Bit Avr gelandet?
Gruss,
Christian
Mir geht das eher andersrum. Ich mag eigentlich nur HALs die ich selber
gestrickt habe. Nicht zuletzt deshalb, weil die meisten Hersteller-HALs,
denen ich bisher begegnet bin, das "A" in "HAL" stäflich vernachlässigen
und in meinen Augen nur allzu oft die Abhängigkeit vom Verständnis der
Hardware-Register durch die Abhängigkeit von Verständnis der
Parametrisierung und Reihenfolge der HAL-Aufrufe ersetzen. Und ich damit
nichts gewonnen habe. Zumal so mancher HAL dank ausgiebiger
Parameterisierung über structs auch noch ausgesprochen ineffizient ist.
Ich mache das folglich tendentiell andersrum. Und stricke mir
Software-Module, die nach oben hin ziemlich ähnlich und vorzugsweise
einfach aussehen, und nach unten auf die unterschiedliche Hardware
verschiedener Controller aufsetzen.
Aber wenn du Wert auf HALs legst, dann vergiss NXP und schau dich
beispielsweise bei ST um. Für die STM32 gibt es das.
Aber eines ist klar: Wenn du Probleme mit der Komplexität hast, dann
bleib bei 8bittern, egal ob PIC oder AVR. Die 32bitter sind alle
ziemlich komplex, und zwar mit deutlich ansteigender Tendenz. So ist der
Interrupt-Controller der Cortex-M3 zwar klar besser als die Varianten
der LPC2000, aber auch deutlich komplexer, und schon die Lektüre der
Dokumentation dürfte so manchen gleich am Anfang aus der Kurve
schmeissen.
Einfach mal irgendwo reinpieksen und hoffen das mehr dabei rauskommt als
heisse Luft, das funktioniert bei PIC/AVR, aber nicht bei ARMs. Schon
garnicht mit Barebone Entwicklungsumgebungen wie WinARM/Yagarto&Co. Da
ist nützlich, wenn man das Teil im Gesamten vorher mal erfasst hast.
Alternativ kann man sich Entwicklungsumgebungen suchen, in denen einiges
schon vorgekaut ist. Man keine Startup-Codes und Linker-Scripte basteln
muss. Und die Beispiele auch für den eigenen Chip vorhanden sind und
nicht nur für den nahen aber nicht ganz kompatiblen Vetter davon. Ist so
halt teuerer.
>>Alternativ kann man sich Entwicklungsumgebungen suchen, in denen einiges>>schon vorgekaut ist. Man keine Startup-Codes und Linker-Scripte basteln>>muss.
Habe ich, Rowley Crossworks, kein Makefile, keine Linkerscripts, kein
Startup usw. Hierarchie und Ordner für Files, klick & play. Bei Winarm
hätte ich auch schon abgewinkt, hatte das nur einmal installiert.
Ich schreibe derzeit meine HAL aber die passt auch nur auf mein Board
und auf kein anderes. Routinen wie uart_init(Baudrate) usw. um überhaupt
damit arbeiten zu können.
Hm ich kann dich verstehen. Ich hab auch viel mit AVRs gebastelt, und
als ich das erste mal was mit arm7 gemacht hab, war ich auch ganz schön
erschlagen. allein da eine led zum leuchten zu bringen und eine taste
auszuwerten dauert ne ganze weile, man muss sich halt erstmal mit dem
startup-code (pll etc.) beschäftigen, hardwarezugriff und so weiter.
viel umständlichder fand ich noch, mich erstmal mit eclipse, yagarto,
gdb, telnet, openocd und irgendwelchen skripten und so beschäftigen zu
müssen. beim avr ist das alles wesentlich einfacher.
dennoch muss ich sagen bieten einem die größeren controller einfach viel
mehr möglichkeiten. und es gibt da auch varianten, die einem viel arbeit
abnehmen können. für infineon controller (zb xc167) gibts den "dave". da
klickt man auch an was für timer und interrupts und so man braucht und
der bastelt einem das codegerüst zusammen - sehr praktisch und fast
einfacher als auf dem avr. dennoch muss man sich auch dort mit den
interna beschäftigen und die compiler sind meist deutlich teurer
(zumindest im gegensatz zum kostenlosen avr-gcc).
ich würd dir raten - bleib dran. wenn man sich einmal reingefuchst hat,
dürfte man auch mit großen controllern gut klarkommen.
Hi,
ja ich bin ja dran. Nur es nervt, wenn nach 2 Tagen Arbeit immer noch
kein Uart IRQ ausgelöst wird, wenn ich U0THR beschreibe. Habe die Uart
auf Fifo umgeschrieben und ISR Steuerung damit die automatisch läuft
sobald ich mit sprintf etwas in einen Array schreibe aber ich suche mich
dämlich nach der Ursache warum die ISR nicht anspringt, ob da irgendwo
ein Bit vergessen wurde zu setzen usw. Die Timer ISR arbeiten doch auch.
Eine eigene Frage?
Dieser Thread ist über 17 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
