mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Umsteiger PIC/Avr auf Arm7 - Erfahrungen


Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: Oliver Simmank (ollibass)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian J. (elektroniker1968)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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

Formatierung (mehr Informationen...)

  • [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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.