Mikroprozessor-Programmierung: Womit fang ich an?

[Dirk Ruth]

Rafael Delianoschrieb:
"
[...]

Es wird bei Controllern viel zu sehr übersehen, daß
die Hauptkosten für die meisten Anwender in der Software
liegen. Und dass lausige Testmöglichkeiten nichtnur die
Entwicklungszeit sondern auch die Qualität der Software
ungünstig beeinflussen.

Genau so. Das hab ich hier auch schon des öfteren so gesagt, will aber
keiner hören. Deshalb empfehle ich auch den M16C (Glyn-Board 50,- EUR,
20K RAM, 256K Flash, kostenloser Compiler, Debugger usw.).

Es macht keinen Sinn, am Anfang den kleinsten und billigsten Prozessor
zu kaufen (und billig sind die PICs wirklich nicht), vielmehr sollte
man den Größten kaufen, weil da genügend Pins und integrierte Hardware
zum kennen lernen, sowie üppig RAM und Flash vorhanden ist. Auf
kleinst möglichen Code und spezielle Tricks und Verrenkungen kann man
gerade in der Anfangsfase wirklich gern verzichten.

Dirk

 

[Rafael Deliano]

Da Du die ja recht engagiert "bewirbst"
Ich bin da bekennender Anwender und habe

gute Gründe warum. Es sind halt nicht die
Sorte Gründe "alle Welt verwendet PIC
oder AVR". Es bliebe allerdings anzumerken,
daß es kein Hobbby-Controller ist. Beschaffung
z.B. kann mühsam sein wenn man nicht
Verpackungseinheiten beim Distributor anstrebt.
Abgesehen von den Samples die wohl recht wahllos
direkt verschickt werden.

Wie sieht es denn da so mit Programmierhardware,
kostenloser Entwicklungsumgebung (Assembler, C
Compiler, Simulator) etc. aus?
Bietet heute jeder Hersteller.

Die Programmierung des FLASH erfolgt mittels simplem
Adapter vom PC aus über V24. Die Software von P&E
dafür ist frugal aber brauchbar, verwende ich selbst
vgl. FORTH-Handbücher. Software von P&E in
Vergangenheit ( 68HC05 ) war teilweise ungenießbar.
Da beim 68HC08 aber im Chip schon gute Voraussetzungen
geschaffen wurden jetzt besser. Wie gut kann
ich nicht sagen, da ich ja was anderes/besseres verwende.
C-Compiler: es gibt limitierte Versionen Codewarrior
von Motorola offiziell, in USA auch low-cost Alternative
Bytecraft. "High cost" Anbieter ohnehin, Motorola ist
immer noch Marktführer bei 8 Bit und automotive
Halbleitern.
Technisch wird man mit C allerdings aus Gründen der
Architektur mit AVR wohl besser unterstützt. Umgekehrt
wird natürlich AVR da gegen lowcost 16 Bit wie MSP430
Federn lassen. Wer C will und nicht auf Kosten schauen
muß liegt bei Motorola/Freescale mit HC12 besser.
Juckt mich aber nicht, da FORTH nicht so anspruchsvoll
ist.

MfG JRD

 

[Olaf Kaluza]

Dirk Ruth <d.ruth@itecnet.de> wrote:

Genau so. Das hab ich hier auch schon des öfteren so gesagt, will aber
keiner hören. Deshalb empfehle ich auch den M16C (Glyn-Board 50,- EUR,
20K RAM, 256K Flash, kostenloser Compiler, Debugger usw.).

So wie ich das sehe ist der Compiler nur kostenlos solange du mit 64kb
zufrieden bist. Obwohl ich natuerlich zugeben muss das dies fuer die
allermeisten Dinge keine wirkliche Grenze ist.
Die mitgelieferte Grafikoberflaeche ist aber ziemlich bescheiden, aber
das kann man zum Glueck mit Makefile und Emacs umgehen.

Sehr armselig/nervig ist aber das Programm zum flashen.

