Wie aufwendig ist eigentlich ein Board mit einem embedded PC anstatt einem mittelmäßigem Microcontroller wie einem MSP430F149? Und wo gibt es denn Schaltpläne u. Layouts für embedded PCs zum Downloaden?
Embedded PC's sind leider ziemlich teuer. Schaltpläne zu finden wird nicht ganz leicht sein. Aber warum ist der F149 ein mittelmäßiger Controller? Mfg, R2D2
Mittelmäßig ist der MSP430F149, weil er nur 2 kB RAM und nur 60 kB Flash hat. Das Flash reicht uns für Ergometer jetzt schon nicht aus (weil für Bootloader kein Platz mehr vorhanden ist u. die deshalb nur im RAM laufen können) und für Speicherkarten wie MMC/SDC, auf die man nur in 512 Byte großen Blöcken (die an einer Adress n*512 beginnen müssen) Auslesen/Beschreiben kann, braucht man zum Lesen/Schreiben einen (bis zu) 512 Byte großen Buffer, also schon 1 kB RAM und damit mehr als die Hälfte - für ein Dateisystem ist da kein Platz.
Ich vermute mal, Du hast Deine 60kB Flash fast nur mit irgendwelchen Bildchen für das LCD verstopft. Lagere diese Bilddaten doch einfach in einen EEPROM aus und Du hast wieder reichlich Platz für echten Programmcode. Z.B. AT24C512 (64kByte) oder AT24C1024 (128kByte). Dürfte um Längen billiger sein als ein EPC und braucht nur 2 Pins zu Deinem MC. Oder nimm als MC einen ATMEGA128 (128kByte Flash). Peter
Also Probleme sind neben dem knappen Flash auch die schlechten Debugging-Möglichkeiten wie z. B. keine funktioniertende RS232-Kommunikation im Debuging-Modus und Seiteneffekte, die nur durch Compiler- oder IC-Fehler entstehen können. Da kommen auch 3 völlig unterschiedliche Programmierer dann nur mit trial & error weiter mit workarounds wie warteschleifen / Speedups (wie memcpy) an Stellen, wo keine Hardware-Zugriffe erfolgen. Und bei einer 2000 EUR-IDE gibt´s schon beim Linken Probleme wie dass zwar eine flashfähige Version erstellt wird, der Debuger die aber nicht akzeptiert. Mit PCs gibt´s solche Probleme nicht und wenn es Probleme gibt, sind auch Sachen wie Kernel debuging viel leichter. Deshalb will ich erstmal recherchieren wo es Schalt-Pläne dazu gibt u. wie teuer denn die Komponenten sind.
Schau mal hier: http://www.dilnetpc.com/ Die haben einen embedded 486er im DIL 64 Format! Hat für einen PC nur etwas wenig RAM und Flash und nur eine Serielle Schnittstelle. Ich selbst benutzte nen richtigen PC104 PC mit National GX1 200MHz, 128MB-RAM, CF Sockel mit 256MB Flash Karte etc. (eBay: 160 Euro)aber falls ihr ne Serienproduktion plant ist dass vermutlich zu teuer da man den dann ja für ~500 Euro pro Stück vom Händler kaufen müsste... MfG, Dominik S. Herwald http://www.dsh-elektronik.de/
Aha, danke. Ich denke an sowas wie einen 486er im 64 Format, damit weiterhin eine Leiterplatte ausreicht. Wie teuer ist denn so ein 486er bei Stückzahlen von einigen 1000 Stück?
Tja da kann ich dir auch nicht helfen - da musste mal bei SSV Anfragen aber billig wirds bestimmt nicht. Ich glaube aber einzeln kosten die so um die 150 bis 250 Euro... Oder meintest du die Prozessoren? Dass sind AMD Elan SC410 - aber da ich sowas für gewöhnlich nicht selbst baue kann ich dich da auch nur an die Distributoren verweisen. MfG, DSH
Hallo zusammen, der Dil/NET-PC 486/33 kostet einzeln 175 ! Mit eval-Board 259 beim Hersteller... Wenn man mich fragt keine gute Alternative. ´ Allerdings, gibt es z.B. eCos (Linux) als OS, welches auf fast jedem gängigen Prozessor läuft, vieleicht da mal schauen (sources.redhat.com) MfG Christian
@Rolf Ist ja schade, daß Du mit Deiner Entwicklungsumgebung so schlechte Erfahrungen gemacht hast. Aber ob man deshalb gleich mit Kanonen auf Spatzen schießen muß ? Immerhin sind PC-CPUs nicht als Stromsparer bekannt, d.h. auch in Sachen Netzteil-Power mußt Du dann noch erheblich zulegen und natürlich auch die Wärmeabfuhr nicht vergessen. Zum Thema Debuggen: Man muß immer dran denken, alle Debugger sind Krücken !!! D.h. irgendwie gibt es immer Seiteneffekte durch die beschlagnahmten Ressourcen und zeitlichen Verschiebungen, wenn z.B. die CPU zur Ausgabe von Registern angehalten werden muß. Da kannst Du bei PCs kein Änderung erwarten. Höchstens, daß diese Seiteneffekte durch die massive Rechenpower etwas geringer sind. Die besten Debugergebnisse hat man daher, wenn man selber kleine Ausgaberoutinen schreibt, die dann Informationen z.B. über die UART ausgeben. Dann sind Dir nämlich die beschlagnahmten Ressourcen bekannt und man kann sie an den Stellen einfügen, wo es günstig ist. Deshalb nehme ich jetzt gerne MCs mit Bootloader, wo man superschnell neu compilieren und downloaden kann. Wenn man in C programmiert, kann man die meisten Routinen auch schon auf dem PC z.B. unter Borland-C testen. D.h. echtes Debuggen auf dem Ziel-MC ist dann nur noch für die Routinen mit Hardwarezugriffen nötig. Irgendwo staubt bei mir auch ein Emulator und ein JTAG-ICE vor sich hin. Der Emulator sieht richtig edel aus, ein PLCC-Sockeladapter mit einem dicken verdrillten Flachbandkabel zu einer großen Box. Aber ich brauche nur einen Blick auf das superdicke Handbuch zu werfen und schon stell ich das Ding ganz schnell wieder in die Ecke. Will damit sagen, auch Emulieren / Debuggen mit einem großen Profitool will erstmal gelernt sein und nicht immer ist an unerwarteten Reaktionen ein Bug in dessen Hardware / Software schuld. Peter
Danke für die Antworten. Also ich habe über ein Jahrzehnt hauptsächlich am PC programmiert, aber die anderen 2 Programmierer haben schon früher mehrere Jahre lang verschiedene Microcontroller programmiert und die sehen es so wie ich. Es ist ziemlich frustierend überhaupt nicht nachvollziehbare Fehler zu finden wie if (i<8) Ausgabe(y); // Ausgabe-Funktion über LCD-Display am MC mit den Ausgaben 0, 8, 16 ... und dann zu sehen, dass bei (i>8) überhaupt nichts ausgegeben wird (d. h. auch 16 wird nicht ausgegeben), obwohl nur aus einem lokalen Puffer ausgelesen wird! Beim PC habe ich sowas noch nie gehabt! Eigentlich müsste man embedded PCs doch mit Bestücken einer Leiterplatte billig herstellen können. Mal hören, was Lieferanten wie Spörle empfehlen.
if (i<8) Ausgabe(y); // Ausgabe-Funktion über LCD-Display am MC Ja warum sollte dass auch funktionieren? Da soll y doch nur ausgegeben werden wenn es kleiner als 8 ist? Müsste ja dann eher so lauten: if(y<8) Ausgabe(y); Sonst wäre die Ausgabe ja von i und nicht von y abhängig und i kann ja vorher irgendeinen anderen Wert annehmen oder konstant sein... Und falls du dich nur vertippt hast - dann scheint der Compiler da buggy zu sein. Da würd ich mir mal testweise nen anderen ansehen. Im Vergleich zum PC sind viele µC Familien ja noch relativ jung. D.h. die Tools für den PC sind natürlich viel ausgereifter. Wenn man allerdings einen µC nimmt, der auch schon so ca. 5-10 Jahre erfolgreich im Markt vertreten ist, dann müsste es auf ähnlich gutem Niveau wie der PC sein. MfG, DSH
Ähm, da hab´ ich mich vertippt; ich meinte natürlich i statt y. Ich habe mir diesen Compiler-Bug zusammen mit einem Kollegen gestern angesehen. Und weil solche Bugs bei zwei mit einander kommunizierenden embedded Systemen auftreten ist es ziemlich aufwending, weil deren Kommunikation nicht funktioniert, wenn schon bei nur einem ein Debuger aktiv ist! Der Compiler ist IAR Embedded Workbench 1.26 Vollversion, also mit Dongle usw.. Den gibt es seit einigen Jahren und der kostet(e) um 2000 EUR. Zudem wird der vom MC-Hersteller TI empfohlen und auch auf dessen Konferenzen verwendet. Zu den Compiler-Bugs kommen noch Linker-Bugs, durch die man zwar Progromme ohne Fehler/Warnungen erstellen u. flashen kann, aber der Debuger schon das Starten verweigert, weil der überlappende Segmente meldet, die es aber auch nach dem Mapping-File nicht gibt und bei denen der bezahlte "Support" nur empfiehlt verschiedene Sachen auzuprobieren. Die neuere Version 2.1 ist bei dem jetztigen Projekt auch keine Alternative, weil die Portierungen dahin viel aufwendiger sind als die nach MSPGCC und sicherlich sind die Linker- u. Compiler-Bugs weiterhin drin. Zudem haben wir nun auch keine Zeit dafür.
" if (i<8) Ausgabe(y); // Ausgabe-Funktion über LCD-Display am MC mit den Ausgaben 0, 8, 16 ... und dann zu sehen, dass bei (i>8) überhaupt nichts ausgegeben wird (d. h. auch 16 wird nicht ausgegeben), obwohl nur aus einem lokalen Puffer ausgelesen wird! " Das bei 16 nichts ausgegeben wird, ist doch vollkommen richtig. 16 ist doch nicht <8 ! Das statt 0..7 die Ausgabe 0, 8, 16 ... erfolgt kann vielleicht an der Verwendung von Macros liegen. C erlaubt da ja ne Menge Schweinereien. Auch Typumwandlungen können manchmal unerklärliche Werte verursachen. Ich benutze den Keil C51 Compiler und hatte da auch schon einige unerklärliche Dinge. Aber die waren bisher immer auf meine Programmierkunst zurückzuführen. Und eben besonders Macros können da die verrücktesten Sachen machen. Um Zweifel auszuräumen lasse ich auch solche erstmal unerklärlich reagierenden Routinen unter Borland.C laufen, ob sie sich da genau so verhalten und das tun sie eigentlich immer. Der Keil ist da ziemlich gut ANSI-C compatibel. Und wenns ganz schlimm kommt sehe ich mir den erzeugten Assembler an, da merkt man dann schnell, was sich der Compiler gedacht hat. Aber richtige Bugs habe ich noch nicht bemerkt. Auch ist die Keil Webseite exzellent in Bezug auf Support und auch der Erläuterung der speziellen MC-spezifischen Erweiterungen, z.B. die Verwendung von Pointern in den unterschiedlichen Memory-Bereichen. "der bezahlte "Support" nur empfiehlt verschiedene Sachen auzuprobieren." Da kann ich absolut nicht klagen. Die Hilfe war immer sehr fundiert. Ich hab auch schonmal von Herrn Keil persönlich meine Fragen beantwortet bekommen. Peter
Ich wollte Dich natürlich nicht zum 8051 bekehren, sondern nur verdeutlichen, daß man nicht alle Microcontroller-Programmiertools pauschal verdammen kann. Es gibt eben auch sehr gute. Vielleicht kannst Du ja Dein Bug-Beispiel mal etwas präziser hinschreiben (Typ der Variablen, Funktionen, Macros, Headerfiles usw.). Irgendwie deutet ja Dein Posting "...16 wird nicht ausgegeben..." darauf hin, daß Du doch was völlig anderes willst, als Du hingeschrieben hast. Ich versuche jedenfalls immer zu ergründen, worin der Fehler liegt. Wenn es nämlich ein Syntaxproblem ist, dann fällst Du immer wieder darauf herein, völlig unabhängig vom Tool. Peter
Also der Bug tritt z. B. so auf: for (i=0;i<8;i++) Ausgabe(i); Und er tritt NICHT auf nach loop unrolling: Ausgabe(0); Ausgabe(1); Ausgabe(2); Ausgabe(3); Ausgabe(4); Ausgabe(5); Ausgabe(6); Ausgabe(7); Am Montag werden wir mal nachforschen ob es ein Stack overflow sein könnte, aber das zu überprüfen ist eigentlich Aufgabe des Compilers! Nur der kennt weder Bitfelder noch Strukturen von Strukturen!
Hallo Rolf! Arbeite auch mit MSP430F149 und Proge mit meiner SDT-Programmierumgebung in Verbindung mit MSPGCC. Ich hatte noch nie irgend welche Probleme (es sei denn der Programmierer hat wo was versteckt). Wie auch andere schon sagten, Debugging-Sachen progt man sich selber. Es ist zwar schön, dass es Software gibt, wo man die Register und Speicherplätze auslesen kann, aber irgendwie hab ich mir bis jetzt nichts anzufangen gewusst. Ich mach immer eine RS232 Verbindung oder so, oder wenn ein Display dabei ist, lass ich es dort wo anzeigen. Und bei Hardwaresachen muss ein Oszi herhalten. mfg Weichinger Klaus http://www.Weinga-Unity.de.vu
Embedded PC gibts für relativ kleines Geld bei ics-d.de Habe Erfahrung mit dem Gene4312 und dem 5335 (PC/104) gesammelt. Das 5335 besitzt in meiner AUsstattung 128MB RAM und eine 256MB Flash-Disk. Als "Gui" benutze ich eine LCD-Display, eine Folientastatur und ein RFID Modul. Ein Atmel 8515 dient dabei als "Wrapper". er schickt mir die Benutzereingaben per RS232 zum PC. Ausgaben landen im Display. Als OS läuft ein Debian mit Apache, php, ftp, ssh und mysql als Datenbank. Das ganze ist dann noch in einem kleinen Wandgehäuse gestopft. Geballte Ladung Rechnenleistung im Miniformat! Probleme gab es nur mit der Abwärme der CPU und dem DCDC Wandler. mfg UK
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.