Hi,
ich suche einen LPC mit SSP, external Memory, Flash ab 256KB, und wenn
möglich noch USB2.0. Ich habe bei Philips eigendlich schon gesucht, aber
vllt. habe ich was übersehen. Oder es gibt so einen LPC gar nicht.
Vielen Dank & Gruß
Nico
USB + externen Speicher gibt's bei den neuen LPC24xx. Der LPC2468 bietet
512KB on-chip Flash, full-speed USB device/host/OTG, zwei SSPs und einen
vollen 32-bit ext. Bus.
Die LPC23xx verfügen zwar auch über einen externen Bus, allerdings ist
der zum einen v.a. für I/O gedacht und zum anderen bei den aktuellen
Chips aufgrund eines Erratas unbrauchbar.
Der LPC2888 bietet sogar 1MB int. Flash und high-speed USB2.0
(480Mbit/s), hat aber nur I2S als synch. serielle Schnittstelle.
Der LPC3180 hätte full-speed USB (12Mbit/s), externen Speicher und zwei
SPI interfaces, aber kein internes Flash. Ausserdem ist er im Vergleich
mit den anderen LPCs natürlich schon ein sehr komplexer Controller
(ARM926EJ-S, MMU, Caches etc.).
Die LPC22xx hätten ebenfalls int. Flash, einen ext. Bus und SPI/SSP,
allerdings kein USB.
Als Alternative zum LPC gibt es die STR7X von ST Micro - der STR710-FZ2
sollte alle Anforderungen erfüllen, von high-speed USB abgesehen.
Der STR9x wäre ähnlich, allerdings mit dem leistungfähigeren ARM966E-S
core und 96MHz. High-Speed USB bietet er allerdings auch nicht.
High-speed USB 2.0 dürfte in der ARM7 Klasse generell schwer zu finden
sein (Ausnahme: LPC288x).
Gruss,
Dominic
Die neueren LPCs, also 23xx und 24xx befinden sich noch in der
Alpha-Testphase beim Kunden. Nach den bisherigen Erfahrungen mit
NXP/Philips sollte man die frühestens in 2-3 Jahren einsetzen.
Schau Dich doch auch mal bei Atmel, ST und Konsorten um. Wie der
Vorredner schon sagte, ist der ARM9 von ST eine gute Alternative.
Uiuiuiui, falsche Antwort.
Jetzt rollt gleich wieder die NXP-Marketingmaschinerie (Robert?) an und
wird ordentlich die Trommel für die LPCs schlagen. Obwohl Du Recht
hast...
Hi,
ich nochmal. Also ich habe mal geguggt..also der LPC2148 würde ja schon
gehen. Allerdings kein ext. Memory.
Ich weiss nicht wie es aussieht dann mit uC Linux? Gibt es da dann noch
eine andere Möglichkeit dieses zum laufen zu bringen?
gruß
Nico
Hi,
naja mit den NXP habe ich mich schon beschäftigt. da weiss ich welche
compiler ich für c bzw. c++ brauche. wie ich den flashe usw.
ich bin aber auch offen für was neues. deswegen meine frage zu den von
ST. Wie flashe ich den brauch ich da noch einen extra programmer oder
so? oder hat der wie die LPC einen Bootloader? Also ein bisschen habe
ich da schon rausgefunden. Die meisten ST haben einen zweiten, kleineren
flash in den man einen bootloader packen kann, nur der muss ja auch
irgendwie in den ST reinkommen. Und gibt es einen möglichst freien C
bzw. C++ compiler für die ST's? das einzigste was ich gefunden habe war
so einer von IAR aber der ist ja glaub ich auch nicht 4 free. Und wo
bekomme ich ST? Das einzigste was ich gefunden hatte, war farnell. aber
die sind ja leider etwas teuer. ich kann über die firma in der ich
arbeite, natürlich dann auch über distributoren bestellen die nur an
gewerbe liefern.
gruß & vielen dank
nico
Nimm doch den STR9, falls Du noch ein Errata Sheet suchst, das bereits
nach 9 Monaten umfangreicher ist als das Datasheet von manchen anderen
Bausteinen. Endlich mal ein echter Konkurrent fuer unsere ersten LPCs
Vielleicht koennten hier mal ein paar ihre realen Erfahrungen mit dem
STR9 schildern.
@ Andreas,
Marketing!? Whatever. Not worth an answer.
Danke fuer die immer wieder so freundlichen Bemerkungen. Das solls erst
mal fuer ne Weile gewesen sein. Falls jemand ernsthaft Hilfe sucht fuer
den LPCs bin immer auf dem LPC2000 forum zu finden.
Sorry fuer diejenigen, die dachten meine Beitraege hier waren hilfreich.
So guys, dig out your English and ask here if you need help:
http://tech.groups.yahoo.com/group/lpc2000
Bis denne, Robert
Komm mal auf den Teppich zurück Robert.
In der Tat ist es so, daß Du hier mächtig die Werbetrommel für NXP
schlägst. Mir persönlich stößt auch das ein oder andere Posting übel
auf.
Zudem hat sich NXP ja nicht mit Ruhm bekleckert. Das Testen scheint ja
mittlerweile größtenteils unterlassen zu werden. Oder wie erklärst Du
das Nichtfunktionieren des EMI vom 23er LPC?
Zudem solltest Du erstmal vor der eigenen Haustüre kehren, bevor Du
solche Andeutungen über Konkurrenten machst.
Ist nicht nur schlechter Stil, sagt auch viel über Deinen Laden aus.
Der Rufus schon wieder...
Denk einfach mal darüber nach: Wenn jeder Hersteller jetzt seine
Marketing-Guerilla hier posten und Konkurrenten schlechtmachen würde, um
von den eigenen unverantwortlichen Fehlern abzulenken, dann könnte man
das Forum wegschmeißen.
Ich sehe keinen Verlust darin, daß Robert jetzt den Beleidigten macht.
Im Gegenteil, hier gibt es doch mehr als genug Leute, die sich gut
auskennen und nicht Werbung machen.
Viel mehr als Robert's vielleicht etwas zu einseitig positive Sichtweise
auf die NXP Chips nervt mich das Gemecker über die NXP Chips.
Offensichtlich setzen sehr viele Kunden auch die alten LPCs erfolgreich
in ihren Produkten ein - die Chips sind also wohl nicht so schlecht, wie
sie hier von manchen gemacht werden.
Andere Hersteller haben ebenfalls genug Probleme, wie z.B. das Errata
Sheet des STR91xF zeigt (@Michael: das war keine Andeutung, sondern ein
Hinweis auf eine durch jeden nachprüfbare Tatsache).
Auch sehr amüsant waren die Erratas zum Hynix/Magnachip HMS30C7202 - da
wurden dann ganze Funktionsblöcke (I2S Audio) in späteren Versionen des
User Manual's gestrichen, da die Fehler zu gravierend waren.
Oder die Cirrus Logic EP93xx - da bleibt z.B. ein Fehler, der beim
Startup zu einem Deadlock führt, über mehrere Revisionen bestehen. Der
Workaround dazu ist besonders lustig: Da im Deadlock-Fall zwei für LEDs
gedachte Ausgänge für längere Zeit auf low bleiben, soll ein kleiner
Schaltkreis das erkennen, und nach ein paar Sekunden einen Reset
auslösen - also blos nie beide LEDs gleichzeitig leuchten lassen, sonst
wird ein Reset ausgelöst.
Die MaverickCrunch DSP Erweiterung hat mehrere Bugs, die bestimmte
Befehlssequenzen unmöglich macht - viel Spass beim Debugging, wenn der
Compiler auch nur einen einzigen davon nicht kennt.
Gruss,
Dominic
Also ihr geht ja nicht gerade freundlich miteinander um. Seit doch froh,
wenn jemand da ist, der sich um die Produkte kümmert.
Und selbst wenn jemand Werbung macht, kaufen muss man es ja trotzdem
nicht
Und ich persönlich finde die Werbung im TV viel schlimmer.
Ich glaube bei einigen kommt da einfach der Neid durch.
Robert, schade das du dich von ein paar so verärgern hast lassen.
Zurück zum Thema:
@Nico:
Ob dein ARM uC von NXP, Atmel, ST Micro oder sonst einem Hersteller
kommt ist ziemlich gleichgültig - ein C/C++ Compiler generiert Code, der
auf einer bestimmten ARM Architektur läuft (ARMv4, ARMv4T, ARMv5, ...)
und eventuell für eine bestimmte CPU optimiert ist (ARM7TDMI, ARM9TDMI,
ARM9EJ-S), aber unabhängig vom verwendeten uC ist.
Die Hersteller fügen "nur" die Peripherie rund um den ARM Core hinzu,
d.h. wie du die PLL konfigurierst oder wie du den SPI Controller
ansprichst kann sich unterscheiden, aber das ist dem Compiler egal.
Kommerzielle IDEs kommen bereits mit Startup Files für bestimmte uCs,
allerdings dürften die meisten Lösungen alle gängigen ARM7 und ARM9 uCs
unterstützen.
Als komplett freie Toolchain bietet sich GCC (GNU Compiler Collection),
GDB (GNU Debugger) und der OpenOCD (buhuhu, ich mieser Selbstvermarkter,
steinigt mich...) an - alles GPL lizenzierte Software, d.h. sowohl frei
als auch gratis.
Wenn du Interesse an einer bunten IDE hast lassen sich diese Tools in
Eclipse integrieren.
Fertige Binaries für Windows gibt es u.a. von GNUARM, WinARM oder
Yagarto.
Gruss,
Dominic
Noch ein extrem lustiges Beispiel für Errata:
Intel XScale3 (z.B. IOP13xx und ixp23xx) hat so viele gravierende
Fehler, dass Support für die ersten 3 oder 4 Revisionen aus dem Linux
Kernel entfernt wurde (oder werden sollte - hatte den Thread nur zu
Beginn verfolgt). Bei manchen musste der komplette L2 Cache deaktiviert
werden, um einen fehlerfreien Betrieb zu ermöglichen - danach war das
Teil allerdings so langsam, dass es nicht mehr zu gebrauchen war.
Der Intel PXA250 hat ein 56-seitiges "Specification Update", das 122
Probleme auflistet. Intel hat dann den PXA255 als Drop-In Replacement
gebracht...
Gruss,
Dominic
@Michael:
> jetzt seine Marketing-Guerilla hier posten
Ich frag mich grad wer hier den Guerilla spielt.
Klar klangen seine Posts etwas gefärbt. Kann ich mit leben. Ich denke
mir meinen Teil dabei, gebe auch mal meine Kommentare zu NXPs ab,
versuche freilich es auf technischer Ebene zu halten, nicht ins
persönliche zu gehen. Insgesamt fand ich seine Anwesenheit klar von
Vorteil. Vorteilhafter jedenfalls als deine, denn Leute die mit
Angriffen die ins Menschliche zielen andere rausekeln sind mir zuwider.
@Dominic:
Was Erratas angeht, meckert man naturgemäss über das was man kennt und
benutzt. Insofern ist dieses Gemecker nur ein Zeichen dafür, dass NXPs
verbreiteter sind als manch anderes bugverseuchtes Gemüse.
Dass 51er tendentiell weniger Fehler drin haben, liegt neben Komplexität
auch daran, dass in diesem Markt mit viel existierender Code neue
Hardware sucht, und da wärs schon besser, wenn die sich genauso benimmt
wie die alte. Aus dem selben Grund sind die Fehlerlisten von
PC-Prozessoren zwar lang, aber nicht annähernd so süffig wie grad die
CAN-Fehler im LPC2129. Und sind die Fehlerlisten von Grafikprozessoren
vermutlich länger als die gesamten Manuals von den LPCs - nur weniger
bekannt.