Es macht keinen Sinn, am Anfang den kleinsten und billigsten Prozessor
zu kaufen (und billig sind die PICs wirklich nicht), vielmehr sollte
man den Größten kaufen, weil da genügend Pins und integrierte Hardware
zum kennen lernen, sowie üppig RAM und Flash vorhanden ist. Auf
kleinst möglichen Code und spezielle Tricks und Verrenkungen kann man
gerade in der Anfangsfase wirklich gern verzichten.

Da kann ich dir aber zustimmen. Wobei es aber gerade fuer einen
Anfaenger nicht unbedingt ein SMD Gehaeuse sein muss.

Olaf

 

[Michael Lange]

Hallo Sebastian,

(sorry, für Lustig, bei deinem Beitrag konnte ich nicht anders, aber
unten kommt noch richtige Info, versprochen.)

Da ich gerne mit LEDs spiele und mir auch schon die eine oder andere
Beleuchtung mit LEDs gebaut habe, würde ich nun gerne wissen wie ich
die LEDs blinken

Strom an-aus-an-aus... ;-)

oder gar animieren lassen kann.

im Rotlichtviertel? ;-)

Meines (halb-)Wissens nach lässt sich sowas mit Mikroprozessoren
realisieren.

Sowas lässt sich mit vielem realisieren.

Aber da fängts dann auch schon an, denn von der Materie
hab ich 0 Ahnung.

Naja, aber es ist ja nicht ganz hoffnungslos mit dir. Lesen/Schreiben
kannst du, LEDs hattest du auch schon in der Hand, und Batterien auch,
(Beleuchtung mit LED gebaut). ;-)

Lässt sich das wirklich mit ľP realisieren, oder is das ein irr-Glaube
von mir ;-).

Das wird aber nicht leicht mit dir ;-)

Falls doch, wie fange ich an Mikroprozessoren zu
programmieren,

Mit lesen ... im Ernst ... (der dse-FAQ - speziell F.7 und da vor allem
F.7.1 und F.7.2; und news://news.online.de:119/d60k4e$brl$1@online.de
zwecks ergänzender Links und Infos; Doku der Hersteller Atmel und
Microchip sonstiger Newsbeiträge; Web-Foren; Suchmaschinen uvam.). Auf
den empfohlenen Web-Seiten finden sich auch viele Programmbeispiele und
Schaltungen.
Bücher sind leider meist nicht sehr aktuell, bzw. auch nicht mehr zu
finden als im Web, es sei denn, du stehst mit Englisch auf Kriegsfuß ;-)

gibt es "Standard" Bücher, die empfehlenswert sind?
Welches Equipment benötigt man? und und und...

Für Buchempfehlungen, und hilfreiche Anfängertips, dankt im Voraus

Ob AVR oder PIC (was anderes würde ich dir allerdings erst mal nicht
raten, wenn du auf schnelle Hilfe im Web hoffst) ist, wie du sicher bald
bemerken wirst, für einige eine Glaubensfrage. Die Diskussion wird
oftmals recht unsachlich und mit sehr fragwürdigen Argumenten geführt.
Vorsicht vor Ratschlägen wie: A ist super, B ist Schrott (leicht
überspitzt ;-) ).
Jede der beiden Plattformen hat ihre Besonderheiten, ihre Vor- und
Nachteile. Viel wichtiger ist was dir gefällt, und wo du evtl.
Unterstützung im RL bekommst.

Ich kann mich auch nicht der pauschalen Empfehlung anschließen, ein
fertiges Kit zu kaufen, das hängt ganz von deinen Fähigkeiten und
Möglichkeiten ab. Willst du sowieso gleich was ganz konkretes bauen, und
hast schon Löterfahrung dann wohl eher nicht. Einen einfachen Programmer
kannst du dir für jede der beiden Plattformen schon für ca. 5 Euro
selber löten. Und die Software gibt's ... wieder im Web.
Wenn du dir ein Kit leihen kannst, wäre das natürlich eine Gelegenheit
erst mal zu prüfen, ob das das Richtige für dich ist.
Ob du dir besser gleich den "ganz großen" Chip kaufen sollst!? Naja, das
ist auch abhängig davon, was du machen willst. Zum Experimentieren ist
es vielleicht nicht schlecht, aber viele Features bergen auch mehr
Fehlermöglichkeiten. U.u. willst du ja vielleicht erst mal was gaaanz
einfaches machen (ein X-Kanal-LED-Lauflicht). Dazu braucht es nun nicht
gerade den Chip mit allen Super-Spezialfunktionen.

