OffTopic: Neuentwicklung Firmware

Wenn unter den anderen Software-Themen kein passendes dabei ist oder wenn das Thema mehrere Bereiche überspant, dann versuche es hier einmal.
Lennart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 32
Registriert: 11.12.2009, 05:42
Wohnort: Berlin
Kontaktdaten:

OffTopic: Neuentwicklung Firmware

Beitrag von Lennart »

Ich wollte mal ne Frage an unsere Coder stellen...

Wie lange (in MannStunden) habt ihr etwa gebraucht um die erste lauffähige Version der C-Firmware zu entwickeln?

Ich selbst versuche mich gerade and einer für den ARM7 (AT91SAM7S) und komme nur extrem schleppend vorran. Was jedoch auch daran liegt, das ich mich das erste mal richtig mit der GNU Toolchain, Makefiles usw. auseinandersetze und die Architektur der ARM µC's recht umfangreich ist.
Mein Ziel ist es Lab-Module mit ARM µC zu entwickeln, da mir der ATmega zu wenig Ram/Flash hat um wirklich flexibel für zukünftige erweiterungen zu sein.

Wie gesagt, würde da gern mal ein paar Erfahrungen austauschen.
"When in trouble or in doubt, run in circles, scream and shout."
Aktuelle Projekte: DevilTrac, ArmLab
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: OffTopic: Neuentwicklung Firmware

Beitrag von psclab38 »

Lennart hat geschrieben:IWie gesagt, würde da gern mal ein paar Erfahrungen austauschen.
Hi Lennart,

wieviel Entwicklungszeit die Urversion der C-Firmware-Module (die DCG-C von amd-65) gebraucht hat, kann ich nicht sagen. Aber beispielsweise die Portierung der DCG2-C (mit meinen Erweiterungen) in die EDL2-C hat für die grundsätzliche Lauffähigkeit ca 2 Tage gedauert (so 2 * 10-12 Stunden). Da konnte ich aber das ganze Framework wiederverwerten, so daß es "nur" die Unterschiede waren :wink: In der Zwischenzeit sind ungezählt Stunden für die kleinen Fixes und Erweiterungen draufgegangen. Das habe ich nicht aufgeschrieben.

Neue Features dauern ihre Zeit, wie jetzt mit dem Arbitrary. Neu ausgedacht, so 20-30 Stunden, portiert heute von DCG2-C nach EDL2-C in 3 Stunden.

Ich verwende die GNU-Toolchain zusammen mit AVR-Studio4 von Atmel. Das paßt zusammen und wenn's mal richtig eingerichtet ist, dann verschwende ich keinen Gedanken an makefile etc. Wenn man's manuell macht, dann muß man natürlich erst mal alles im Detail verstehen und dann bei Bedarf auch wieder manuell ändern. Es gibt sicher auch andere IDEs für Atmel, aber zusammen mit dem Debugger ist es durchaus brauchbar.

Zu ARM7 speziell kann ich Dir leider nichts sagen...
Lennart hat geschrieben:Mein Ziel ist es Lab-Module mit ARM µC zu entwickeln, da mir der ATmega zu wenig Ram/Flash hat um wirklich flexibel für zukünftige erweiterungen zu sein.
Nun ja, es gibt ja auch größere Controller als den ATmega32 oder 664(P), mit mehr RAM und Flash. Die Frage ist, was willst Du damit machen?

Soo falsch sind die ATmega32 oder 664(P) für die lab-Module nicht. Die Rechenleistung ist beeindruckend, wenn man sich mal vor Augen hält, was die Dinger so mal eben "nebenbei" machen. :shock: Aber ich hätte gerne extra rausgeführte JTAG-Anschlüsse gehabt... :wink:

Setzt Du bei Deiner Entwicklung auf einer C-Firmware auf oder hast Du ganz von vorne angefangen?

Viele Grüße
Paul
Roddot
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 146
Registriert: 19.06.2008, 13:53

Re: OffTopic: Neuentwicklung Firmware

Beitrag von Roddot »

