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.
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.