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, wie sieht das denn mit der programmierung der ARM's von ST aus? Gibt es da einen C/C++ Compiler? Wie flashe ich diese ARM's? Gruß Nico
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
wieso muss der µC denn von NXP sein? Gibt doch noch sooo viel andere Hersteller...
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.
Zum Thema STR9 Erratasheet, es hat mit der Einführung der STR91xFA mächtig geschrumpft. Gruss, Tom
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.