psclab38 hat geschrieben: Soo falsch sind die ATmega32 oder 664(P) für die lab-Module nicht. Die Rechenleistung ist beeindruckend, wenn man sich mal vor Augen hält, was die Dinger so mal eben "nebenbei" machen. :shock: Aber ich hätte gerne extra rausgeführte JTAG-Anschlüsse gehabt... :wink:
Ich halte die ATMegas echt für toll und habe mich nun etwas in die C Geschichten eingelesen.

Deshalb wollte ich ja auch diesen Sommer auf deine C Portierungen umsteigen.
Ich hoffe ich muss nicht alles auf 16Bit umbauen damit es reibungslos läuft. :)

Selber was in Hardware aufbauen (spielen) wollte ich aber erst mit den XMegas die kommen mir logischer daher und scheinen keine "Aufgebohrten" Familienmitglieder zu haben bei denen dann alles doch wider anders ist. Die sind ja nun lieferbar und an 3,3V kommt man ohnehin nicht herum.
3,3V ist auch OK da zB die KFZ-Bordnetzspannung beim Startversuch soweit einbrechen kann das 5V schon zu hoch ist.
Wegen der Größte und Abstände der Pins muss man dann halt schauen was es an Adaptern gibt.

Die haben nun neben den obligatorischen ADC auch einen DAC (oder waren es zwei) da ist wohl wirklich Geld zu sparen, zumal die Preisankündigungen für uns Bastler nur positives verlauten lassen.

Zur Software:
Denke du könntest uns hier sehr über die Anfängerhürden helfen wenn du die kostenlosen Atmel-Tools und die beiden ebenfalls kostenlos erhältlichen C "Kompiler" im Wiki beschreibst.
So das wir uns auf den "Einschissen" den ihr für besser haltet
In der CT war mal ein Hinweis auf einen kostenlosen Texteditor der alles kann was man so benötigt (automatische farbige Darstellung usw)

Meist ist es ja nicht notwendig immer die besten Tolls zu verwenden aber eben Die die auch die anderen aus dem Projekt im Einsatz haben schon.

Wäre toll wenn Ihr studierten/faktische Programmierer in dieser Richtung euch einigen könntet so das man in diesem Wiki alles nachlesen kann.

Ich hatte mir einen AVR-Dragon zugelegt und bis auf JTAG hatte ich schon alles im Benutzung letztens auch die HV-Parallel-Programmierung um einen Atmega32 wiederzubeleben.

Der "taugt" auch für die XMegas nur mit den 3,3V muss man dann aufpassen da einige bastel Schutzmaßnahmen die Spannungseinstellung (autosense) ausgehebelt haben.
Let's fets with Static-DC. :-)
Lennart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 32
Registriert: 11.12.2009, 05:42
Wohnort: Berlin
Kontaktdaten:

Re: OffTopic: Neuentwicklung Firmware

Beitrag von Lennart »

Stimmt schon, die Mega's sind für den Einsatzzweck ausreichend. Ich hab mir halt gedacht, wenn ich anfange µC's zu programmieren (aufm PC (DOS/Win/Linux) code ich bereits seit mehr als 10 Jahren) nehm ich einen leistungsfähigeren der auch für weit komplexere Anwendungen geeignet ist und zudem die Performance bzw. Speicher hat um auch mal größere Datenmengen zu Verarbeiten/Übertragen (z.B. Oszi/LA).

Ich code gerade am Framework rum. Der Code ist zur hälfte abgekupfert und zur hälfte neu erfunden um meinen eigenen Ansprüchen zu genügen. Bisher fertig ist ...

- Startup-Code (Assembler)
- CStartup (Assembler/C)
- OnChip-Devices
...- SPI (noch ohne DMA mit ca. 20Mbyte/s)
...- Interupt-/Exception-Händler
...- PIT (benutzt als Systemtimer/-zähler mit 10ns auflösung)
...- UART's (noch ohne DMA)
...- StringLib (siprintf usw.)
- Ext-Devices
...- EA DOGM128 Grafik Display 128x64 (Diverse Fonts, Text-Routinen, Grafik-Routinen mit max. 550fps)

