Hi Leute, da ich in meiner Ausbildung (Informatik-Assi) so langsam (in einem halben Jahr?) zu den Mikrocontrollern komme, will ich ein bißchen Vorarbeit leisten. Die Schulausrüstung schaut alt aus... *hüstel*Drecksklump*hust* Das Folgende wird etwas ausführlicher (Roman), deshalb fix die Kurzfassung: Ich will ne ARM-basierte uC-Entwicklerlösung fürs Rumbasteln (Level: Neuling, blutig) mit Ziel Horizonterweiterung und Ausbildungs-begleitendes Lernen. Zu diesem Behufe würd ich gerne ein paar Meinungen hören... ----Start Roman---- Das warum und wieso sowie die Kombinationen, die ich mir angeschaut und als interessant befunden habe, folgen: Aus genereller Affinität zum Befehlssatz würde ich ein ARM-Board bevorzugen (hab vor Ewigkeiten mal schon in Richtung GBA-dev tendiert und mir damals für $sündhaft_teuer das ARM ARM gekauft). In C/C++ bin ich recht komfortabel unterwegs, und wegen gelegentlichem Linux-Gefrickel komm ich mit Eclipse und GCC ganz gut zurecht. Beim Assembler weiß ich ungefähr, an welchem Ende ich ihn anfassen muss. Elektrik/Elektronik ist für mich eher dünnes Eis, aber dank Training komm ich gut mit Lötkolben und Basis-schaltungen zurecht... Fehler sind (nicht nur) hier aber sicher vorprogrammiert. ... ansonsten ist meine Erfahrung mit uC auf das Spielen von und mit Mobilkonsolen (GP32, GBA, DS), Tragen von Armbanduhren etc beschränkt: nix, zip, Nada. Soviel zur Person (als Hilfe zum Einschätzen). Meine Wunsch-konfiguration wäre entweder * ein Amontec JTAGkey-Tiny (ab 4.Okt) von http://www.amontec.com/jtagkey-tiny.shtml als JTAG-Anbindung und zum Flashen Weil: Parallelport 'unten' am PC, am Arbeitsplatz liegt ein kleiner aktiver USB-Hub -> weitaus weniger Stress/mehr Platz/weniger Bücken/schnellere Übertragung/zukunftsicherer. * oder eine der Parallelport-Lösungen als JTAG-Adapter (billiger, langsamer, aber schon länger auf dem Markt -> bessere Unterstützung) btw: hier tendiere ich eindeutig zur USB-Version. Auch wenn sie erst später rauskommt und die Leistungsfähigkeit unbekannt ist... Selberbauen bleibt jetzt mal aussen vor, wenn dann was ned klappt weiss ich noch nichtmal ob ich nen IC auf dem JTAG-Adapter oder der uC-Platine gegrillt habe... oder sonstwas. Machbar wärs natürlich aber schon. ...egal. Zum Rest: * ein LPC2103 o.ä. auf Headerboard, weil billig und ggf schnell neu beschafft (Olimex? zB http://www.olimex.com/dev/lpc-h2103.html ) Nachteil: Beschaltung müßt ich selber hinbasteln, nervig, aber machbar. Natürlich dadurch irgendwie Motivationsbremse und steilere Lernkurve. Vorteil: Billig, flexibler gehts nimmer. * eines der 'mittleren' Olimex-boards wie zB LPC-MT-2106 ( http://www.olimex.com/dev/lpc-mt.html ) oder sogar - wenn ich meinen Ferienjob mal ausnahmsweise nicht über ein halbes Jahr verteilt in Burger und Kino umsetze - eines der 'großen' Boards, zB ein everything-and-the-kitchen-sink SAM7-EX256 Entwicklerbrettchen ( http://www.olimex.com/dev/sam7-ex256.html ) Problem: Einmal Mist gebaut -> 80-1xx Lewonzen über den Jordan - und evtl schlecht auf spätere Erweiterungen anzupassen (auch wenn eigentlich alles da dran ist, was ich jemals dranhängen wollen würde). Vorteil: ALLES dran und drin und überhaupt. Mit Codebeispielen und wahrscheinlich ziemlich schnellem Erfolgserlebnis... * ein Kuriosum am Rande: Die kastrierte halbgare eierlegende Wollmilchsau sozusagen. Leider kein JTAG, und als (relativer) Anfänger bin ich mir nicht sicher, ob das so eine gute Idee ist... die Rede ist von http://www.embeddedartists.com/products/boards/lpc2104_pro002.php - 35 Euro, plus Shipping&Handling und 25% Tax (autsch - die armen Schweden). Trotzdem, Bluetooth, Graphikdisplay, ... und sonst kaum was. Nichtmal Header zum Experimentieren. Dennoch, wenn JTAG nicht wichtig wäre... klingt interessant. Plus, ich werde kaum der Versuchung erliegen, irgendeinen selbergeschraubten Frankenstein dranzubauen, bevor ich nicht schon einiges mehr an Erfahrung unter dem Gürtel habe... -------Ende Roman------ Also? Wäre das 'Spiele'brett is billich und JTAG wäre damit gezwungenermassen auch unnötig. Per USB wird sowohl Proggen als auch Stromversorgung geregelt... allerdings wäre das ungefähr wie Schwimmen lernen in der nächstbesten Pfütze... oder? Preislich gleichzusetzen wäre wohl die 'mittlere Lösung'... Zukunftssicherer wäre sie allemal. Die kleine und große Option würde ich nur bei wirklich guten Argumenten in Betracht ziehen. Egal, das Maul zerreißen könnt ich mir noch ewig. Allerdings hab ich keine Ahnung von der Materie. Deshalb würde ich mich über Kommentare sehr freuen. Haut rein. Wenn ihr jetzt überhaupt noch mitlest und Lust habt. :)
Was willst du denn bauen? Wenn man ein interessantes Projekt vor Augen hat, fällt es leichter Anforderungen zu definieren und dann ins kalte Wasser zu springen. Ohne konkretes Projekt würde ich mir ein µC-Board holen, das schon von mehreren anderen benutzt wird und für das es die essentiellen Anpassungen der Entwicklungstools gibt. Da geben die Beispielsourcen von WINARM einen guten Einblick. Was in den Foren diskutiert wird, würde ich mir auch mal ansehen. Ein cooles Forum ist dieses Unterforum von Mikrocontroller.Net: http://en.mikrocontroller.net sowie http://www.sparkfun.com/cgi-bin/phpbb/viewforum.php?f=11
Nur noch eines: der Kostenrahmen. Mit Herzbluten würde ich 250 Euro veranschlagen, 150 Euro und drunter wären mir echt lieber. Unter extremen Umständen kann ich bis zum Doppelten (300-500) gehen, aber das muß dann schon ein göttliches Geschenk an die Menschheit sein. Sammelbestellungen stände ich ggf auch aufgeschlossen gegenüber - läuft zZt irgendwas dementsprechendes? Hab mal die Marktsparte hier durchflogen, scheint ned so zu sein, aber evtl hab ich ja was übersehen. PS.: Grade noch bei digilent vorbeigestolpert... ein AVR-Board für 60, und ein Spartan3-Starterboard für 100, zusammen ~160 US$... arrrrgh. das ist mit S&H und EuSt sicher auch locker noch ~170 Euro... Danke, starker Euro. :) Langsam weiß ich echt nimmer wohin mit dem Geld, AVR is mir zwar ned so recht, aber... FPGA is so ne Sache, die ich mir auch schon immer mal angucken wollte. seufz Wenn meine Probleme nur immer so angenehmer Natur wären. ^^; Was sagen die Profis hier? FPGA's dürften jetzt (mit meinem Wissensstand als Halblaie) noch etwas übertrieben sein, oder? ^^; Naja, egal. Zeit fürs Bett, sonst kauf ich noch irgendwas Unüberlegtes. Grüße aus dem Weißwurstäquator.
Soviel zum Thema Schlaf. ;) Danke, Stefan, werd ich mir mal anschaun. Hm, konkretes Projekt als Ziel... eh. Je nachdem, was mir die Leutz am Anfang für Hardware zutrauen würden. Basteln halt. Habe ich ein Display, nutze ich es. Bluetooth? Prima. Nix dergleichen? LEDs dranbappen, KITT-mäßig blinken lassen. Fernbedienungen nachbauen. Billigtaschenrechner versuchen. Miniroboter basteln, der ner Linie folgt. Und dabei Kitt-mäßig leuchtet und faucht. Eieruhr, die ein winziges WAV abspielt. Irgendwo hab ich erst kürzlich ne RFID-Antenne und -beschaltung gesehen -> Scanner. Mir fallen jetzt nur ziemlich hochlevelige Sachen ein... Ich bräucht halt eine gute Allroundlösung, etwas, das sehr bastelfreudig ist. * Logger. Ich bin tagsüber lang weg, interessiere mich generell, ob: mein Hund gebellt hat (wann? wie oft?) die Klingel/das Telefon läutete (wann? wie oft?) evtl Temperatur/Helligkeitsverlauf an mehreren Orten (PC, Zimmer 1-n, ...) Lautstärke generell? Ausgabe evtl über Laufschrift: Uhrzeit, Temperatur. etc (ne Menge Ideen) Speichern auf CF (ATA) oder SD/MMC Ein Mikro und ein ADC mit genug Samples/s (die meisten uC ham ja eh mindestens einen) sollten fast schon ausreichen - vielleicht sogar für kleinere Soundschnipsel? Wenn ja, dann geht da noch verdammt viel mehr.... * Manager-port eines alten Routers / einer Telefonanlage abgreifen und ggf das dort ausgegebene CLI auf Display als Text ausgeben oder andernfalls auf bestimmte events reagieren / 'Text eingeben'. * Auslesen PS2-Tastatur/Maus, Ausgabe über R2R-Netzwerk oder DA-Wandler auf VGA-Monitor ... sollte gehen? Vielleicht? Später erweitern? * Ich hab noch ein paar olle ISA-Netzwerkkarten (10 MBit, RTL8019AS) - evtl läßt sich damit was machen? zB ein stark eingeschränkter BootP/DHCP/etc-Server? MAC-Sniffer? Statistiken anlegen über Netzauslastung/Anzahl Pakete je Protokoll? Muss ja gottseidank kein voller TCP/IP-stack werden, einfach nur Musterabgleich. TCP-Ports auslesen und mitloggen? Ethereal für die Hosentasche wirds nie werden (Hilfe!), aber ein paar interessante Fakten müssten sich sammeln lassen. * Ein CD-Laufwerk anschließen und schauen, wie weit man mit den MMC-Befehlen kommt. Elektor hatte da mal eine Art Durchsagesystem , evtl kann man da noch viel mehr draus machen... *An den Seriellport eines Handys anschließen und mal gucken, was sich da so zerlegen lässt... vollautomatische Einbruchs/wasauchimmermeldung per SMS ans eigene Handy über ein prepaidhandy klingt lustig. Ich weiß, das gibts alles schon, aber hey, es geht mir ums Lernen. :) Später mal (absolut illusorisch): *Auslesen von Memcards gängiger oder alter Spielekonsolen zum Zwecke des Kopierens, Manipulierens - oder einfach nur so. * Lautsprecher mit Ethernet-Anschluß (Icecast/etc-client). DHCP, TCP/IP, der ganze Dreck. Eine **** Menge Arbeit. Kommerziell sauteuer. Selber machen FTW. * PC-unabhängiges Löschen einer pATA-Festplatte. Ein Datenkiller zwengs ebayverkauf von alten Platten oder vor Ausleihen an Freunde... evtl sogar noch mit Formatierungsroutine (FAT32/EXT2?) in einem schnuckelig kleinen Gehäuse. Oder, wenn Löschen, warum nicht sektorweise eine Platte auf eine andere kopieren? Bei 60MHz und >100GB dürfte das dauern, aber mei... * Automatischer CD/DVD-Brenner. Ein Stapel Rohlinge auf ne Ablage, ein Batchjob auf dem PC läuft an, fünf Stunden später kann man die Backups säuberlich verstauen. Ginge m.E. auch ohne uC per Parallelport, ... meh. X-D * cheapo-USB-Stick zwengs Flash ausschlachten, eigenen USBstick basteln (GPG-verschlüsselt, Füllstandsanzeige, Schreib/Leseschutz...)? Alternativ nehm ich das Spieleboard und progge die zweimilliardste Version von Pong, das über ein Bluetoothdongle am PC Internetfähig wird? Schulterzuck ^^;
Du hast also eine Karte vom Himalaya vor dir, aber noch keinen Berg ausgesucht. Bevor du jetzt losgehst und die Seile und Kletterhaken kaufst... Beschaffe dir ein paar gute Schuhe und erklimme den nächsten Berg in deiner Umgebung. Welchen nächsten "Berg" haben die in der Schule im Angebot? Es ist vielleicht schlau den gleichen µC zu benutzen bzw. ein befehlskompatiblen Nachfolger. LEDs blinken lassen geht mit einem kleinen AVR. Einen RFID Reader kannst du mit viel einfacheren Mitteln bauen (auch AVR beim Elektor -Reader). Bei deinen "Bergen" einen ARM einzusetzen, ist irgendwie ähnlich wie sich mit voller Ausrüstung eine Schlackenhalde hochzuseilen ;-)
@Lorenz "... allerdings wäre das ungefähr wie Schwimmen lernen in der nächstbesten Pfütze... oder?" Mir kommt das eher vor, wie Schwimmen lernen mit Sprung ausm Düsenjet in den Ozean bei Windstärke 10. Ich weiß ja nicht, wie groß Dein Vermögen ist, Mißerfolge einzustecken, ehe ein "Hello World" (aufm MC ist das ne Blink-LED) endlich läuft. Zum Lernen würde ich daher besser nen 8-Bitter (z.B. ATmega8) im DIP auf ne Rasterkarte pinnen und los gehts. Kostet unter 20,- und schneller Erfolg ist garantiert. Außerdem gewinnst Du dann endlich mal richtige Erfahrungem wieviel Ressourcen für die allermeisten Aufgaben wirklich nötig sind, ohne immer gleich mit Giga-FLOPs und -Bytes auf Eieruhren, Fahrradcomputer usw. zu schießen. Peter
Alles-in-einem-Antwort-und-Kommentar, ein weiterer epischer Roman, sorry. Hm, also ich hätte jetzt eher gedacht, daß ich Autofahren lerne mit einem 50t-Bulldozer mit 50 cm dicker Panzerung, anstatt mich kopfüber auf die Vespa zu hocken und auf der Autobahn in Gegenrichtung zu fahren. Ich meine, wenn ich mit dem $dickerer_uC gegen die Wand fahre, also etwas hoffnungslos ineffektiv gestalte, so kann ich dennoch mein Ziel erreichen, später wiederkommen, besser werden. Später kann ich sogar die Panzerung abmontieren (internen PLL auf 1, 5MHz-Quartz dranbappen) und mir so anschauen, wie es sich als Vespa fährt. Nen AVR kann ich nicht eben mal schnell nehmen und bei 60 MHz eine grafische Benutzeroberfläche mit 3D-Effekten auf ein super schlierenfreies 3310-display schmeißen - einfach, weil er dazu nicht gedacht ist und nicht so hoch getaktet wird. Andererseits steht es mir jederzeit frei, mittels Thumbmode auf meinem schwer untertakteten ARM über die mangelnden Bitschubser-Fähigkeiten eines ARMs zu lästern. Intel-Netburst-style: Taktrate draufschmeißen, und jedes Problem läßt sich mit nem überfahrenen Eichhörnchen lösen. Wenn ich zB die Peripherie 1:1 auf 50-60 MHz takten kann (bin mir nicht sicher, ob das die Billig-LPCs schaffen, aber irgendwo hier auf den Foren hab ich gelesen, daß es bei mindestens einem LPC geht), kann ich ein Vielfaches an Daten abgreifen - zum Beispiel, um nen Bus abzuhorchen (zB als Datenlogger) oder in Gegenrichtung, um Daten in kurzen Bursts weiterzuschaufeln. Geht mit FPGAs besser, sofern ich das verstehe, aber hey, es is ne zusätzliche Möglichkeit. Denkfehler? Wenn ja, bitte sagen. ----- Bis dahin, sorry für den Sturkopf, aber... ... sehe ich das richtig, die kleinste Lösung (LPC2* im DIP-Gewand) klingt besser? Bis jetzt hör ich bloß berechtigterweise 'Lass das'... Versteh ich, aber es beantwortet meine ursprüngliche Frage nicht. :) Das Problem bei der Sache ist halt: Ich hab bei der Hardwareseite einen wahnsinnigen Schiß, was kaputtzumachen, und wenns nur eine 5-cent-LED ist. Ich hab das nötige Handwerkzeug (in der Theorie), aber an Haudraufmentalität fehlt es mir. Ich kann einfach nicht auf einem Breadboard so ohne weiteres was zusammenstecken und anschließen. Da wird erstmal 5 Minuten Krise geschoben, ob auch alles so passt... bei jedem Baustein. Hardwaremäßig fehlt es mir einfach zu sehr an Erfahrung. Wir bauen im Unterricht eine 4-Bit CPU als diskrete Schaltung in EWB und werden später an 8051'ern rumschrauben. Bei unserem Tempo und der Qualität unserer Ausrüstung werden wir nicht Berge erklimmen, sondern höchstwahrscheinlich unbeweglich drauf warten, bis Afrika per Kontinentaldrift die Erde unter uns genug angehoben hat, damit wir auf einem Berg stehen. Vielleicht kommt ja auch ein freundlicher Gletscher vorbei und beschleunigt den Prozess. Nichts gegen meine Ausbildung, aber wir lernen das notwendige Grundmaterial, den Rest muß sich jeder selber besorgen. Ein ARM wäre mein Traumteil, weil das Mistvieh mich schon seit Jahren von der Seite her anmacht - das ARM ARM habe ich zeitenweise schon fast mit religiösem Eifer gelesen. Ist >6 Jahre her, aber irgendwas MUSS hängengeblieben sein. Nein, nicht der Hirnschaden, der war schon davor da. ;) Angefangen hats mit x86-Assembly, weil Borland's TurboPascal unter DOS grade auf den alten Pentiums und grafiktechnisch (Mode 13h+) nie schnell genug und hardwarenah genug sein konnte. x86 per a86 (?) wurde mir dann aber zu gefährlich (Arbeitsmaschine) und ehrlich gesagt ist mir die ISA zu... eklig/klobig. ARM klang damals wunderbar simpel und elegant, und so fand dann das ARM ARM den Weg zu mir. Wie gesagt, interessierter Laie war ich schon seit eh und je. Softwaremäßig stehe ich auf weitaus sichereren Beinen. Ich bin mir darüber im Klaren, daß ich für den Bruchteil eines ARM-Boards mit MSP430'ern oder AVR's etc rumbasteln könnte - will ich eigentlich aber nicht so wirklich. Sicher, <Mantra>Bitschubsen geht mit AVR&Co schneller, einfacher und ist dort je nach Aufgabe auch sinnvoller</>, aber ich will das nur ggf in der Anfangsphase machen, später über ein BS oder gar was selbstgebackenes 'höhere' Aufgaben erledigen. In der Schule werde ich weiß Gott genug LED's zum Blinken bringen dürfen (AFAICS Ampelschaltung, mir grauts jetzt schon davor :D). Deshalb will ich daheim dann das 'Kontrastprogramm'. Nun ja, und eine Blink-LED läuft doch folgendermaßen ab: Programm, das Pin am uC toggelt. Widerstand. LED. Masse. ->Elektrisch sogar für mich machbar (wenn man den uC nicht per Lötkolben grillt oder falsch dimensionierte Bauteile benutzt (blaue superhelle LED, direkt zwischen Pin und Masse? wäre das so ein Fall?)). Wenn ebengenannte Prozedur (Schleife & delay, oder per RTC getriggert) halbwegs einfach zu schreiben ist, trau ich mir das zu. Softwareseitig fühle ich mich relativ sicher, perfekt wirds nie sein, aber was sind das sein? 30 Zeilen ARM-assembly? Drei bis sechs Tage? In den Codebeispielen für die LPC-Reihe hängt oben ein chip-spezifischer Header drin, das wars. Damit komm ich zurecht. Zumindest trau ich mir das zu. Hochmut, Fall, etc. Hardwareseitig schauts da schon gaaaanz anders aus. zitter Ich versuche mich seit meiner Kindheit an dem Zeuch, und weiß heute grad mal, wo an nem Widerstand der Pluspol liegt und warum die Schweine in die Wand eingemauert wurden. ;) ----- Arrrh, wieder vom Hundertsten ins Tausendste. Was ich sagen wollte: Ja, bin mir bewußt, dass ARM einer der schlimmstmöglichen Einstiegsvektoren ist. Nein, ich brauche keine {T|G|M}Hz-Monster mit megabyteweise Speicher (dann gleich ein VIA EPIA). Ich will etwas näher an höhere Leistungsbereiche kommen, um mir genug Reserven zu lassen, falls ich sie mal brauchen sollte, um ein Hartdwareproblem in Software zu lösen - aber im Grunde genommen will ich mit nem 9V-Block und einer Handvoll Bausteinen was sinnvolles machen können. Wenn mich die Lust verläßt, sollte ich zumindest soweit kommen, mir den angepassten uIP-stack zu besorgen, ne Netzwerk'karte' anzuflanschen, irgendwo ne GPL MP3-Dekodiersoft zu klauen und mittels Umrühren und Jungfrau-Opfern den Netzwerklautsprecher zu realisieren. Vielleicht kommts auch ganz anders, ich finde endlich einen Weg in die Welt der Elektrik/Elektronik, und zwei Jahre später gehen meine E-Hosen mit dem Hund spazieren, während sich die Zeitung mir vorliest. Oder ich entwickele schulbedingt eine panische Angst vor Ampeln und muss zu den netten Männern mit den weißen Turnschuhen und der Habmichliebjacke. Sh*t happens. Bis jetzt höre ich zweimal berechtigterweise "Du bist wahnsinnig" und einmal ein unfreiwilliges Plädoyer für die Billiglösung. Und das AVR-Robotikboard von Digilent schaut etwas besser aus als gestern (allerdings, 128 _M_B RAM sind etwas unrealistisch ;) ). Verdammter Sturkopf.
Die eierlegende Wollmilchsau also. Das ist eine komplett andere
Philosophie als meine ("Steck nur soviel Hardware für ein Projekt, wie
unbedingt nötig"). Mir würde es schon widerstreben, dass ich Projekt n
schlachten muss, um meine wertvolle Sau für Projekt n+1 zu recyclen.
"Ich hab bei der Hardwareseite einen wahnsinnigen Schiß, was kaputtzumachen" Naja eben. ARM7 gegen AVR ist nämlich nicht Panzer gegen Vespa. Eher Airbus gegen Piper. Anfangen tut man mit letzterem. Auch weil's damit billiger kommt, wenn man mal den falschen Knopf erwischt ;-). Beim ARMs reicht es aus, die PLL falsch zu programmieren, und du darfst einen TQFP-Chip aus- und einen neuen einlöten. Worst-Case bei AVRs ist, wenn du den üblichen Ponyprog-Anfängerfehler mit den Fuses machst. Dann ziehst du einen 3 Euro Chip aus der Fassung (nicht weil er hinüber wäre, sondern weil du zugesperrt und den Schlüssel weggeworfen hast).
Lade Dir bitte das STR71x microcontroller reference manual runter: http://mcu.st.com/mcu/modules.php?name=mcu&file=familiesdocs&FAM=86 http://mcu.st.com/mcu/download2.php?file=10352.pdf&info=STR7%20Reference%20Manual%20STR71x&url=http://www.st.com/stonline/books/pdf/docs/10352.pdf Dann lies Dir schnell die bischen 35 Seiten über den Interruptcontroller durch und programmiere eben mal 17 Interruptprioritäten, die sich unterbrechen können und funktionieren ohne irgendwo in nem Fehlerzustand (spurious Interrupt, Exception) hängen zu bleiben oder sich gegenseitig die Prozesse zu zerschießen. Danach glaube ich Dir, daß Du mit nem ARM anfangen solltest. Die meisten hier haben klein angefangen und fanden es trotzdem alles andere als popeleinfach. Daher denken sie, daß es auch für andere sinnvoll ist auch klein anzufangen. Bezüglich Ampelsteuerung, sowas kann man doch prima mit nem Scheduler machen. Das hat dann den Vorteil, daß es sehr flexibel und schnell änderbar ist. Muß also durchaus kein Kinderkram sein. Man kann in C wunderschön nahe an der Hardware programmieren, wenn man sie erstmal verstanden hat. Insbesondere ist man ohne ein behäbiges OS hautnah an den Interrupts dran. Ich liebe Interrupts. Peter P.S.: Ich glaube auch nicht, daß Du aufm MC so eben mal irgendwo hergesaugte USB-, MP3-Legosteinchen zusammenknipsen kannst und es läuft. Meine Erfahrung ist, solange man die Programme nicht versteht, laufen sie auch nicht.
Vielen Dank für die vielen Antworten. Ich glaube, so langsam sehe ich einige Fallstricke und Probleme, die mir nie eingefallen wären oder die ich einfach als vermeintlichen Kleinkram ignoriert hätte. Gottseidank hab ich hier nochmal gepostet, bevor ich was gemacht hab... *@Stefan*: Joa, Du hast bereits eine Menge Erfahrung, und weißt wahrscheinlich jetzt bereits mehr als ich am Ende meiner Ausbildung. Du kannst Dir den Luxus leisten, möglichst 'kleine' Hardware zu benutzen - wenn ich jetzt bald anfange, hab ich vergleichsweise von Tuten und Blasen keine Ahnung. Wenn Du merkst, daß Deine Schaltung zu langsam reagiert, fiddelst Du im Interrupt-Controller rum, schreibst schwer optimierte Routinen und hängst extern vielleicht noch ein Gatter oder sonstwas dran. Meinereiner kratzt sich an einer nicht näher zu nennenden Stelle, versucht ein paar Tage am Quellcode zu werkeln, weint ein bißchen, und geht Leute im MC.net-Forum nerven. Ich werde also erstmal heilfroh über den Overkill sein ... denke ich. Bezüglich Recycling von Schaltungen: Hm, ist wahr, aber wieviele Projekte hast z.B. Du jetzt gerade simultan am Laufen? Wird das wirklich so, dass ich uC im Dutzend horten muß, vor allem jetzt am Anfang, wenn die Projekte eher in Richtung LED-Blinker gehen werden? Ist vielleicht etwas blauäugig, aber, ich hoffe/denke, wenn ich eine funktionierende Schaltung aufgebaut habe und unbedingt behalten will, was hindert mich daran, ein Headerboard mit entsprechender Hardware zu verlöten? Ein großes Entwicklerbrett mit frei herumbaumelndem Breadboard und/oder fliegender Schaltung und/oder Lochstreifenplatine wird aus Platzgründen und zwengs der Sicherheit eh nie viel hermachen. Ich muss dann nämlich nur dann eine Schaltung entwerfen, wenn ich sie auch wirklich gebrauchen werde. Andererseits geht mir damit natürlich eine Menge Übung durch die Lappen... Hmmm... Mal überlegen. Danke für den Denkanstoß. *@A.K.*: Ich denke mal, mit PLL rumzudoktern lass ich eh, bis ich a bissl Ahnung habe. Solang ich aber den Takt in Ruhe lasse und brav bin beim Flashen, sollte hardwaremäßig doch alles in Ordnung sein - oder? Wenn ich mir ein vorbestücktes Brett nehme, komm ich in der kritischen Phase am Anfang eher weniger in Bedrängnis, etwas dranzulöten, also fällt diese Gefahr für den uC auch weg. Aber Du hast recht, wenn dann mal was passiert, bin ich ge*****. (Ich sage nicht 'falls'...) @Peter Dannegger: Ja, is klar, aber ich werde auch nicht mit einem solchen Monster an Komplexität arbeiten. http://www.standardics.nxp.com/products/lpc2000/all/~LPC2104/#LPC2104 Die Liste (6.5.1) ist schon weitaus übersichtlicher. Ein Watchdog, Software-IRQ, 2 Timer, 2 UARTs, PWM, I2C, SPI, PLL, RTC, und die drei externen Interrupts, das macht 14 Quellen, die über ein Wort im Interruptcontroller identifizierbar sind (die DEBUG-Geschichten lassen wir mal weg). 2 Prio's in Hardware, unterscheidbar per FIQ/IRQ-Eingang, Handler-Adressen in den ersten schlagmichtot Bytes des Adressraums. Ich weiß ja nicht, wieviele Interrupts ich handhaben muß (einer der Gründe, warum ich diesen thread losgetreten habe, ist eben mein fehlendes Wissen in diesem Bereich), aber für LED-Blinken und so Zeuch am Anfang reichen doch sicher <=6 Interrupts, und soweit komm ich noch. Einmal Timer oder RTC, den Software-Interrupt bedienen wir natürlich auch noch, der Watchdog will glücklich sein, plus 100% zur Sicherheit (bin ja schließlich unwissend auf dem Gebiet der uC's, wer weiß, was da noch so rumschwirrt - ich ned). Die Vektoren für alle anderen Interrupts zeigen auf einen Dummy, die entsprechenden Bits im Interruptcontroller werden gesetzt, damit sie ignoriert werden. Den Watchdog hängen wir an den FIQ, die RTC wird der zweithöchste (Software-exception is ja eh extra). Das heißt, an Adresse 8h sitzt die Addy meines Software-Fehler-handlers (Ziehe Alarm-Pin auf 1 oder sowas), der FIQ-Vektor (1Ch) zeigt auf den Watchdog-code (den ich zugegebenermassen noch angucken muss), davor, also auf 18h, sitzt ein pointer auf die Blink-routine (Zähl nen Zähler hoch und toggle ggf das Bit für Ausgang x). Initialisierung im Hauptprogramm löscht/setzt die Vektoren, schaltet alle nicht benötigten Interrupts ab, schaltet den Watchdog/Timer/RTC/whatever an und zieht erstmal alle Pins auf nen definierten Wert, wenn überhaupt nötig. Wenn ich mich von diesem Modell aus weiterentwickle, sind Erweiterungen doch machbar: die Blinkroutine wird ersetzt mit einer Prozedur, die die Adresse aus dem Interruptcontroller liest und entsprechend dorthin springt. Und somit bleibt mein einziges Problem die Ordnung der IRQ-Quellen in ein angemessenes Prioritätsgemisch. Da es da aber keine Kochbuchrezepte geben dürfte, wird das von Fall zu Fall neu entscheiden werden müssen. Erinnert mich alles sehr an TSR-Programmierung unter DOS. Ich würd mich an die VIC usage notes auf Seite 70 des Usermanuals halten... klingt machbar. Oder war das jetzt alles nur Schmarrn? mfG, Lorenz
Much ado about nothing. Ok, ich habe jetzt ein Einsehen. Da ich möglichst bald damit anfangen will und glaub ich hier keiner auch nur einmal was gutes über meine Idee bezüglich ARM als Erstlingsplattform gesagt hat, lass ich das 'Fliegen lernen per Airbus' bleiben und sattel ganz traditionell auf die Cessna um. seufz Wie langweilig. ;) Habe mir ein Headerboard mit nem ATMega128 bestellt, plus ISP-Kabel (PonyProg-kompatibel). Massig Leistung, mit 16 MHz und der Menge an Flash und RAM sollte ich gut leben können. Wenn also demnächst irgendwas in den Nachrichten kommt wie "Explosionen, Killerroboter und manisches Gelächter im Norden Münchens" ... ihr wißt von nix. In einer bis zwei Wochen sollte das Zeuch da sein, davor werd ich mich auf die FAQ/das Wiki werfen und schauen, was ich so schaffe. Sprich, in zwei Wochen und 15 Minuten werde ich hier wieder anzutreffen sein und Romane schreiben. *g,d&rvvf* Stefan, Peter, A.K.: Danke für das feedback und die freundlichen Ratschläge. :) ... ...und ich hätt trotzdem soooo gerne mit nem LPC angefangen... ;)
hi könnt ihr mir weiter helfen muss für die schule eine eieruhr programmieren und komme nicht mehr weiter. wäre echt cool.
Ist das ernst gemeint? Falls ja: Ich habe Probleme mit meinem System. Ist für die Arbeit. Kannst du mir da weiterhelfen? -> Im Ernst: Bitte immer möglichst viel Infos mitgeben. Die wenigsten Leute haben noch eine Glaskugel zu Hause. @Admin btw: Warum gibts eigentlich nicht, wie in manch anderen Forum, nen Thread (immer ganz oben), wo drinsteht, wie man zu posten hat? Auch wenn die Leute trotzdem leeres posten, könnte man sie auf diesen Aufklärungsthread verweisen, statt jedem einzeln zu fragen, was er denn für ein System hat, Programmiersprache usw...
Auch, wenn der Thread schon etwas angegraut ist: Ich hab im Studium mit 68332 Assembler angefangen, dann mit einem fertigen ARM Board weitergemacht und schließlich doch mein eigenes gebaut. Funktioniert auch. Jetzt fang ich dann mit dem Mega8 an. Warum? Weil ich mir nicht den 12 Euro teuren (was nicht das größte Problem wäre) und dank LQFP kaum austauschbaren ARM nicht schrotten will. Ein Mega8 kostet unter 2 Euro, passt schön in nen Sockel und ist doch etwas robuster.
Im Elektor gabs sowas vor vielen hundert Jahren, die hat gekräht, wenn die Zeit um war. Wie soll die Uhr aussehen, Einstellmöglichkeiten/Ausgabe ? Ist irgendeine Hardware/Prozessor vorgegeben?
Beitrag #6768067 wurde von einem Moderator gelöscht.
Beitrag #6768077 wurde von einem Moderator gelöscht.
Beitrag #6768082 wurde von einem Moderator gelöscht.
Beitrag #6768083 wurde von einem Moderator gelöscht.
Beitrag #6768122 wurde von einem Moderator gelöscht.
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.