Hi Leute,
ich will ein Microcontrollerboard mit den 16Bit-Controllern von Hitachi
bauen.
Die Vorteile von den Controllern sind folgende:
- frei verfügbarer GNU-Compiler(C und C++)
- 16 MByte adressierbarer Bereich
- die neuesten Varianten mit 25 Mhz
- beim H8/3069 sind 512kByte Flash und 16kByte RAM auf dem Chip
- eine gute Dokumentation der Controller
Das Board soll folgende Anschlußmöglichkeiten haben
- 3 serielle Schnittstellen
- LCD-Display
- Datenbus für IO-Erweiterungen
- Datenbus für externes RAM und Flash
- alle wichtigen Pins auf einen Stecker für eine "Bastelplatine"
Ziele:
- Das Board soll einen preiswerten Einstieg in die 16Bit-Controller
ermöglichen
- nicht wie andere EVBs nach der ersten Testphase in der Ecke liegen,
sondern
durch die Datenbusse und die "Bastelplatine" auch als Vorserienmodell
dienen können
- Programmierung von Microcontrollern in C++ ermöglichen
- Eine einfache Einfürung in den GNU-Compiler mit lauffähigen
Beispielen,
auch etwas umfangreicher als nur ein Blinklicht
Nun meine Fragen:
- Was darf so ein Board kosten?
- Was muß das Board sonst noch haben oder soll es erweiterbar sein?
- Wer hat überhaupt Interesse?
- Ist so etwas interessant für engagierte Hobbyelektroniker?
- Gibt es professionelle Entwickler mit Interesse?
- Sind noch andere der Ansicht, daß es Sinn macht, einen Microcontroller
in C++ zu programmieren?(Man muß es ja nicht übertreiben, aber etwas
objektorientiert
ist doch ganz sinnvoll.)
Bisherige Erfahrungen:
- den legendären 6502 in Assembler programmiert.
(Bei größeren Projekten sehr unübersichtlich und dann auch
unzuverlässig.)
- den 6502 in C programmiert.
(Mit einem nicht optimierenden Compiler keine große Freude,
dann auch noch die 64k Grenze.)
- Einstieg in die Hitachi-Controller, schon mal keine Speicherprobleme
mehr.
(Die Hitachi-EVBs sind allerdings nur bis zur ersten eigenen Platine
brauchbar und
liegen dann in der Ecke.)
- Mein zurzeit aktuelles Projekt hat ca. 90 Dateien und eine
Binärdateigröße
von ca. 800kByte. Es ist etwas aufgebläht durch Übersetzung der
Bedienungstexte
in 9 Sprachen.
- Der Compiler macht einen sehr ordentlichen Code. Ob ein guter
Assemblerprogrammierer noch etwas besser optimiert, wage ich zu
bezweifeln,
da die Optimierung über ein großes und weiterhin wachsendes Projekt
fortgeführt werden muß.
Dieter
hi,
wenn du projekte hast,die man mit 8-bittern nicht
verwirklichen kann,dann nur ran an den 16er.
was ich mit 8 bits nicht machen kann,das ueberlasse ich einem pc.der
kostet nicht viel mehr als eine komplette
Hitachi ausruestung.
ciao
ps 90% aller hobbyanwendungen machen mehr warteschleifen
als nutzarbeit.
Um welche 16bitter von Hitachi soll es sich denn konkret handeln?
Bzw. existieren die GNU C und C++ Compiler denn schon oder sind sie im
laufe des Projektes zu entwickeln?
Hi,
nur weil die Compiler frei erhältlich sind,
musst du dich ja nicht gleich
auf so eine "Krücke" von Hitachi stürzen.
Hast du dir mal die 16-Bit Microcontroller
von Infineon angeschaut. Ist nur ein Vorschlag.
MC's mit 8051-Gehirnen sind sehr beliebt und
daher ist die Unterstützung recht gross.
Ausserdem sind sie Industriestandard!
Standardanhang bei den Infineon-Datenblättern:
Supported by a Large Range of Development Tools like C-Compilers,
Macro-Assembler
Packages, Emulators, Evaluation Boards, HLL-Debuggers, Simulators, Logic
Analyzer
Disassemblers, Programming Boards
Ich halte überhaupt nichts davon, das Haus vom Dach aus aufzubauen.
D.h. zuerst überlege ich mir, welche Anwendungen ich überhaupt vorhabe.
Und erst dann suche ich den MC aus, der gut dazu passen könnte.
Gut passen heißt dann auch in Hinblick auf Preis, Verfügbarkeit,
Zuverlässigkeit, Support (von Hersteller oder Foren), persönliche
Erfahrungen und Fertigkeiten.
D.h. es muß nicht unbedingt ein Super-Super-MC sein, wo meine Anwendung
nur 1% des Flash belegt und nur 1% der CPU-Leistung verbraucht.
Ich habe bisher leider noch nicht die Killerapplikation gefunden, die
mich weg vom 8051 drängt, d.h. mehr Flash oder 16Bit benötigt.
Meine größtes Projekt ist nur 40kB groß und benötigt 8kB RAM, da habe
ich einen P89C668 genommen.
Lange parallele CPU-Datenbusse sind auch heutzutage in Hinblick auf
CE-Zertifizierung total Out.
Es gibt ja I2C, SPI und Konsorten, womit man bequem beliebige
IO-Erweiterungen machen kann (PCF8574, 74HC595, 74HC165).
Auch geht der Trend weg von einem Zentral-MC hin zu mehreren kleinen.
Ein MC mit internem Flash ist bedeutend unempfindlicher bezüglich EMV
und daher leichter zu zertifizieren (meine persönliche Erfahrung).
Peter
Hallo Dieter,
Deine Planung einen 16 Bitter von Hitachi in Zusammenhang mit GCC zu
verwenden kann ich nur begrüßen. Allerdings würde ich Dir empfehlen,
eine H8S-CPU (z.B. H8S/2394) einzusetzen, die deutlich schneller
arbeitet. Als Anregung einen Link
www.mino-elektronik.de/chip_2352/chip_2352.htm.
An den Reaktionen auf Dein Vorhaben kannst Du vielleicht absehen, daß Du
hier keine Fans findest. Der eine weiß nicht, wozu 16 Bitter notwendig
sind, der andere vermutet "Krücken", obwohl er noch im Kinderwagen
sitzt, und wieder ein anderer hat keine Probleme, die ein
leistungsfähiger Prozessor elegant, schnell und preisgünstig lösen
könnte.
Der GNU-Compiler erzeugt recht guten Code; Probleme, wie sie hier oft
unter AVR-GCC angesprochen werden, habe ich damit nie gehabt. Ich
verwende die Ausgabe 98r2, die 'mal auf einer Hitachi-CD enthalten war.
Nur Mut Michael
Hallo,
wenn ich von einem 8 Bitter auf einen 16 Bitter umsteigen will, so muß
der mir dann auch mein Problem lösen. Die Anwendung (wie schon bemerkt
wurde) ist also maßgebend. Für rechenstarken Einsatz ist er sicher die
richtige Wahl aber zum "Sammeln" von Daten nicht wirklich besser. Eine
Anwendung als digitalen Recorder (für was auch immer) setzt eine sehr
hohe Taktgeschwindigkeit vorraus, größerer Adressraum allein hilft
nicht. Deshalb setze ich noch immer den 68HC811E2 (8MHZ) ein um z.B.
Ultraschall zu digitaliesieren (12 Bit Auflösung mit 400KHZ Abtastrate
und 8 Kanälen). Auch di 16 Bitter währen hier schon allein mit der
Adressensteuerung der Ram's überfordert.
MfG Manfred Glahe
Ich wollte Dieter nicht den Wind aus den Segeln nehmen!
Hab das Hardware Manual vom H8S/2394 überflogen und
muss zugeben das ich wohl mit der "Krücke" etwas voreilig war.
Ich hatte vor gut zwei Jahren ein Board mit
dem 80C535 (8-Bit,A/D-Wandler,UART,Timer,PWM usw. )entwickelt,aufgebaut
und auch erfolgreich in Betrieb genommen. Die erforderliche Software für
die Entwicklungsumgebung hab ich in VB programmiert.
Von der Entwicklung bis zum ersten Ausprobieren verging
nicht viel Zeit.
Ich will damit sagen, das wenn man am Ball bleibt und
das Ziel nicht aus den Augen verliert, so ein Projekt
erfolgreich sein kann.
Und wenn du gut in C/C++ bist, dürfte der H8S/2394 auch
kein Problem für dich sein.
Michael wird dir bestimmt noch ein paar Tips geben können!
@Stefan: schön, daß Du meine Anmerkungen nicht persönlich genommen hast;
ich hoffe, Du erfreust Dich bester Gesundheit.
Die C166er hatte ich mir Mitte der 90er angesehen, um vom 80C552
wegzukommen. Bei den 8051-Derivaten bestand ein Hauptproblem aus
Optimierungen, um die Teile ein bißchen auf Trap zu bringen. Soweit ich
mich erinnere, haben mich die SAB80C166 mit ihrer Segementierung und
ihrer etwas unübersichtlichen I/O-Funktionalität abgeschreckt. Der Preis
war hoch und ist es im Vergleich mit den Hitachi-Teilen heute noch.
Wer mit 8 Bittern auskommt, soll es bitte machen. Ich habe jedoch
gemerkt, daß der Umstieg auf 'dickere' CPUs viel mehr Luft beim
Programmieren und der Funktionalität bringt. Möglichst unsigned char zu
verwenden, wie es bei 8 Bit angesagt ist, haut doch vielfach nicht mehr
hin. Wenn man eine Filterung (gleitender Mittelwert) von 16 Bit
A/D-Werten braucht, muß man long-Variablen (32 Bit) verwenden - bei
Skalierungen/Umrechnungen z.B. mm->inch oder kPa->psi oder 'printf'
ebenso. Schnelle A/D-Samples kann ein DMA-Controller im Hintergrund
machen, während ein Schrittmotor im kHz-Bereich per Interrupt
angetrieben wird und ein Meßlineal (z.B. +/- 500,000mm) am
Inkrementaldecoder die genaue Position aufnimmt und über eine
Kalibrierungstabelle die Ungenauigkeiten des Meßtisches ausglichen
werden. Und das Alles gleichzeitig im ms-Takt. Ein 8 Bitter geht hierbei
voll in die Knie, ein Prozessor mit 32 Bit breiten Registern bringt hier
eine deutliche Leistungssteigerung !
Früher hatte ich das Problem, wie passt meine Aufgabe in den Prozessor.
Heute ist das kein Thema mehr. Dabei liegen die Kosten für
CPU/RAM/Flash-EPROM nur unwesentlich höher als die z.B. eines ATmega128.
Michael
Hallo Michael,
"Schnelle A/D-Samples kann ein
DMA-Controller im Hintergrund machen,"
Wie schnell ist eine Ramadresse beschrieben im DMA Modus? Und wie liest
Du die ADW Daten zwischendurch ein (oder hat Dein Controller einen ADW
mit 12Bit Auflösung). Welchen Controller (außer den Coldfire) kannst Du
für eine solche Anwendung empfehlen?
MfG Manfred Glahe
Hallo Manfred,
wenn Deine Frage auf 'Erbsenzählerei' hinausläuft: daran werde ich mich
nicht beteiligen.
Ein 16 Bit Wert benötigt zur Speicherung im internen RAM 50ns, extern
100ns bzw. 200ns (16 bzw 8 Bit Busbreite). Der DMA-Controller braucht
noch eine gewisse Zeit für die Buszuteilung (siehe Datenblatt). Mit
externem RAM 512kB kann man bei 400kHz und 16Bit etwa 0,5 Sek.
abspeichern - wenn es Dich interessieren sollte.
Michael
Hallo Michael,
natürlich interessiert es mich, sonst würde ich nicht fragen. Aber ich
wollte nicht wissen wie die write/time ist, sondern wie hoch die
Wiederholrate ist (darin sind alle Zeiten enthalten). Allein das
Schreiben ins Ram dauert nach deinen Angaben 200nS mal 8 Kanäle sind
1800nS + Totzeit zwischen Adressänderung?
D.h. ich möchte wissen wie schnell ich einen Wert (16 Bit) vom DAW
abholen und im RAM speichern kann.
Bislang habe ich keinen Controller gefunden der mir die existierende
HC11 Hardware ersetzen könnte und die Fragen nach technischen Daten sind
nicht "Erbsebzählerei" sondern Fachfragen und die sollte man auch als
solche beantworten (wenn man denn Antworten hat).
MfG Manfred Glahe
Hallo Manfred,
die mir bekannten Hitachi Controller haben eine
Auflösung von 10Bit. Schon mal schlecht.
Dann beträgt die max. Sampletime 2,8us pro Kanal.
(Beim H8/3069 mit 25MHz)
Allein damit sind keine 400kHz möglich.
Von 8 Kanaelen einmal ganz abgesehen.
Wie laeuft es denn bei deiner vorhandenen Hardware?
Bei 8 externen AD-Wandlern kaeme es auf einen Versuch an.
Das sind allerdings genau die Beispiele, fuer die ein
einfaches Entwicklungsboard Sinn macht.
MfG
Dieter
Hallo Dieter,
an interne ADW Kanäle denke ich dabei nicht, die sind, soweit mir
bekannt ist, alle zu langsam. Externe DAW's sind als serielle sehr gut
für diese Anwendung einzusetzen. Ich verwende den MAX5712. Das
eigentliche Problem ist die Steuerung der RAM- Bank. Mit dem HC11 geht
das nicht direkt denn der ist viel zu langsam dafür. Selbst mit einem
wesentlich schnelleren PIC16F84 wird das noch nichts. Die Frage ist
also, gibt es einen Controller der Daten vom Port einliest und sie dann
im Ram ablegt, mit einer ausreichenden Geschwindigkeit. (400KHZ/Byte).
Ein DSP währe hier wohl am Besten geeignet, aber den muß man auch
erstmal beherrschen und billig ist so ein Einstieg auch nicht gerade.
MfG Manfred Glahe
@Manfred,
wenns nur darum geht, Daten von einem Port zu lesen und im RAM
abzulegen, dann sieht das z.B. beim DS89C420 mit 33MHz so aus:
loop:
jnb Strobe, $
jb Strobe, $ ;Daten gültig mit Strobe 1->0
mov a, P1 ;port einlesen
movx @dptr, a ;und ablegen mit auto increment
ajmp loop
Das ganze dauert 14 Takte, d.h. das sind dann also 2,3MByte/s.
Oder man machts in einem Interrupt und reserviert einen DPTR dafür, dann
dauerts 16 Takte.
Noch 3* schneller gehts mit einem Cygnal C8051F120 (max 100 MIPS)
Beide sind allerdings nur popelige 8-Bitter und noch dazu von der
8051-Familie.
Peter
@Manfred:
1. Deshalb setze ich noch immer den 68HC811E2 (8MHZ) ein um z.B.
Ultraschall zu digitaliesieren (12 Bit Auflösung mit 400KHZ Abtastrate
und 8 Kanälen).
2. Mit dem HC11 geht das nicht direkt denn der ist viel zu langsam
dafür.
Was ist denn nun richtig ? Der MAX5712 ist ein DA-Wandler, wie soll ich
das verstehen ?
Beim H8S gibt es verschiedene DMA-Möglichkeiten. Eine davon ist der
'normal-mode' mit 'auto-request'. Hier werden max. 65636 Transfers (8
oder 16 Bit) in einem Rutsch ausgeführt. Bei 16 Bit Busbreite benötigt
man 200ns zur Übertragung eines Wortes. Das sind 10MB/s. Acht Kanäle mit
16 Bit bräuchten dann 1,6us entsprechend 600kHz. Bei 8 Bit Busbreite
verdoppelt sich die Zeit.
Bei 'kleineren' Samples unter 30KB (beim H8s/2394) kann man auch ins
interne RAM schreiben: 250ns/Wort oder 2us für acht Kanäle oder 500kHz
(8 Bit Datenbusbreite).
Wenn man 'nur' 400kHz Abtastrate hat (alle 2,5us ein Kanal) gibt es
andere Möglichkeiten des DMA-Controllers, die die CPU kaum belasten und
im Hintergrund laufen können, ohne den Prozessor zu blockieren. So hatte
ich Dein Problem verstanden.
Michael
Hi
Komisch bei mir steht der HC811E2 mit 8x8 ADW im Buch.
und für eine Singelumsetzung werden 32 Taktzyklen benötigt. Das sind bei
12MHz Quarz = 3MHz Takt 93,75 KHZ Umsetzrate je Kanal. Bei 8 Kanälen
also 11,72KHz.
Ultraschall auf 8 Kanälen????? Das ist zwar immernoch schneller als AVR,
aber man sollte auf dem Boden der Realitäten bleiben. Ich mag den HC11
auch, aber versuch mal einen HC12 oder HC16 da fängt der Spass erst
richtig an.
Gruss Uwe
Hi,
also die HC16 sind ja nun eher auslaufmodelle. Das dumme an den HC12ern
ist, das es nicht so einfacvh ist da ein BDM Tool zu bauen und das die
Gekauft unangenehm teuer sind.
Eckhard
Hallo Michael,
zu Deier Frage:Was ist denn nun richtig? Meine Angaben zu diesem
Problem waren offensichtlich nicht präzise genug (den ADW hatte ich
offensichtlich mit dem DAW namentlich verwechselt). Hier nochmal das
Problem.
Es müssen 8 analoge Kanäle mit 400KHZ Abtastrate und 12 Bit Auflösung
gewandelt und abgespeichert werden. Bei der geforderten Laufzeit fallen
dann 16MB Daten an.
Der HC11 steuert eine HARDWARE mit dem ADW MAX1284 und speichert dessen
Daten in einer Rambank. Natürlich wird da noch mehr getan (auch das
anschließende DAW mit dem MAX5712) aber das kann alles wesentlich
langsamer erfolgen und wird vom HC11 erledigt. Ich würde mir nun in
Zukunft die aufwendige Hardware für die Rambanksteuerung sparen wollen
und einen Controller einsetzen der diese EXTERNE Rambank dierekt
ansteuert (zumindest den unteren Adressbereich). Zu Herrn Dannegger: ist
das Abspeichern mit AUTOINC nur für das interne Ram zu verwenden?
MfG Manfred Glahe
Hallo Manfred,
ich hoffe, auch Du siehst es so, daß die zögernde Offenlegung Deiner
Anforderungen nicht ganz geschickt war. Auf die gleiche Weise könnte ein
8051 auch eine Frequenz von 800-900MHz in 1Hz Schritten erzeugen: Befehl
über RS232 an HP-Signalgenerator.
Der MAX1284 ist ein serieller Wandler und kein Flash-Wandler; folglich
braucht er noch eine Ablaufsteuerung, bevor er sein Ergebnis abliefert.
Deine Hardware ist daher sicherlich sehr umfangreich; die Leistung des
HC811 eher zweitrangig.
Ich will mich hier nicht auf dem H8S festbeißen, aber er würde es wohl
auch noch schaffen, Deine 16MB Daten per DMA abzulegen, wenn diese
parallel zum Zugriff zur Verfügung stehen: block transfer mode. Die
Daten müssen dabei memory-mapped vorliegen. Unter Umständen kann der DTC
(data transfer controller) den DMAC entsprechend konfigurieren und
nachladen. Dies erfordert aber ein bißchen Planung und Verständnis der
CPU. Der DMA-Controller kann dabei dann den gesamten Adressraum von 16MB
linear adressieren !
Oder man macht es wie Caesar der Römer nach der Regel 'parte et divide':
für jeden Kanal einen eigener Prozessor. Oder ein PLD, oder ...
Michael
Hallo Michael,
ich habe kein Problem mit der Offenlegung der Schaltung (im Anhang die
Hauptsteuerung und von mir aus auch den Rest wenns interressiert). Nur
handelt es sich hier um einen koplexen Ablauf der Verarbeitung und ich
wollte das Problem auf einfache Fragen reduzieren. Läßt sich aber so
wohl doch nicht durchführen, sehe ich jetzt ein.
Natürlich hast Du Recht, wenn es nur um die Ausgabe ginge aber das währe
eben nur der eine Aspekt. Im Prinzip handelt es sich um einen kompletten
"Recorder" welcher analoge Signale digitalisieren soll und z.B. auch auf
dem Oszi darstellen soll. Ebenfalls zur Ausgabe von synthetisierten
Daten oder Konserven soll er geeignet sein. Auf die Schnelle habe ich
das mit meinem derzeitigen Wissen gelöst.In Zukunft sollte es jedoch
eleganter gelöst werden und danach suche ich jetzt.
Die Ablaufsteuerung mit seriellen Wandlern benötigt natürlich
400KHZ*16/Kanal und deshalb habe ich diese Details bislang weggelassen
(paralelle Wandler sind auch möglich, müssen aber byteweise gepuffert
werden und selektiert werden und begrenzen ein für allemal die
Auflösung, serielle kann ich später für andere Aufgaben beliebig wählen
da die ADW/DAW Platine extern am Signal untergebracht ist). So
umfangreich ist die Hardware eigentlich nicht da sie auch noch den
programmierbaren Taktoszillator und die Paralellport anbindung zum
Rechner enthält. Möglicherweise findet ja jemand einen geeigneten
Controller für diese Anwendung (Datenblattangaben allein helfen nicht
unbedingt weiter). Ich möchte mich aber ausdrücklich für einige gute
Anregungen bei allen bedanken.
MfG Manfred Glahe