...wie man sieht nicht wirklich viel. Allerdings hat das Einrichten von OpenOCD/Eclipse/Toolchain länger gedauert als erwartet. Und das debuggen innerhalb Eclipse funzelt auch noch nicht so wie es soll. Alles was das Makefile anbelangt war auch absolutes Neuland für mich.

Zum Zeitfaktor... das läßt sich bei mir auch nur schlecht abschätzen... ich sitze nun seit etwa 4 Wochen dran, allerdings immer nur so 2..3h pro Tag, vereinzelt auch länger. Ein blöder Fehler im Linkerscript hat etwa eine Woche gekostet.
"When in trouble or in doubt, run in circles, scream and shout."
Aktuelle Projekte: DevilTrac, ArmLab
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Re: OffTopic: Neuentwicklung Firmware

Beitrag von thoralt »

Hallo,
Roddot hat geschrieben:Ich hoffe ich muss nicht alles auf 16Bit umbauen damit es reibungslos läuft. :)
Was genau willst Du eigentlich auf 16 Bit umbauen? Die AVRs sind 8 Bit, und die weiter oben angesprochenen ARM7 besitzen einen 32-Bit-Kern. Willst Du noch ein neues Fass aufmachen?
Selber was in Hardware aufbauen (spielen) wollte ich aber erst mit den XMegas die kommen mir logischer daher und scheinen keine "Aufgebohrten" Familienmitglieder zu haben bei denen dann alles doch wider anders ist. Die sind ja nun lieferbar und an 3,3V kommt man ohnehin nicht herum.
Nun, das wird sich nicht vermeiden lassen. Die XMega-Familie steht noch am Anfang. In den nächsten Jahren wird sie, falls sie am Markt erfolgreich ist, erweitert werden. Und auch hier werden mit Sicherheit Erweiterungen vorgenommen, welche nicht mit dem "Ur-XMega" kompatibel sind. So war es immer und so wird es immer sein - kein Grund, sich zu ärgern.
3,3V ist auch OK da zB die KFZ-Bordnetzspannung beim Startversuch soweit einbrechen kann das 5V schon zu hoch ist.
Du scheinst mir recht oft auf den KFZ-Anforderungen herumzureiten. Willst Du das c't-Lab im Auto betreiben? Das dürfte nicht das richtige Anwendungsfeld sein... Außerdem: Es ist der falsche Ansatz, zu sagen, ein 3,3-V-Design wäre besser, weil die KFZ-Bordspannung _möglicherweise_ unter 5 V sinken kann. Wenn hier eine Unempfindlichkeit gefordert ist, dann muss eben ein Schaltregler her. Andererseits - sogar Autoradios gehen aus, wenn man den Motor anlässt. Falls Du also nicht vorhast, Steuergeräte für Airbags oder Einspritzanlagen zu entwickeln, dann baue einen Überspannungsschutz ein und verlasse Dich auf die Betriebsspannung. Ansonsten kriegst Du und die Leute um Dich herum nur unnötig graue Haare.
In der CT war mal ein Hinweis auf einen kostenlosen Texteditor der alles kann was man so benötigt (automatische farbige Darstellung usw)
Möglicherweise meinst Du Eclipse. Ich habe Eclipse für alle Quelltextprojekte im Einsatz, das hat den Vorteil, dass auch die Windows-Kollegen (ich arbeite am Mac) meine Projekte öffnen können. Für Eclipse gibt es ein Plugin (GNUARM Eclipse), welches die ARM-spezifischen Einstellungen in einigen wenigen Dialogen übersichtlich zusammenfasst. Was man dafür braucht, ist eine Eclipse-Installation mit C-Unterstützung sowie einen C-Compiler (arm-gcc). Das ganze ist auch nochmal im Yagarto-Projekt zusammengefast. Ich habe leider jetzt keine Zeit, das alles Schritt für Schritt zu erklären, das sollte mal jemand von Euch ausprobieren. Außerdem liegt momentan kein ARM7-Design herum, sodass ich auch nichts testen kann. Meine letzten Erfolge hatte ich mit einem AT91SAM7S gefeiert, falls hier konkrete Fragen auftauchen, kann ich evtl. aushelfen.

