Hi,
was mich mal interessieren würde, was gibt es bisher an µCs aufm Markt,
die einen integrierten SDram Controller besitzen? Optimal wäre
natürlich, wenn sie in C oder C++ programmierbar wären und es dazu auch
schon ein paar Projekte gibt. Aber ich gebe mich auch schon alleine mit
den µCs zufrieden ;)
Also ich weiß, dass z.B. der At91RM9200 von Atmel einen in Chip SDram
Controller hat. Allerdings hab ich bisher noch nicht so viel zum
programmieren eines ARM9s gefunden. Dann gäbe es da noch die LPC28xx
allerdings im BGA Gehäuse... das sagt alles ;)
Es muss kein ARM-Core sein, es sollte nur etwas Lektüre dazu geben und
er sollte in C/C++ programmierbar sein. Geschwindigkeit ist nicht ganz
so wichtig. Sie sollte mindestens im Bereich eines ARM7 von Atmel
liegen.
Vielen Dank fürs lesen und vielen Dank im voraus für etwaige Antworten!
Gruß
Chris
Ein ARM7 mit SDRAM-Controller ist der OKI ML67Q500x, der ist im TQFP144
auch noch ansatzweise lötbar (wenigstens kein BGA).
Da Olimex das Teil verbaut, müsste man auch irgendwie 'rankommen können:
http://olimex.com/dev/oki-h5003.html
ui den µC zu bekommen wird glaub schwerer als sich in den arm9
einzuarbeiten, selbst google gibt dazu nur 3 oder 4 ergebnisse aus, wenn
man ML67Q5 eintippt... wenn man noch zwei nullen dranhängt ist es nur
noch ein ergebins...
hat sonst noch jemand eine idee?
vielen dank
Chris :)
Wenn auf dem Prozessor noch ein (größeres) Betriebssystem laufen soll
bietet es sich an, sich die vom jeweiligen OS unterstützte Hardware
anzusehen.
z.B. im OpenSource-Bereich eCos oder NetBSD
http://ecos.sourceware.org/hardware.htmlhttp://netbsd.org/
Heraus kommen, neben einigen Exoten, auch die "üblichen Verdächtigen"
div. SH-3/SH-4 von Renesas, PowerPCs von Freescale oder die TX-19/39/49
von Toshiba
Lass mal sehen. DRAM heisst massig RAM, also 32 bit breit, mit 32 bit
Adressraum. Das sind inklusive Steuersignale R/W, usw, schon mal 70
pins. Bei 144 ist Schluss mit TQFP, da ist man schnell bei nem BGA.
Z.
Einerseits gibt es auch 208polige TQFP-Gehäuse, andererseits wird das
SDRAM bei den von mir genannten OKI-Bausteinen "nur" 16 Bit breit
angesteuert. Daher gibt es keine Probleme mit der Pinbelegung.
Um den Geschwindigkeitsnachteil des 16-Bit-Busses auszugleichen,
empfiehlt es sich hier, Code aus dem internen (schnelleren) SRAM
auszuführen.
erstmal vielen dank für die ganzen antworten! :)
ich komme auch mit nem 16bit datenbus zum sdram aus, was mir 16 pins
spart, da reicht dann wahrschienlich nen tqfp144 locker.
die ARM7SE klingen sehr gut, nur leider sind die noch nicht verfügbar
"Status: sampling" und der AT32 ist leider auch nur im BGA gehäuse
verfügbar, welches ich partout nicht löten kann :(
hab nochmal nen bisschen nach oki ARMs in shops gegoogelt aber bisher
noch nichts gefundne... hat den schonmal jemand in nem shop gesehen,
außer auf boards?
was mir vorallem wichtig ist, dass die MCus lötbar sind (also keine bga
gehäuse). sowie eben die programmierbarkeit mit c/c++. vorhandene
Projekte/beispiele(von denen vom hersteller abgesehen) wären natürlich
nie schlecht.
der blackfin ist doch nen dsp... mit dsps habe ich noch keine erfahrung
gemacht... unterscheiden die sich stark von µCs? hat der nen
integrierten SDram kontroller oder is der als SDram controller relativ
einfach nutzbar?
Chris
Hi, naja der BF531 ist nicht nur eine DSP Funktionalitaet, sondern
besitzt alles was ein heutiger ARM9 auch hat.
Der BF besitzt einen SDRAM Controller und wird somit sehr leicht
benutzt.
Der Mikrocontroller / DSP ist auch in kleinen Stueckzahlen relativ
billig. Leider gibt es USB / Ethernet nicht für das kleine LQFP176
Package, sondern erst ab BGA Package.
naja usb wäre nicht das problem... schließlich kann man ja extra
bausteine dafür benutzen...
was mich eher stört, ist, dass es keine ordentliche dokumentierte open
source bzw kostenlose IDE für c(++) für den Blackfin oder allgemein DSPs
gibt, soweit ich bisher gesehen hab(wobei meine suche vorallem auf den
Blackfin konzentriert war) oder habe ich etwas übersehen?
das teil klingt aufjedenfall interessant, aber da finde ich glaube ich
fast mehr zum AT91RM9200, der zur zeit auch noch in der auswahl steht...
gibt es denn sonst noch vorschläge oder anregungen?
jup allerdings... es gibt sogar nen angefangenen mame port fürn
blackfin... das is ja mal cool :)
das ganze infomaterial dort ist aber sehr darauf ausgelegt, wie man
vorgeht wenn man linux verwenden möchte... oder ist es etwa ratsamer
sich aufm blackfin mit linux auseinanderzusetzen, als ihn direkt zu
programmieren? letzteres wäre mir lieber...
ich werd jetzt einfach mal mit dem cygwin gcc port nen bissl rumspielen
und gucken was sich so erreichen lässt
Natürlich geht der BF auch ohne Linux oder mit einem anderen RTOS. Aber
als Start, um die Toolchain aufzusetzen, auf Leute zu treffen, die sich
damit auskennen etc. ;-) ist die Site nicht schlecht. Viele Infos,
Sourcen, Foren etc. gibts auch auf www.blackfin.org
Gruß,
Christian.
Also der Blackfin lässt einem schon das Wasser im Mund zusammenlaufen,
aber ich glaube er ist für mich doch etwas overpowered, wobei dass nicht
das größte Problem ist. Ich hab mich mal nen bisschen umgeschaut und
festgestellt, das ich zum At91RM9200, doch etwas mehr doku finde.
Zwei Fragen habe ich noch bevor ich mich wirklich festlege.
Erstens: Kann es sein, dass die Initialisierung des AT91RM9200, im
prinzip fast gleich ist wie bei den SAM7 von Atmel? Nur dass halt die
Register an anderen Adressen evtl sind und es mehr
konfigurationsregister gibt?
Was gleich zur nächsten Frage führt: Von der art und weise den C code zu
programmieren ist zwischen den ARMs, auch vom befehlssatz her kein
unterschied oder habe ich mich da verguckt?
Vielen Dank für eure antworten
Chris
Bei NXP (Philips Semic), gibt es auch die neue LPC2468 Micro Familie, in
LQFP208 Gehäuse, mit SDRAM Unterstützung. User Manual/data Sheet sind
auf der NXP Website. Der Micro ist auf der ARM7 Arhitektur basiert,
läuft mit 70MHz cpu, MicroCLinux auf externem Flash SPeicher (kann man
extern anschließen), 512KB internes Flash, etc.. Hofe es hielft Dir
weiter.
