www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Anfänger-Set (ARM)


Autor: Lorenz Jugel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/lpc... -
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. :)

Autor: Stefan (Gast)
Datum:

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

Autor: Lorenz Jugel (Gast)
Datum:

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

Autor: Lorenz Jugel (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

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

Autor: Lorenz Jugel (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

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

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
s/für/in/g

;-)

Autor: A.K. (Gast)
Datum:

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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lade Dir bitte das STR71x microcontroller reference manual runter:

http://mcu.st.com/mcu/modules.php?name=mcu&file=fa...

http://mcu.st.com/mcu/download2.php?file=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.

Autor: Lorenz Jugel (Gast)
Datum:

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

Autor: Lorenz Jugel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
s/TSR/Interrupt/g

Hust Hirn is noch ned ganz da, sorry.

Autor: Lorenz Jugel (Gast)
Datum:

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

Autor: ducsmooth (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hi könnt ihr mir weiter helfen muss für die schule eine eieruhr 
programmieren und komme nicht mehr weiter.

wäre echt cool.

Autor: Henrik J. (henrikj)
Datum:

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

Autor: Frank Gnurapton (pancho)
Datum:

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

Autor: Christoph Kessler (db1uq) (Gast)
Datum:

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

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.