Als JTAG-Programmer hatte ich zuletzt den USBProg benutzt, den kann man in Verbindung mit OpenOCD gut zum Flashen und mit einiger Geduld auch zum Debuggen verwenden.

Viele Grüße
Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
Roddot
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 146
Registriert: 19.06.2008, 13:53

Re: OffTopic: Neuentwicklung Firmware

Beitrag von Roddot »

thoralt hat geschrieben:Hallo,
Roddot hat geschrieben:Ich hoffe ich muss nicht alles auf 16Bit umbauen damit es reibungslos läuft. :)
Was genau willst Du eigentlich auf 16 Bit umbauen? Die AVRs sind 8 Bit, und die weiter oben angesprochenen ARM7 besitzen einen 32-Bit-Kern. Willst Du noch ein neues Fass aufmachen?
Selber was in Hardware aufbauen (spielen) wollte ich aber erst mit den XMegas die kommen mir logischer daher und scheinen keine "Aufgebohrten" Familienmitglieder zu haben bei denen dann alles doch wider anders ist. Die sind ja nun lieferbar und an 3,3V kommt man ohnehin nicht herum.
Nun, das wird sich nicht vermeiden lassen. Die XMega-Familie steht noch am Anfang. In den nächsten Jahren wird sie, falls sie am Markt erfolgreich ist, erweitert werden. Und auch hier werden mit Sicherheit Erweiterungen vorgenommen, welche nicht mit dem "Ur-XMega" kompatibel sind. So war es immer und so wird es immer sein - kein Grund, sich zu ärgern.
3,3V ist auch OK da zB die KFZ-Bordnetzspannung beim Startversuch soweit einbrechen kann das 5V schon zu hoch ist.
Du scheinst mir recht oft auf den KFZ-Anforderungen herumzureiten. Willst Du das c't-Lab im Auto betreiben? Das dürfte nicht das richtige Anwendungsfeld sein... Außerdem: Es ist der falsche Ansatz, zu sagen, ein 3,3-V-Design wäre besser, weil die KFZ-Bordspannung _möglicherweise_ unter 5 V sinken kann. Wenn hier eine Unempfindlichkeit gefordert ist, dann muss eben ein Schaltregler her. Andererseits - sogar Autoradios gehen aus, wenn man den Motor anlässt. Falls Du also nicht vorhast, Steuergeräte für Airbags oder Einspritzanlagen zu entwickeln, dann baue einen Überspannungsschutz ein und verlasse Dich auf die Betriebsspannung. Ansonsten kriegst Du und die Leute um Dich herum nur unnötig graue Haare.
Mein Text war auf die C-Firmware bezogen und Lennart hat das offenbar auch so verstanden, ich gehe mal davon aus das psclab38 das auch richtig verstanden hat.
Ich habe (noch) die 12 Bit Schaltung.
Mit 8/16/32 Bit des µP hat das nichts zu tun.

Ich denke das 8Bit (Xmegas) absolut ausreichen für meine geplanten Basteleien.
Der Registerbereich der neuen Xmegas scheint auch noch für größere Typen zu reichen und die "Fuses" sehen deshalb auch aufgeräumter aus.

Ich beziehe mich gerne auf die praktischen Erfordernisse von KFZ-Anwendungen da diese anders als Labor- oder Schreibtisch Anwendungen einen praktischen Prüfstein darstellen an dem Bastler und Modellbauer einfach feststellen können ob das Design ihrer Schaltung zu den bessern gehört oder überarbeitet werden muss.
Wem schon mal ein Model abhanden kam weil zB die Zündkerze plötzlich im HF-Bereich störte weiß was ich meine.
Mit all den HF-Sendern die es Heutzutage an jeder Ecke gibt kann eine Überprüfung des Designs in diesem Sinne sicherlich generell nicht schaden.

Und natürlich habe ich den ATMega32 einer EDL neu programmieren müssen!

Momentan experimentiere ich mit einem einfachen Narbendynamo da geht erstaunlicherweise auch was. (70+ Volt Impulse bis Khz)
Let's fets with Static-DC. :-)
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: OffTopic: Neuentwicklung Firmware

