Hallo, ich habe seit einer gewissen Zeit AVRs in Assembler und seit kurzem auch in C geproggt, doch so langsam komme ich an ihre Grenzen, insbesondere was den RAM angeht. Nun würde ich jetzt gern auf ARMs umsteigen, allerdings weiss ich nicht ob es Atmel AT91SAM7 oder Phillips LPC2xxx sein soll. Was würdet ihr empfehlen? MfG Mark
Hallo, würde mich auch interessieren dieses Thema, gibt es irgendwo im Netz eine Art Tutorial von den beiden. Auch eine Basis-Schaltung die für das Grundverständis wäre gut. Mfg Daniel
Als Anfänger sollte man auf jeden Fall mit einem fertigen Board starten, das spart viel Zeit und Ärger. Ein paar Informationen zu den Unterschieden zwischen LPC2000 und AT91SAM7S gibt es im Wiki: http://www.mikrocontroller.net/articles/AT91SAM http://www.mikrocontroller.net/articles/LPC2000
Hallo, Ich habe mir die Links angeschaut und mich für die LPCs entschieden, da sie anscheinend leistungsfächiger sind als die Atmels. Eigentlich wollte ich mir mein eigenes Board zusammenlöten, da die fertigen Boards mir zu teuer sind bzw nicht die erforderliche Leistung bringen(oder zu viel davon haben->Kosten). Eine Basisschaltung wäre nicht schlecht Danke MfG Mark
Hallo, ich wäre auch lieber an einem eigenen Board interessiert, dass ich mir mehr oder weniger aus anderen zusammen stricke. Da ich mich da dann schon selber mit der Hardware auseinandersetzen muss. An Kenntnissen sollte es mir nicht mangeln, da ich auch auf AVRs sehr fit bin. Des weiteren bestünde bei mir die Möglichkeit am Arbeitsplatz mir einige Tipps zu holen. Aber prinzipiell möchte ich es selber schaffen. Mfg Daniel
Auch ich stand vor kurzem vor der Entscheidung, mit welchem Controller ich mir meine ARM-Kenntnisse aneignen soll. Ich hatte mich zunächst für den AT91SAM7X256 entschieden, weil ich einen CAN-Bus benötige. Als C-Compiler habe ich mich für WinArm entschieden. Außer dem üblichen Blink-Demos ist jedoch nichts sinnvolles herausgekommen. Die SAM7-Libraries von WinArm ist meiner Meinung nach zu umständlich und die langen Namen kann sich doch kein Mensch merken. Außerdem hat das Datenblatt von ATMEL die Note "Mangelhaft" verdient. Es kommt lange nicht, an die gewohnte Qualität der AVR-Controller heran. Irgendwann hab ich dann den ATMEL aufgegeben und mir einen LPC2129 zugelegt. Zwar ist bei diesem Controller die Hardware - sprich Stromversorgung - gegenüber dem ATMEL etwas umständlicher, aber die Programmierung war dank des übersichtlicheren Datenblatts und der vorhandenen Librarys mit gut zu merkenden Namen recht einfach. Alles in Allem kann man bei jedem Controller Vor- und Nachteile sehen, einfacher zu programmieren ist der LPC allemal. Die Schwächen der Stromversorgung beim LPC gleichen der schnellere Flash-Speicher und die 32-Bit Timer mehr als aus. Auch der Bootloader ist beim LPC einfacher zu aktivieren als beim ATMEL. Allerdings ist die Baudrate relativ gering, so daß ein Flashen des Speichers doch recht lange dauert. Dies ist besonders in der Entwicklungsphase recht mühsam. Wer noch Vor- und Nachteile aufzählen kann... nur zu. Den idealen Controller gibt es nicht. Eine Mischung aus beiden wäre das Ideal. Natürlich gibt es noch ARM-Controller von anderen Herstellern (z.B. von ST), die aber im Hobby-Bereich relativ selten zu finden sind. Erwin Reuss
Allerdings ist der CAN Controller vom LPC2129 eine geradezu imponierende zu nennende Sammlung von Bugs und Designfehlern. Imponierend insofern, als Philips sich getraut hat, das Teil so zu verkaufen. Und in der B Release nicht einen einzigen Fehler behoben hat.
@A.K. Das Errata Sheet is zu lang, keine Diskussion. Der LPC2364/66/68 waere evtl. eine Alternative mit den CAN Problemen behoben, nur eine Spannung und auch sonst noch ein paar nette neue Eigenschaften. Jetzt zur Version B des LPC2129. Wenn ein controller Anlaufprobleme haben kann, ganz gleich in welchem Prozentsatz, dann muessen diese so schnell als moeglich behoben werden (ohne Ruecksicht auf Verluste). Deshalb hat sich NXP dafuer entschieden den fast fertigen komplett erneuerten LPC2129 nochmals zu verschieben um den korrigierten Typen der immer zuverlaessig startet so schnell als moeglich auf den Markt zu bringen. Ungluecklicherweise sind Startup Probleme relativ verbreitet, so hat neuerdings der SAM7S auch welche als auch der STR9. Das bedeutet, wir kochen alle nur mit Wasser. Die Erratas des CAN lassen fuer >90% der Kunden Spielraum work arounds einzusetzen, deshalb sind sie in der Relation weniger kritisch. A.K. als Philips angefangen hat den LPC2129 zu verkaufen waren nur wenige der CAN Probleme bekannt. Soll ein Hersteller den Chip vom Markt nehmen wenn mehr Fehler bekannt werden und somit alle existierenden Kunden in den Sumpf fahren? Wir arbeiten (immer noch) an der Totalrenovierung der LPC21x9 und die werden wohl nach im 2. Quartal '07 auf den Markt kommen. Sie sind, wie bei NXP ueblich kompatibel zum Vorgaengermodell. Gruss, Robert
Ack zu den Bugs, wenn man das erst später merkt. Sind aber schon so heftige Dinger dabei, dass ich mich etwas drüber wundere, wie das durch die Tests durchrutschte. Was ich besonders interessant finde, ist das Interrupt-Design der CAN Channels. Bischen kurz gedacht scheint mir. Was beim SJA1000 sinnvoll war, erwies sich beim ARM als Falle. Da werden im 229x insgesamt 9 Interruptquellen für CAN verbraten. Aber weil das CANICR löschend liest, müssen sowohl Rx- als auch Tx-Handler letztlich beide Aktivitäten erledigen. Mithin eine Interrupt-Source für beide ausgereicht hätte. Der 9. Interrupt auf einen "grand unified interrupt handler" für alles rund um CAN rauslaufen muss. Wenn man den nun sowieso schon hat, kann man ihn genauso gut für alle CAN Interrupts nutzen. Womit dann 9 von 16 möglichen VIC-Vektoren den gleichen Inhalt haben. Und Interrupt-Nesting eine eher heikle Nummer wird. Oder habe ich da was falsch verstanden? Jedenfalls wäre mehr Nutzen drin gewesen, wenn man einfach bloss den SJA1000 reingeklebt hätte. Denn fast alles, was daran verbessert werden sollte, wurde zum Schuss in den Ofen.
Warunm laeuft es mir bei dem Ausdruck "geproggt" ohne Anfuehrungszeichen kalt den Ruecken runter?
@Uwe Bonnes: weil es kein richtiges Deutsch ist ich weiß^^ @alle: Ich hab da noch eine Frage, und zwar ob es möglich ist, einen 168-pol. PC-133 SD-RAM an einen LPC2294 anzuschließen und dann als externen RAM zu nutzen? MfG Mark
Nein bzw. nur mit sehr viel Aufwand, da die LPC22xx-Reihe keinen SDRAM-Controller enthält. Der Aufwand bestünde darin, in einem FPGA einen SDRAM-Controller zu implementieren, der sich dem LPC22xx gegenüber wie ein statisches RAM verhält; wenn ich mich jetzt korrekt erinnere, sieht das Speicherinterface des LPC auch nicht die Möglichkeit des dynamischen Erzeugen von Waitstates vor, was die ganze Sache verkomplizieren dürfte. Da ist ein ARM7 von OKI wesentlich attraktiver, der ML67Q5000. Den verbaut Olimex übrigens auch auf einer Platine: http://www.olimex.com/dev/oki5003.html Der LPC2888 enthält wohl auch einen (S)DRAM-Controller, ist aber dank BGA nicht mehr verarbeitbar ...
Warum willst Du an einem SAM7 so viel RAM, dass Du SDRAM brauchst? Fuer einen LPC mit viel SRAM, schau Dir mal Ulrich Radigs (www.ulrichradig.de) LPC22xx Board an. Mit dem LPC2378 und erst recht dem LPC2468 sind SRAM Erweiterungen auch moeglich. Fuer ein Selbstbauprojekt mit SDRAM wuerde ich eher an den Blackfin BF532 (blackfin.uclinux.org) denken. Mit den Stamp Board gibt es da auch schoene und bezahlbare Demoboards, sowie mit BF1 und Konsorten auch Selbstbauprojekte.
PS: Die Ankuendigung fuer die LPC24xx Bausteine spricht auch von SDRAM. Aber ob man unbedingt ein "Early Adopter" sein will?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.