Letztendlich ist es deine eigene Entscheidung, was du machst. Eigentlich
sind alle norwendigen Informationen recht leicht zu finden und fertige
Rezepte kann man eh nicht geben. Höchstens: Viel Lesen, und mach dir
klar, was du willst.

Wenn du auf Basis der empfohlenen Info-Quellen konkretere Fragen hast,
bist du hier jeder Zeit willkommen.


Michael

 

[Dirk Ruth]

Olaf Kaluzaschrieb:
"

Dirk Ruth <d.ruth@itecnet.de> wrote:

Genau so. Das hab ich hier auch schon des öfteren so gesagt, will aber
keiner hören. Deshalb empfehle ich auch den M16C (Glyn-Board 50,- EUR,
20K RAM, 256K Flash, kostenloser Compiler, Debugger usw.).

So wie ich das sehe ist der Compiler nur kostenlos solange du mit 64kb
zufrieden bist. Obwohl ich natuerlich zugeben muss das dies fuer die
allermeisten Dinge keine wirkliche Grenze ist.
Die mitgelieferte Grafikoberflaeche ist aber ziemlich bescheiden, aber
das kann man zum Glueck mit Makefile und Emacs umgehen.

Naja die Serial gibt's wohl an jeder Ecke und ich glaube auch nicht,
dass es Renesas interessiert, wenn ein Anfänger damit was ausprobieren
will. Mir haben sie zumindest die serial kostenlos angeboten, da ich
ein gößeres Projekt mit dem M16C gemacht habe. M.W. sind oder waren
die Compiler in der Zeit begrenz (1/4 Jahr). Kann man sich sicher also
nochmal neu installieren.

Als Oberfläche kann man nehmen was man will (wie beim gcc). Ich
verwende hier Visual Slick Edit und Makefile sollte man sowieso immer
erstellen, damit man weiß, was passiert und welche
Compiler-Einstellungen verwendet werden.

Sehr armselig/nervig ist aber das Programm zum flashen.

Dafür gibt's den M16C-Flasher von www.mikrocontroller.com
Der macht seinen Job recht gut.

Richtig Spass macht es dann allerdings mit dem KD30 zu arbeiten.
Erinnert mich irgendwie an 68HC11 Zeiten und den Monitor. Für Anfänger
völlig ausreichend und ein tolles Tool, mit dem man gerade als
Anfänger eine Menge Fehler finden kann. Sowas bieten PIC und AVR und
wie sie alle heisen mögen nicht an. Da muss man wieder Hardware kaufen
um halbwegs vernünftig debuggen zu können.

Es macht keinen Sinn, am Anfang den kleinsten und billigsten Prozessor
zu kaufen (und billig sind die PICs wirklich nicht), vielmehr sollte
man den Größten kaufen, weil da genügend Pins und integrierte Hardware
zum kennen lernen, sowie üppig RAM und Flash vorhanden ist. Auf
kleinst möglichen Code und spezielle Tricks und Verrenkungen kann man
gerade in der Anfangsfase wirklich gern verzichten.

Da kann ich dir aber zustimmen. Wobei es aber gerade fuer einen
Anfaenger nicht unbedingt ein SMD Gehaeuse sein muss.

Als Anfänger muss man halt auch erstmal löten lernen und SMD ist auch
für Bastler heute Pflicht, wenn man über ein gewisses Maß hinauskommen
will. Elektronik ist nun mal nix für Grobmotoriker und DIP-100 ist mir
soweit nicht bekannt.