Beitrag von psclab38 »

Roddot hat geschrieben:Mein Text war auf die C-Firmware bezogen und Lennart hat das offenbar auch so verstanden, ich gehe mal davon aus das psclab38 das auch richtig verstanden hat.
Na, ich hatte es noch gar nicht gelesen, erst jetzt. ;-) Du hattest Dich wohl auf die Hardwarebestückung bezogen und Du hast weder 16-bit DAC/ADC noch die Dual-DAC? Damit holperts halt ziemlich, wenn Du die Arbitrary-Funktion im ms-Bereich nutzen willst. Aber wenn's keine Dual-DAC-Version ist, dann ist es auch egal, wenn's nur 12 bit sind.

Wie gesagt, wenn Du gerne willst, daß auch mit 12 bit alles rund läuft, dann würde ich Dich bitten, mitzutesten. Ich kann nicht jede Hardwarevariante aufbauen und alle Optionen nach Pflichtenheft checken, ich bin da auf Eure Mitarbeit angewiesen. Wie auch schon letztens in einem anderen Thread erwähnt, habe ich bei der DCG2-C entdeckt, daß bei nur 12 bit die Ripple-Spannungen und Ströme NICHT getrennt gemessen werden (liegt vermutlich an mir, das hatte ich damals nicht aufgebohrt. NB ich wundere mich immer noch, ob bei der 12-bit-DCG auch mit 12bit gemessen wird, da wird eigentlich nur der ADC des ATmega verwendet und der hat 10 bit. Aber ich hab ja auch nicht behauptet, daß ich alles verstehe 8) )
Roddot hat geschrieben:Ich beziehe mich gerne auf die praktischen Erfordernisse von KFZ-Anwendungen da diese anders als Labor- oder Schreibtisch Anwendungen einen praktischen Prüfstein darstellen an dem Bastler und Modellbauer einfach feststellen können ob das Design ihrer Schaltung zu den bessern gehört oder überarbeitet werden muss.
Wem schon mal ein Model abhanden kam weil zB die Zündkerze plötzlich im HF-Bereich störte weiß was ich meine.
Mit all den HF-Sendern die es Heutzutage an jeder Ecke gibt kann eine Überprüfung des Designs in diesem Sinne sicherlich generell nicht schaden.
Es kommt -wie überall- auf die richtige Dimensionierung an. Qualität ist, wenn's den Anforderungen (mit Sicherheitsabstand) entspricht. Wenn's 10mal soviel aushält, dann hat's vermutlich auch mehr gekostet (Geld oder Schweiß). Dann waren entweder die Anforderungen falsch oder es war zu teuer für den Anwendungsfall. :wink: Insofern kann ich Thoralt nur zustimmen.

Viele Grüße
Paul
Roddot
kann c't-Lab-Module konstruieren
kann c't-Lab-Module konstruieren
Beiträge: 146
Registriert: 19.06.2008, 13:53

Re: OffTopic: Neuentwicklung Firmware

Beitrag von Roddot »

psclab38 hat geschrieben:Es kommt -wie überall- auf die richtige Dimensionierung an. Qualität ist, wenn's den Anforderungen (mit Sicherheitsabstand) entspricht. Wenn's 10mal soviel aushält, dann hat's vermutlich auch mehr gekostet (Geld oder Schweiß). Dann waren entweder die Anforderungen falsch oder es war zu teuer für den Anwendungsfall. :wink: Insofern kann ich Thoralt nur zustimmen.
Bei solchen Stückzahlen die ihr offensichtlich plant, wo es auch auf den "Pfennig" ankommt, ist das sicherlich verständlich das ihr strikt nach Pflichtenheft und dessen Anforderungen entwickelt.
Bastler wie ich achten meistens erst ab Größenordnung "Mark" auf den Preis, da stimme ich dann nicht zu.

Aber ich werde ein DCG auf 16 Bit (dual) ummodeln die 12Bit mache da ja nun keinen Sinn mehr.
Let's fets with Static-DC. :-)
Lennart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 32
Registriert: 11.12.2009, 05:42
Wohnort: Berlin
Kontaktdaten:

Re: OffTopic: Neuentwicklung Firmware

Beitrag von Lennart »

hmmm ... ich wollte eigendlich über die Firmwareentwicklung diskutieren und nicht über 16/12/8bit was auch immer Wandler oder welcher µC der bessere ist. Mir geht es ums Coden allgemein da es mein Haupthobby ist wenn ich das so nennen darf :)

Mein Posting hatte ich geschrieben als Anwort auf Pauls Frage...
Setzt Du bei Deiner Entwicklung auf einer C-Firmware auf oder hast Du ganz von vorne angefangen?
zu diesem Zeitpunkt gab es Roddot's Posting noch nicht
"When in trouble or in doubt, run in circles, scream and shout."
Aktuelle Projekte: DevilTrac, ArmLab
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: OffTopic: Neuentwicklung Firmware

Beitrag von psclab38 »

Roddot hat geschrieben:Bei solchen Stückzahlen die ihr offensichtlich plant, wo es auch auf den "Pfennig" ankommt, ist das sicherlich verständlich das ihr strikt nach Pflichtenheft und dessen Anforderungen entwickelt.
Bastler wie ich achten meistens erst ab Größenordnung "Mark" auf den Preis, da stimme ich dann nicht zu.
Deine Ansicht hat sicher ihre Berechtigung und ich möchte auch gar nicht dagagen reden. Worauf Thoralt und ich aber rauswollten ist, daß es für den Hobbybereich sicher in der einen oder anderen Hinsicht in Ordnung ist:

a) Einschränkungen in Kauf zu nehmen (abstürzende Modellflieger sind da natürlich nicht eingeschlossen) und
b) ab einem gewissen Punkt vielleicht auch mal 5 grade sein zu lassen, sobald man die geforderte / gewünschte Genauigkeit im Ergebnis erreicht hat.

In Kurzform: In solchen Fällen sagt man auf Bayrisch: "Des baßt scho!"

Das soll uns natürlich nicht davon abhalten, grundsätzliche Fragestellungen ausführlich zu diskutieren! 8)

In diesem Sinne
Paul

EDIT: @Lennart: sorry, kommt nicht mehr vor. :D
psclab38
kann c't-Lab-Konstrukteure konstruieren
kann c't-Lab-Konstrukteure konstruieren
Beiträge: 942
Registriert: 25.01.2008, 23:34

Re: OffTopic: Neuentwicklung Firmware

Beitrag von psclab38 »

Lennart hat geschrieben:Ich code gerade am Framework rum. Der Code ist zur hälfte abgekupfert und zur hälfte neu erfunden um meinen eigenen Ansprüchen zu genügen. Bisher fertig ist ...

- Startup-Code (Assembler)
- CStartup (Assembler/C)
- OnChip-Devices
...- SPI (noch ohne DMA mit ca. 20Mbyte/s)
...- Interupt-/Exception-Händler
...- PIT (benutzt als Systemtimer/-zähler mit 10ns auflösung)
...- UART's (noch ohne DMA)
...- StringLib (siprintf usw.)
- Ext-Devices
...- EA DOGM128 Grafik Display 128x64 (Diverse Fonts, Text-Routinen, Grafik-Routinen mit max. 550fps)

...wie man sieht nicht wirklich viel.
Wieso nicht viel? :?: So ein Framework dauert seine Zeit und wenn Du bislang keine Dummy-Anwendung als "Kern" drin hast, dann kann man ja noch nicht viel sehen.

Du bist ja schon auf dem richtigen Weg und aller Anfang ist schwer. Da geht unerwarteter Weise an Stellen Zeit drauf, die man gar nicht kennt. Wenn das Dein "Anfänger"-Projekt ist, dann: Hut ab! Ganz ehrlich!