Dirk

 

[Olaf Kaluza]

Dirk Ruth <d.ruth@itecnet.de> wrote:

Naja die Serial gibt's wohl an jeder Ecke und ich glaube auch nicht,

Das muessen dann wohl Ecken sein an denen ich mich nicht rumtreibe.

Dafür gibt's den M16C-Flasher von www.mikrocontroller.com
Der macht seinen Job recht gut.

Ja, aber nicht fuer die R8C. Leider!

will. Elektronik ist nun mal nix für Grobmotoriker und DIP-100 ist mir
soweit nicht bekannt.

Soviele Beine braucht man meist garnicht. Ich vermisse viel oefter
mehr Luxus in kleinen Gehaeusen.
Ich hab mich heute mal ein bisschen mit der Gratisplatine aus dem
japanischen Elektronikheft (mit R8C/15) beschaeftigt.

Bis jetzt mit folgenden Erkenntnissen:

1. Es gibt keinen I2C/Bus. Ich weiss kann ich auch in Software
machen, aber in Hardware waere schoener.

2. Endlich wieder verschiedene IRQ-Prioritaeten. Das hat mich
an den AVRs immer genervt.

3. Ob ich nun einen 16Bit oder 8Bit Prozessor habe ist ziemlich
egal. 16kb Rom und 1kb Ram fuellt man sowieso nur mit dem
C-Compiler

4. Ich weiss ich koennte es messen, aber ich hab bis jetzt noch
kein Gefuehl dafuer bekommen ob die nun schneller oder langsamer
als ein AVR sind. Ich _schaetze_ sie sind meistens langsamer weil
ein Befehl mehr Zyklen braucht und gelegentlich schneller wenn man
mit groesseren Datentypen hantiert.

5. Die drei Timer scheinen mir mir etwas komisch und unaufgeraeumt zu
sein.

6. Man muss sich wohl entscheiden ob man RS232 oder SPI haben will.

7. Programmierung ueber RS232 mag von Vorteil sein wenn man Rechner
ohne RS232 hat da ein USB->RS232 Wandler funktioniert, aber
ansonsten ist es etwas nervig jedesmal einen Jumper umstecken zu
muessen.
Garnicht davon zu reden das man wohl jedesmal abstecken muss wenn
man die RS232 auch noch in seinen eigenen Anwendungen braucht.

8. Interessant ist auch das in dem japanischen Elektronikheft in neun
von 10 Artikeln mit Assembler gearbeitet wird und im zehnten zeigen
sie was der Compiler aus C fuer einen Assemblercode macht.
Ich glaub die halten nicht viel von C.

Olaf

 

[Georg Acher]

In article <2f7d7d.8m5.ln@criseis.ruhr.de>,
Olaf Kaluza <olaf@criseis.ruhr.de> writes:

|> 5. Die drei Timer scheinen mir mir etwas komisch und unaufgeraeumt zu
|> sein.

Nuja, die Timer-Doku zum Atmega8515 (nur so als Beispiel) ist eine der
schlimmsten und unverständlichsten, die mir jemals untergekommen ist. Und meine
Leidensfähigkeit ist gross...

|> 8. Interessant ist auch das in dem japanischen Elektronikheft in neun
|> von 10 Artikeln mit Assembler gearbeitet wird und im zehnten zeigen
|> sie was der Compiler aus C fuer einen Assemblercode macht.
|> Ich glaub die halten nicht viel von C.

Weil es wahrscheinlich keine Japan-Variante davon gibt.

Mir ist noch ein Gespräch mit einem von Pioneer in Erinnerung, für die ich mal
C-Code für einen Multimediabestandteil eines Auto-Navi geliefert habe:

Ich: Was ist da eigentlich für ein Prozessor drin?
Er: Das ist ein NEC§$%&
Ich: Was für ein Teil?
Er: Ach, das ist ein 32Bit-Industriestandard-uC in Japan...
Ich: Aha, und was für ein Betriebssystem läuft da drauf?
Er: §$%&/
Ich: Wie bitte?
Er: Das ist ein Industriestandard-Betriebssystem für eingebettete Systeme in
Japan...

Schon nach 5min wusste ich nicht mehr, wie das Zeug hiess ;-)

--
Georg Acher, acher@in.tum.de
http://wwwbode.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias

 

[Olaf Kaluza]

Georg Acher <acher@in.tum.de> wrote:

|> 8. Interessant ist auch das in dem japanischen Elektronikheft in neun
|> von 10 Artikeln mit Assembler gearbeitet wird und im zehnten zeigen
|> sie was der Compiler aus C fuer einen Assemblercode macht.
|> Ich glaub die halten nicht viel von C.

Weil es wahrscheinlich keine Japan-Variante davon gibt.

Da irrst du aber. Ich musste mir die Software extra aus dem Netz holen
weil auf der beigefuegten CD alles in japanisch ist, auch die Software!

Ich wuerde sogar vermuten das die R8C urspruenglich eine japanische
Entwicklung sind, jedenfalls habe ich beim lesen der englischen
Datenblaetter den Eindruck gehabt als wenn sie hier und da etwas
holprig uebersetzt sind.

Olaf

 

[Dirk Ruth]

Olaf Kaluzaschrieb:
"

Dirk Ruth <d.ruth@itecnet.de> wrote:

[...]
will. Elektronik ist nun mal nix für Grobmotoriker und DIP-100 ist mir
soweit nicht bekannt.

Soviele Beine braucht man meist garnicht. Ich vermisse viel oefter
mehr Luxus in kleinen Gehaeusen.

Das verträgt sich wohl irgendwie nicht.

Ich hab mich heute mal ein bisschen mit der Gratisplatine aus dem
japanischen Elektronikheft (mit R8C/15) beschaeftigt.

Bis jetzt mit folgenden Erkenntnissen:

1. Es gibt keinen I2C/Bus. Ich weiss kann ich auch in Software
machen, aber in Hardware waere schoener.

zu kleiner Controller

2. Endlich wieder verschiedene IRQ-Prioritaeten. Das hat mich
an den AVRs immer genervt.

ACK

3. Ob ich nun einen 16Bit oder 8Bit Prozessor habe ist ziemlich
egal. 16kb Rom und 1kb Ram fuellt man sowieso nur mit dem
C-Compiler

Mit Assm zu aufwendig - verliert man schnell die Übersicht, bzw.
braucht man vorher 1 Woche Ressourcenplanung, d.h. für Anfänger
ungeeignet.

4. Ich weiss ich koennte es messen, aber ich hab bis jetzt noch
kein Gefuehl dafuer bekommen ob die nun schneller oder langsamer
als ein AVR sind. Ich _schaetze_ sie sind meistens langsamer weil
ein Befehl mehr Zyklen braucht und gelegentlich schneller wenn man
mit groesseren Datentypen hantiert.

Bei M16C wird fast alles in einem Zyklus abgearbeitet. Mit den R8C/15
kenn ich mich jetzt nicht so aus (sind mir zu klein).

5. Die drei Timer scheinen mir mir etwas komisch und unaufgeraeumt zu
sein.

Man muss bei Renesas immer das kleingedruckte lesen.

6. Man muss sich wohl entscheiden ob man RS232 oder SPI haben will.

zu kleiner Controller

7. Programmierung ueber RS232 mag von Vorteil sein wenn man Rechner
ohne RS232 hat da ein USB->RS232 Wandler funktioniert, aber
ansonsten ist es etwas nervig jedesmal einen Jumper umstecken zu
muessen.
Garnicht davon zu reden das man wohl jedesmal abstecken muss wenn
man die RS232 auch noch in seinen eigenen Anwendungen braucht.

zu kleiner Controller

8. Interessant ist auch das in dem japanischen Elektronikheft in neun
von 10 Artikeln mit Assembler gearbeitet wird und im zehnten zeigen
sie was der Compiler aus C fuer einen Assemblercode macht.
Ich glaub die halten nicht viel von C.