Ich hab auch wiederholt z.B. mit dem WinAVR C-Compiler wegen PROGMEM (Daten im ROM/Flash) gekämpft, weil ich lange nicht kapiert habe, wie der tickt. Andere Compiler können das scheinbar transparent und hier hat's eine Weile gedauert zu erkennen, wo der Compilerentwickler die Lust verloren hat.
Lennart hat geschrieben:Allerdings hat das Einrichten von OpenOCD/Eclipse/Toolchain länger gedauert als erwartet. Und das debuggen innerhalb Eclipse funzelt auch noch nicht so wie es soll. Alles was das Makefile anbelangt war auch absolutes Neuland für mich.
Ab einem gewissen Punkt (als mir klar war, daß ich da mehr Code schreiben wollte) hab ich mir einfach den JTAGICE mk2 gekauft. Der hat mir richtig Zeit gespart und ich konnte mich auf die Sache konzentrieren. (Leider stürzt AVRStudio während dem Debugging recht gerne ab, das kann dann nerven. Es gibt aber Tage, da kommt kein einziger Absturz vor.) Zum reinen Programmieren verwende ich auch den USBprog.
Lennart hat geschrieben:Zum Zeitfaktor... das läßt sich bei mir auch nur schlecht abschätzen... ich sitze nun seit etwa 4 Wochen dran, allerdings immer nur so 2..3h pro Tag, vereinzelt auch länger. Ein blöder Fehler im Linkerscript hat etwa eine Woche gekostet.
Da Du Eclipse verwendest, schau' Dir vielleicht Thoralts Vorschläge näher an. Ich kenne die Umgebungen leider nicht. AVRstudio kann aber auch Syntax-Highlighting...

Viele Grüße
Paul
Lennart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 32
Registriert: 11.12.2009, 05:42
Wohnort: Berlin
Kontaktdaten:

Re: OffTopic: Neuentwicklung Firmware

Beitrag von Lennart »

psclab38 hat geschrieben:EDIT: @Lennart: sorry, kommt nicht mehr vor. :D
Hehe .. so wars nicht gemeint .. hatte nur das Gefühl das der Thread ein wenig vom Thema abgleitet :)
psclab38 hat geschrieben:Wieso nicht viel? :?: So ein Framework dauert seine Zeit und wenn Du bislang keine Dummy-Anwendung als "Kern" drin hast, dann kann man ja noch nicht viel sehen.

Du bist ja schon auf dem richtigen Weg und aller Anfang ist schwer. Da geht unerwarteter Weise an Stellen Zeit drauf, die man gar nicht kennt. Wenn das Dein "Anfänger"-Projekt ist, dann: Hut ab! Ganz ehrlich!
Danke, ich hab halt nicht damit gerechnet, das die Hürden bei der Toolchain so hoch sind. Allerdings macht es Spaß wenn man wieder eine bezwungen hat. (War ich glücklich als das Makefile und das Linkerscript funktionierten wie ich es mir vorgestellt habe)
psclab38 hat geschrieben:Ich hab auch wiederholt z.B. mit dem WinAVR C-Compiler wegen PROGMEM (Daten im ROM/Flash) gekämpft, weil ich lange nicht kapiert habe, wie der tickt. Andere Compiler können das scheinbar transparent und hier hat's eine Weile gedauert zu erkennen, wo der Compilerentwickler die Lust verloren hat.
Da in der Ecke war auch mein versteckter Fehler .. allerdings kann ich immer noch nicht ganz nachvollziehen warum der Code gesponnen hat .. najo .. ich werds schon noch rausfinden :)
psclab38 hat geschrieben:Ab einem gewissen Punkt (als mir klar war, daß ich da mehr Code schreiben wollte) hab ich mir einfach den JTAGICE mk2 gekauft. Der hat mir richtig Zeit gespart und ich konnte mich auf die Sache konzentrieren. (Leider stürzt AVRStudio während dem Debugging recht gerne ab, das kann dann nerven. Es gibt aber Tage, da kommt kein einziger Absturz vor.) Zum reinen Programmieren verwende ich auch den USBprog.
Ich benutze sowohl zum Flashen als auch zum Debuggen diesen OpenOCD USB Adapter als JTAG interface. Funzelt super. Hat allerdings nen weile gedauert bis OpenOCD (die Software ... 2* der gleiche Name aber andere Funktion) richtig konfiguriert war. Aber seit dem funzelts einwandfrei.
psclab38 hat geschrieben:Da Du Eclipse verwendest, schau' Dir vielleicht Thoralts Vorschläge näher an. Ich kenne die Umgebungen leider nicht. AVRstudio kann aber auch Syntax-Highlighting...
Ist lustig ... ich benutze bereits die YAGARTO Toolchain ... allerdings ist offensichtlich das GNUARM PlugIn für Eclipse nicht kompatiebel mit meiner Version (Last Stable mit allen Updates - CDT 6.0.2 Galileo) aber auch da bleib ich dran ... wobei so ein reines Make-Projekt den Vorteil hat das wirklich jeder die Sourcen selbst ohne größere Probleme selbst übersetzen kann.
"When in trouble or in doubt, run in circles, scream and shout."
Aktuelle Projekte: DevilTrac, ArmLab
Lennart
kann c't-Lab-Bausätze löten
kann c't-Lab-Bausätze löten
Beiträge: 32
Registriert: 11.12.2009, 05:42
Wohnort: Berlin
Kontaktdaten:

Re: OffTopic: Neuentwicklung Firmware

Beitrag von Lennart »

PS: @thoralt

ich hoffe du bist mir nicht bös das ich dein Forum ein wenig für mein ARM-Projekt mißbrauche .. ich denke mir halt das ich das gleiche ziel vor habe mit meiner (Basis-)Plattform, nähmlich Labor-Module für ein abgewandeltes c't-Lab mit ähnlichen Schnittstellen usw.

wenn ich es lassen soll, einfach bescheid geben ;)
"When in trouble or in doubt, run in circles, scream and shout."
Aktuelle Projekte: DevilTrac, ArmLab
Benutzeravatar
thoralt
Site Admin
Site Admin
Beiträge: 262
Registriert: 10.04.2006, 08:48
Wohnort: Chemnitz
Kontaktdaten:

Re: OffTopic: Neuentwicklung Firmware

Beitrag von thoralt »

Hallo Lennart,
Lennart hat geschrieben:ich hoffe du bist mir nicht bös das ich dein Forum ein wenig für mein ARM-Projekt mißbrauche ..
Ach was, ich habe nix dagegen. Solange ihr Jungs programmiert und lötet, ist alles in Ordnung :)

Thoralt
There are 10 kinds of people in this world: Those who understand binary and those who don't.
joedawson
kann c't-Lab-Bausätze bestellen
kann c't-Lab-Bausätze bestellen
Beiträge: 24
Registriert: 25.11.2009, 13:38

Re: OffTopic: Neuentwicklung Firmware

Beitrag von joedawson »

Howdy!

Bei mir steht in mittelferner Zukunft auch irgendwannmal was anverwandtes bevor, nämlich ein ct-lab-Modul mit ARM drauf. Blöderweise bin ich ARM-mässig stark vorbestraft (beruflich) - deswegen steht bei mir zumindest die Controllerseite schon ziemlich fest: einer aus der LM3S-Serie, mittlerweile von Texas, früher Luminary Micro. Das is dann ein Cortex-M3, also quasi leistungsmässig etwa (wirklich so ganz grob übern Daumen) ein ARM7, aber halt auf Embedded getrimmt. Die Teile und auch passende dev-Kits sind wirklich zu sehr humanen Preisen zu haben, kann ich jedem nur ans Herz legen.
Muss auch gestehen, auf so Makefilegebastel und Kriege mit selbstzusammengestellten IDEs hab ich mittlerweile keine Lust mehr, es gibt genug bezahlbare Alternativen die die Zeit einer sinnvolleren Verwendung zuführen können.

Aber wie meine Vorredner schon sagten - für einen Erstversuch ist das Geschaffte sehr ordentlich in Bezug zum Zeitraum. Ich kann mich an genügend Tage erinnern, an denen mal 5 oder 6 Stunden draufgegangen sind für die Suche nach einem falschen Bit in irgendeinem Konfig-Register.

Lange Rede, kurzer Sinn: ich veruch hier regelmässig reinzuschauen und wenns Fragen zu ARMs gibt, kann ich glaub ich auch manchmal weiter helfen.

In diesem Sinne,
joe
Antworten