???

Versuch mal, ob Du bei Glyn als Entwickler irgendwie eingetragen
werden kannst (Glyn-Board kaufen, Projekt beschreiben usw.), dann
bekommst Du z.B. den M30624FGAFP (256k Flash, 20K RAM) zum
Vorzugspreis von etwas über 10,- EUR netto.

Tschüss PIC, tschüss AVR.



Dirk

 

[Rafael Deliano]

SMD ist auch für Bastler heute Pflicht, wenn man über ein
gewisses Maß hinauskommen will.
Der 68HC908GP32 ist noch DIL40, aber wohl der letzte seiner Art.

Freescale hat bei vielen Typen allerdings SDIP, Problem jedoch
häufig Lieferfähigkeit.

Erinnert mich irgendwie an 68HC11 Zeiten und den Monitor.
Das eben tut ein FORTH im Zielsystem noch viel besser als ein

Monitor von ehedem.

MfG JRD

 

[Olaf Kaluza]

Dirk Ruth <d.ruth@itecnet.de> wrote:

1. Es gibt keinen I2C/Bus. Ich weiss kann ich auch in Software
machen, aber in Hardware waere schoener.

zu kleiner Controller

Naja, fuer umsonst.
Im ernst, der ist eigentlich nicht so klein, aber irgendwie haelt
Renesas den I2C wohl nicht fuer so wichtig.

2. Endlich wieder verschiedene IRQ-Prioritaeten. Das hat mich
an den AVRs immer genervt.


ACK

Das ist doch auch so ein Punkt. Wieso hat Atmel das nicht in die AVRs
eingebaut. So schwierig kann das doch nicht sein selbst die MCS51
konnten das doch schon. Muss wohl irgendwie mit den privaten Vorlieben
des jeweiligen Entwicklers zusammenhaengen.

Bei M16C wird fast alles in einem Zyklus abgearbeitet. Mit den R8C/15
kenn ich mich jetzt nicht so aus (sind mir zu klein).

Die R8C sollen eigentlich kompatibel zum M16C sein. Allerdings steht
im Datenblatt das von den 89 Befehlen genau 20 nur einen Zyklus
brauchen und 75% Prozent alle Befehle brauchen 5 oder weniger Zyklen.

Ist natuerlich schwer abzuschaetzen was dies fuer die Praxis bedeutet.

zu kleiner Controller

Du wiederholst dich.

Versuch mal, ob Du bei Glyn als Entwickler irgendwie eingetragen
werden kannst (Glyn-Board kaufen, Projekt beschreiben usw.), dann
bekommst Du z.B. den M30624FGAFP (256k Flash, 20K RAM) zum
Vorzugspreis von etwas über 10,- EUR netto.

Ach noe, bis jetzt das mit dem R8C nur Spass weil ich mal was anderes
sehen wollte. Ausserdem habe ich hier auch noch irgendwo einen M16C
rumliegen.
Aber bei dem naechsten groesseren Projekt fuer die Firma werd ich da
wohl mal ein verstaerktes Auge drauf werfen.

Olaf

 

[Dirk Ruth]

Rafael Delianoschrieb:
"

SMD ist auch für Bastler heute Pflicht, wenn man über ein
gewisses Maß hinauskommen will.
Der 68HC908GP32 ist noch DIL40, aber wohl der letzte seiner Art.
Freescale hat bei vielen Typen allerdings SDIP, Problem jedoch
häufig Lieferfähigkeit.

Kenn man von Freescale auch nicht anders. Es gibt auch noch von
STMicroelectronics vieles im SDIP mit Pinabstand 1,27mm. Ist aber auch
nicht so richtig für Lochrasterkarten geeignet. Dann doch gleich PLCC.

Erinnert mich irgendwie an 68HC11 Zeiten und den Monitor.
Das eben tut ein FORTH im Zielsystem noch viel besser als ein
Monitor von ehedem.

Gibt's da auch vsprintf, sscanf, _f4mul, _f4div, qsort usw.? Hab FORTH
das letzte mal von 15 Jahren probiert, weil's damals schneller war als
BASIC-Interpreter.

Dirk

 

[Rafael Deliano]

Es gibt auch noch von STMicroelectronics vieles im SDIP mit
Pinabstand 1,27mm.
Für Consumer existiert ein Markt für bedrahtete Bauelemente

auf FR3-Boards bestückt in Fernost. Ich habe Kunden dem
brauche ich nicht mit SMD kommen.

Ist aber auch nicht so richtig für Lochrasterkarten geeignet.
Erträglich: mit Laubsäge Schlitze sägen, mit

Pattex den SDIP-Sockel einkleben.
Pferdefuß ist später das Layout auf FR3 wegen des engen
Rasters und der kleinen Pads.

Dann doch gleich PLCC.
Gibts bei den 68HC08 praktisch nichtmehr: wer SMD

will muß QFP nehmen. Bei FLASH und serieller in-circuit
Programmierung ist das heute auch ok. Problem nur wenn
Chip >16kByte hat und die serielle Programmierung langsam
ist. Wenn man Chip mit viel Pins, viel Speicher
auf Programmiergerät hat kann man parallel laden und
damit Programmierzeit erträglich halten.

Gibt's da auch vsprintf, sscanf, _f4mul, _f4div, qsort usw.?
Was das sein soll weiss ich nicht, aber mit unleserlichen

Akronymen kann FORTH bestens dienen.
Eingabe, Ausgabe von Hex/Binär/Dezimalzahlen ( Oktal nichtmehr )
und Arithmetik sind natürlich vorhanden. Aber nur Festkomma.

MfG JRD

 

[Jan Stumpf]

Hi!

Wirklich schwer beeindruckt hat mich uebrigens der 20Mhz Quarz auf
diesem Demoboard. Der ist so gross wie ein kleiner SMD Widerstand,
enthaelt aber zusaetzlich noch die beiden Kondensatoren.

Vieleicht die von Murrata? Gibts z.B. bei Farnell!

http://www.murata.com/catalog/p16e15.pdf

Viele Grüße

Jast

 

[Dirk Ruth]

Rafael Delianoschrieb:
"

Es gibt auch noch von STMicroelectronics vieles im SDIP mit
Pinabstand 1,27mm.
Für Consumer existiert ein Markt für bedrahtete Bauelemente
auf FR3-Boards bestückt in Fernost. Ich habe Kunden dem
brauche ich nicht mit SMD kommen.

Die hab ich auch schon mit SMD Bestückung gesehen. Obenauf dann mit
schönen Drahtbrücken versehen.

Dann doch gleich PLCC.
Gibts bei den 68HC08 praktisch nichtmehr: wer SMD
will muß QFP nehmen. Bei FLASH und serieller in-circuit
Programmierung ist das heute auch ok. Problem nur wenn
Chip >16kByte hat und die serielle Programmierung langsam
ist. Wenn man Chip mit viel Pins, viel Speicher
auf Programmiergerät hat kann man parallel laden und
damit Programmierzeit erträglich halten.

Ist die Programmierzeit länger als bei OTP? Ist mir noch gar nicht
aufgefallen.

Gibt's da auch vsprintf,
http://www.resourcecode.de/view.php?id=696

sscanf,
http://www.maconlinux.net/php-online-manual/de/function.sscanf.html

_f4mul,
Fliesskomma Multiplikation

_f4div,
Fliesskomma Division

qsort usw.?
http://www.fz-juelich.de/zam/docs/bhb/bhb_html/d0140/chapter_15.html

Was das sein soll weiss ich nicht, aber mit unleserlichen
Akronymen kann FORTH bestens dienen.
Eingabe, Ausgabe von Hex/Binär/Dezimalzahlen ( Oktal nichtmehr )
und Arithmetik sind natürlich vorhanden. Aber nur Festkomma.

Sicher hast Du inzwischen auch Deine Macros zusammen, mit denen Du
Fliesskomma Berechnungen durchführst, oder Formatierungen vornimmst.
Da die o.g. Funktionen aber zum Sprachstandart gehören gehe ich davon
aus, dass sich da inzwischen eine Menge Leute Gedanken um die
Korrektheit und Optimierung gemacht haben

Dirk

 

[Robert Rottmerhusen]

Olaf Kaluza wrote:

Ich wuerde sogar vermuten das die R8C urspruenglich eine japanische
Entwicklung sind, jedenfalls habe ich beim lesen der englischen
Datenblaetter den Eindruck gehabt als wenn sie hier und da etwas
holprig uebersetzt sind.

Das ist mir auch schon beim M16C aufgefallen ;-/
Teilweise sehr schlecht zu verstehen.

Grüsse
Robert

 

[Sebastian Jäger]

Am Sun, 29 May 2005 17:15:32 +0200, schrieb Michael Lange
<leckmich@despammed.com>:

Mit lesen ... im Ernst ... (der dse-FAQ - speziell F.7 und da vor allem
F.7.1 und F.7.2; und news://news.online.de:119/d60k4e$brl$1@online.de
zwecks ergänzender Links und Infos; Doku der Hersteller Atmel und
Microchip sonstiger Newsbeiträge; Web-Foren; Suchmaschinen uvam.). Auf
den empfohlenen Web-Seiten finden sich auch viele Programmbeispiele und
Schaltungen.

Ich hab mir mal die Empfohlenen Links in den FAQ angesehen, unter
http://www.speedy-bl.com/atmel.htm#Testschaltung
hab ich ein auf den ersten Blick gut aussehendes Beispiel gefunden.
Leider war eine 70minütige Google Recherche nach weiteren derartigen
Beispielen (Schaltplan, ASM-Source, ein wenig Text) wenig erfolgreich.
Vielleicht hab ich auch einfach nur die falschen Suchworte benutzt :/

Kennt jemand weitere Quellen für solch "kleinere" Projekte?

Nochmals vielen Dank für die vielen informativen Replies!

mfg Sebastian

 

[Axel Schwenke]

=?ISO-8859-1?Q?Sebastian_J=E4ger?= <dod_lord@gmx.de> wrote:

Kennt jemand weitere Quellen für solch "kleinere" Projekte?

Weil es noch keiner genannt hat, hier

<http://www.rowalt.de/mc/index.htm>

gibts eine IMHO recht gelungene Einführung in die AVR-Reihe.


XL

 

[Rafael Deliano]

Gibt's da auch vsprintf, sscanf, _f4mul, _f4div, qsort usw.?
Fliesskomma Berechnungen durchführst, oder Formatierungen vornimmst.
Da die o.g. Funktionen aber zum Sprachstandart gehören ...
FORTH ist keine C-Variante. Der 68HC908GP32 ( 8 Bit CPU,

512 Byte, 32kByte FLASH ) ist kein geschrumpfter PC.
Aufwendige Ein/Ausgabeformatierung von Zahlen aufs Terminal
macht wenig Sinn, wenn die Applikation im Regelfall nur LEDs,
bestenfalls ein kleines LCD hat.
Float macht keinen Sinn wenn die CPU dafür zu langsam ist bzw.
bei 8 Bit Auflösung des A/D-Wandlers auch die Genauigkeits-
anforderungen nicht danach sind.
Ausgefeilter Sortieralgorithmus macht keinen Sinn wenn die
Tabelle maximal 256 Byte lang ist.
Wer lieber PC will wird mit dem System nicht glücklich.
Ist dann aber auf grosse Controller beschränkt.

MfG JRD

 

[Rolf Bombach]

Dieter Wiedmann wrote:

Zum Blinken eines LEDs tuts der PIC. Für viel mehr ist er
kaum zu empfehlen.

Da hast du dich aber weit aus dem Fenster gelehnt.

Ok, dann halt 2 LEDs.

--
mfg Rolf Bombach