<*nk*tz> Hallo Leute, ich hab mir eben die Beschreibung der ARM/LPC1100 hier im Forum angesehen und nach den LPC800 gesucht und immerhin ein wenig gefunden. Nur: ziemlich out-of-date (Stand 2011?) z.T. Fehler. Ich hab paar kleine Korrekturen gemach. Wahrscheinlich ist der Auto vor diesem Forum davongelaufen. Ich kann mich noch an einen Robert Teufel erinnern, vor ein paar Jahren, der immer von den LPCs geschw"armt hat. Das hat aber offensichtlich nicht gefruchtet. Man kann S"ackeweise Saatgut in der W"uste versenken, da geht nichts auf! Wo kaum Wasser ist, da gedeihen nur die gen"ugsamsten Kakteen und lassen am liebsten gar nichts an sich ran. Hier im Forum k"onnen anscheinend nur PICs, AVRs, 8051, MSP430 und im Ausnahmefall ein STM32 wurzeln und vor sich hindursten. So verdorrt und ausgelaugt ist hier der Boden. Und was darauf vor sich hin darbt, das taugt h"ochstens dazu dem Menschen das Vorw"artskommen zu erschweren oder Schatten f"ur 'nen kleinen Fusszehen zu spenden. Aber ob der Mensch "uberhaupt noch gewillt ist woanders bessere Bedingungen zu suchen? Vielleicht will er sich lieber hinsetzen und sehns"uchtig an die letzte Eiszeit denken. Ach w"urde sich das Klima doch bloss zu seinen gunsten ver"andern und wieder Bedingungen wie fr"uher herrschen. Aber wenn ein Fremder vorbeikommt und von Wiesen, Wald und Wasser redet, dann schneidet der hiergebliebene ein St"uck aus einem Kaktus, presst demonstrativ 7 Tropfen Wasser raus, dann mit aller Gewalt noch einen 8. Dann schaut er verachtungsvoll den Fremden an und sch"uttelt den Kopf. Wie kann man nur mehr brauchen wollen!? Aber die 8 Tropfen gen"ugen ihm nicht wirklich, er ist bloss zu faul seinen Hintern zu bewegen. Denn bei jeder anderen Sache ist er gar nich so bescheiden und nimmt, was er (umsonst) bekommen kann. Ist das hier eine LPC-freie Zone? Sind die so unattraktiv? Steckbrett: Schon mal 'nen LPC810FN8 (DIP8) angeschaut? Nein? Einen LPC1114FN28 (DIP28) eines Blickes gew"urdigt? Nein? Oder vielleicht f"ur die 'modernen' unter euch: LPC812JD20 (20-SOIC-W), LPC1110FD20 (20-SOIC-W), LPC1112FD20 (20-SOIC-W), die kann 'man' schon noch ohne Probleme l"oten, wenn man was anderes als 'nen 80W Schweisskolben aus dem Baumarkt hat. Auch nicht? Brauchen zuviel Strom im aktiv-Modus z.B. 2mA@12MHz. Vermutlich. Und im (Nicht:Deep-) Power-Down sowieso (z.B. 3uA mit Ausgangsregistern aktiv, self-wakeup-timer laufend, 4 wakeup-pins aktiv). Und die 1.8V..3.6V sind auch so ungeschickt, wenn man nicht z.B. die ultra-low-level NXP PMVxxUP/UN MOSFET am Ausgang verwendet (z.B. PMV30UN, wenn's mal wieder etwas mehr Strom sein muss), sondern seine MOSFET-Restposten aus den 90er Jahren verbrauchen will (BUZ...). Und die Pins dieser Micros sind ja auch nicht Arme, sondern eher nur D"aumchen (Thumb2?) mit nicht mal 10mA, aber allerh"ochstens mal 20mA - l"acherlich f"ur jeden Bastler-Mindestanforderungskatalog. Dann wohl tats"achlich besser Finger weglassen, von dem neumodischen Kram. </*nk*tz>
Ich kann deinen Frust gut verstehen. Lassen wir mal die alten Mikrocontroller bei Seite, jedoch koennten sich die LPC's doch besser durchsetzen. Im direkten Vergleich mit den STM32 finde ich eine super IDE, mit fast keiner Begrenzung (LPCXpresso mit einem Codelimit von 256 Kb), eine schoenere Dokumentation (ich finde die NXP Doku persoenlich besser beschrieben, als z.B. die ST Dokus) und natuerlich die tollen Mikrocontroller. Jedoch sehe ich auch, dass die ganzen Cortex Mikrocontroller noch etwas Zeit brauchen um sich durchzusetzen. Ausserdem hat NXP leider beim Marketing ein paar Fehler gemacht (also nach meinem Gefuehl). Sie bieten zwar super Produkte und ein tolles Angebot an, jedoch hat ST mit dem STM32F4Discovery vom Marketing her einfach gewonnen. Das Board hat freie Pins und direkt ein wenig Peripherie zum rumspielen (die Peripherie fehlt einfach bei den Xpresso Boards oder es sollte welche geben mit ein wenig Peripherie zum Einsstieg). Ausserdem konnte ST seine Boards schneller an den Mann bringen. Ich denke da nur an die Embedded World, wo gefuehlt jeder Besucher am Ende mit einem STM32F4Discovery nach Hause gegangen ist und das mindestens zwei Jahre in folge. Es fehlt wirklich ein Gegenstueck zu dem STM32F4Discovery von NXP und sie muessen echt eine aggressivere Vermarktung betreiben!
" ...Schon mal 'nen LPC810FN8 (DIP8) angeschaut? Nein?" Doch .. aber vielleicht ist es einfach die Einarbeitungszeit die Viele scheuen. Aber ein WIKI Artikel für den schnellen Einstieg wäre natürlich sehr hilfreich ;-) Ich beschäftige mich normalerweise nur mit der MSP430 Familie. Aber die kleinen schnellen 32 Bitter interessieren mich sehr. cheers
Ich mach mal wünsch dir was: TQFP im 0.8 Raster, 32-64 Pins, viel und flexibles I/O welches per interner Switchmatrix auf die Ports configurierbar ist.
Im Vergleich z.B. zum Attiny85 fehlt dem LPC800 das EEPROM und der AD-Wandler: http://www.mikrocontroller.net/part/LPC812
Also LPC1114 hab ich schon für private Basteleien verwendet (LQFP). Mir war gar nicht klar, dass es die LPC111X Familie zum Teil auch in SOIC gibt. Das ist für kleine, einseitige Platinen definitiv besser geeignet.
Hallo Marc, ich finde es auch Schade, dass der LPC81X so wenig Beachtung findet. Eine Maßnahme wäre es vielleicht, die Wikiartikel auf den neusten Stand zu bringen. Andererseits ist auch das offizielle Forum ziemlich verwaised..
chris_ schrieb: > Im Vergleich z.B. zum Attiny85 fehlt dem LPC800 das EEPROM und der > AD-Wandler: > http://www.mikrocontroller.net/part/LPC812 Wenn man diese braucht, dann ja. NXP hat vor Jahren schon angekündigt, ein Upgrade der 81X Serie mit ADC auf den Markt zu bringen. EEPROMS gibt es in den neueren Controllern fast nie. Dafür kann man sich aber häufig einen Teil das Flash als Datenbereich sichern.
:
Bearbeitet durch User
Aladin schrieb: > Ich mach mal wünsch dir was: TQFP im 0.8 Raster, 32-64 Pins, viel und > flexibles I/O welches per interner Switchmatrix auf die Ports > configurierbar ist. Die LPC81X haben eine ziemlich flexible Switchmatrix. Den LPC812 gibt es auch im 0.8 mm SOIC für Leute die sich keinen Lötstoplack leisten können. 32-64 Pins sind einfach nicht der Zielbereich für die kleinen Controller. Die ATtinies kommen ja auch nicht als 64pin TQFP. Dann muss es einer der grüßeren sein (LPC12xx usw.)
Arne Maximilian R. schrieb: > Zeit brauchen um sich durchzusetzen. Ausserdem hat NXP leider beim > Marketing ein paar Fehler gemacht (also nach meinem Gefuehl). Sie bieten > zwar super Produkte und ein tolles Angebot an, jedoch hat ST mit dem > STM32F4Discovery vom Marketing her einfach gewonnen. Das Board hat freie > Pins und direkt ein wenig Peripherie zum rumspielen (die Peripherie Da muss ich Dir recht geben. NXP war mit den dev-Board für die LPC81X Reihe recht großzügig - ich habe von allen drei Versionen (LPC800 mini, LPC812 mbed, LPC812 Xpresso) eines abstauben können. Praktisch anwendbar fand ich nur das Mini-Board. Und da hätte es auch ein Mini Breakout getan. Mein liebstes LPC812 Devboard ist noch mein eigenes :) https://github.com/cpldcpu/LPC812breakout
:
Bearbeitet durch User
> Schon mal 'nen LPC810FN8 (DIP8) angeschaut? Nein? Nein, wieso auch. DIP8 ist laecherlich. Braucht sehr viel Platz, hat kaum Anschluesse und ist Bastler unfreundlich weil man in seinen Platinen dafür noch 8 Loescher bohren muss. Mir kommt ausschliesslich SMD auf die Platine. Aber wenn du so gefrustet bist, wie kommt es das hier kaum einer Renesas benutzt? Weltgroesster Hersteller von Microcontrollern, bergeweise Derivate, sehr gute Doku (dagegen ist STM32 ein Witz), sehr leistungsfaehig, viel Peripherie, gute Entwicklungsumgebung, einfach zu flashen. Wird hier auch ignoriert als wenn man davon eine fiese Krankheit bekommt... Die Antwort ist, die Schafe fressen nur das Gras dessen Farbe sie kennen. Olaf
Olaf schrieb: > Nein, wieso auch. DIP8 ist laecherlich. Braucht sehr viel Platz, hat > kaum Anschluesse und ist Bastler unfreundlich weil man in seinen > Platinen dafür noch 8 Loescher bohren muss. Mir kommt ausschliesslich > SMD auf die Platine. Dafür passt DIP8 auf ein Breadboard. Und der LPC810 benötigt nicht wie ein ATtiny85 4 Anschlüsse für den Programmieradapter sondern nur zwei. (Serieller Bootloader oder SWD).
:
Bearbeitet durch User
Tim schrieb: > Dafür passt DIP8 auf ein Breadboard. Und der LPC810 benötigt nicht wie > ein ATtiny85 4 Anschlüsse für den Programmieradapter sondern nur zwei. > (Serieller Bootloader oder SWD). Du hast vergessen zu erwaehnen, dass SMD nicht gerade freundlich fuer die Lochrasterplatine ist, die man in der Hobbyentwicklung gerne verwendet. Das waere naemlich fuer mich einer der wichtigsten Punkte, weil ich mir schnell eine Platine selber loeten kann. Aenderung: Y -> Z scheiss amerikanische Tastatur -.-
:
Bearbeitet durch User
Es liegt aber evtl. auch an der mangelnden Verfügbarkeit. Wenn ich bei meinem normalen Lieferanten (Segor) nach den LPC Bausteinen suche, finde ich trotz des normalerweise guten Sortiments eben nur ein ganz paar (3) Stück, die auch preislich nicht mit entsprechenden STM32 mithalten können. Ich bin nicht auf eine Familie festgenagelt, (bin z.Zt. auch mit dem LPC2220 in der Betty am spielen), aber warum soll ich mir eine schlechte Verfügbarkeit antun? 8-beiner gibt es nun auch von PIC und von Atmel. Da muss ich mir nicht noch eine Familie ins Haus holen, und auch die braucht wieder eine eigene Toolchain, einen anderen Programmer usw.
:
Bearbeitet durch User
>Ist das hier eine LPC-freie Zone? Sind die so unattraktiv?
Im TV reden die Leute doch auch nur von "Promis", obwohl deine Nachbarin
vielleicht ein besserer Mensch als die Frau Klum o.ä. ist.
Das kann man doch nicht dem Forum vorwerfen, wenn die Chips sich z.B.
nicht gegen stm32 durchgesetzt haben. Für Solche "Spezialfälle" gibt es
auch spezialisierte Communities, meist auf der Herstellerseite.
Lpc setzt sich nicht so durch aufgrund der Preispolitik. ST bietet bei hohen Stückzahlen und Kunde mit grossem Namen Preise, bei denen man als Hobbyentwickler und Diigikeykunde vor Überraschung vom Stuhl fällt.
@ MarcVonWindscooting (Gast) >Man kann S"ackeweise Saatgut in der W"uste versenken, da geht nichts >auf! Wo kaum Wasser ist, da gedeihen nur die gen"ugsamsten Kakteen und >lassen am liebsten gar nichts an sich ran. Du hast was melodramatiches an dir, gefällt mir ;-) >Hier im Forum k"onnen anscheinend nur PICs, AVRs, 8051, MSP430 und im >Ausnahmefall ein STM32 wurzeln und vor sich hindursten. Genau. Die ARMEN Irren, mit diesen ach so schlechten uCs. > So verdorrt und >ausgelaugt ist hier der Boden. Das Gegenteil ist der Fall. Die Möglichkeiten übersteigen die Notwendigkeiten in den meisten Fällen um einiges. Erkennbar unter anderem dadurch, dass des öfteren ein uC zum LED blinken statt eines NE555 oder wie ganz früher 2 Transistoren genommen wird. >"uberhaupt noch gewillt ist woanders bessere Bedingungen zu suchen? Nur wenn es ihm schlecht genug geht. >Vielleicht will er sich lieber hinsetzen und sehns"uchtig an die letzte >Eiszeit denken. Oder einfach das Leben geniessen anstatt krampfhaft was NOCH besseres zu suchen? > Ach w"urde sich das Klima doch bloss zu seinen gunsten >ver"andern und wieder Bedingungen wie fr"uher herrschen. Als bekanntlich alles besser war. ;-) > Aber wenn ein >Fremder vorbeikommt und von Wiesen, Wald und Wasser redet, dann >schneidet der hiergebliebene ein St"uck aus einem Kaktus, presst >demonstrativ 7 Tropfen Wasser raus, dann mit aller Gewalt noch einen 8. >Dann schaut er verachtungsvoll den Fremden an und sch"uttelt den Kopf. >Wie kann man nur mehr brauchen wollen!? Das ist der Punkt. Die meisten brauchen schlicht nicht mehr. >Ist das hier eine LPC-freie Zone? Sind die so unattraktiv? Wenn sie denn so toll sind, dann zeig es doch dem Rest der Welt. Schreibe Artikel und ebensoviele enthusiastische wie penetrante Beträge wie ein bekannter Mr. STM32. Vielleicht wirkt es ja. Gold, das unter der Erde liegt und keiner sieht, interessiert keinen. Und wenn sich etwas Neues gegen etabliertes durchsetzten will, muss es nicht nur besser sein, es muss die Leute mitreißen. Oder starke Sehnsüchte, Wünsche, (Leistungs)Anforderungen erfüllen. Kann das dein LPC? >Schon mal 'nen LPC810FN8 (DIP8) angeschaut? Nein? Über den Sinn von 32 Bit im DIP8 kann man vorzüglich streiten ;-) >Einen LPC1114FN28 (DIP28) eines Blickes gew"urdigt? Nein? Anders herum wird ein Schuh draus. Die Neuen müssen sich darstellen und versuchen die Platzhirsche zu verdrängen, nicht als schlafendes Dornröschen geweckt werden.
Ja und was ist erst mit den Kinetis ARMs (M0+ und M4) von Freescale? Auch sehr schöne Teile aber hier schreibt keine Sau drüber ;) Oder was ist mit den XMC von Infinion? Super Chips aber nirgends erhältlich da die Autoindustrie da schon die ganze Produktion aufkauft ;) MfG
Fer T. schrieb: > Ja und was ist erst mit den Kinetis ARMs (M0+ und M4) von Freescale? > Auch sehr schöne Teile aber hier schreibt keine Sau drüber ;) Es gibt wahrscheinlich zu wenig Leute hier im Forum, die von der Stückzahl her in dem Bereich liegen, ab dem man von Freescale überhaupt erst eines Blickes gewürdigt wird.
Die kleinen LPCs sind wirklich sehr schwer zu bekommen, obwohl sie sehr interessant aussehen. LPC8xx, LPC11xx, usw. bei Reichelt, Conrad oder gar eBay: kaum verfügbar. Die STM32 bekommt man dagegen praktisch an jeder Ecke hinterhergeschmissen. Das gleiche Spiel bei den Devboards. Ein STM32-Discovery gibt's sogar für < 10 EUR!
Vor einem gefühlten Jahr hat elpro sein LPC-Sortiment eröffnet bzw. gut erweitert. Das sollte man fast alles zu guten Preisen finden. Außer z.B. den LPC11Cxx. Ich bin auch aus vielen Gründen LPC-Fan, aber was Vielfalt angeht, ist STM nicht zu schlagen. So gibt es nur einen CM0 mit CAN; den LPC11Cxx. Und auch nur mit LQFP 48. Das ist sehr gut, aber der nächste mit CAN ist ein CM3 im LQFP80!
Mir hat NXP zuviel Kahlschlag im 8051 Segment betrieben. Wer einmal seine langjährigen Stammkunden im Regen stehen läßt und nur verbrannte Erde hinterläßt, bei dem kauft man so schnell nichts mehr. Daß jemand so schnell und so viele ICs völlig ersatzlos aus dem Programm nimmt, habe ich noch bei keinem anderen Hersteller erlebt. Selbst recht neue MCs wurden eingestampft, z.B. der P89C668. Glücklicher Weise ließ er sich mit leichten Firmwareanpassungen durch den AT89C51RE2 ersetzen.
Olaf schrieb: > Wird hier auch ignoriert als wenn man davon eine fiese > Krankheit bekommt... Und dafür gibt es Gründe: Mieserable Output-Pin Belastbarkeit, man braucht also quasi immer Treiber, schlechte Ausgangsflexibilität, meist nur ganze Ports in der Richtung umschaltbar, schneller abgekündigt als man einen beschaffen konnte (man denke an den R8C den Elektor verschenkte, ein Jahr später gab es ihn schon nicht mehr und auch nichts kompatibles)., und für Bastler nicht beschaffbar (ausser Glyn, und Glyn mag vor allem Firmenkunden), extrem mühsam an das kostenlose DevSoftware zu kommen (Registrierung die nach kostenpflichtig aussieht). Der Prozessor innendrin, quasi ein 68000er, ist Super, die Programmierbarkeit in C Spitze, aber wenn man so blöd beim Marketing und Peripheriedesign ist, hat man selber schuld. Und NXP ? Wenn man sich ein mal so einen Flop wie die XA Architektur leistet, kann man nicht erwarten, daß einem Kunden noch in Scharen hinterherlaufen, der ARM im LPC2000 ist von Philips nicht dokumentiert, da muss man woanders gucken http://www.altera.com/literature/third-party/ddi0100e_arm_arm.pdf
Danke f"ur euer Feedback! @falk Ich werde versuchen in Zukunft mal paar Vorteile aufzuzeigen. Bin je momentan voll dran am LPC800. @cpldcpu Ja, das breakout-board ist chic. Verkaufst Du die auch? Schematic in einem PDF w"are sch"on, denn ich hab auf dieser Maschine z.B. kein EAGLE habe(w"are ja zuviel verlangt von denen, mal 'ne 64-Bit Linux-Variante anzubieten). LPC800 besch"aftigt mich wegen der Low-Power-Features. Da w"urde mich ein Breakout-Board mit einem STLQ015 LDO (1uA Ruhestrom oder so!) reizen. @fer_t Ja, die Teile von Infineon XMC1100 seh ich regelm"assig mach, nur um festzustellen dass sich noch nichts getan hat :( Und generell bin ich ein Europ"aer und militanter "Oko, der tendenziell versucht europ"aische Firmen zu bevorzugen. NXP hat "ubrigens eine gute Umweltpolitik - man kann von ganz vielen Bauteilen sogar den chemical content von der HP runterladen - Hammer, oder? @Olaf Renesas war der Grund, dass ich nach 'ner Alternative f"ur 'nen M16C... zu suchen begann und (damals) den LPC2100 entdeckte. Zuvor kannte ich Siemens und Atmel-Datenbl"atter von 8051 Derivaten und ein 600+ Seiten Manual von Renesas (f"ur so wenig Funktion) hat mich geschockt... @greg Ja, das mit dem bekommen ist so 'ne Sache. Conrad, Reichelt, usw. Fehlanzeige. Aber es gibt bestimmt Leute hier im Forum, die welche verkaufen w"urden. Ich hab schon "ofters Sammelbestellungen hier gesehen. Aber klar, ist schon umst"andlich und der, der sie verkaufen w"urde k"onnte nur verlieren, denn a) wehe er w"urde f"ur seinen Zeitaufwand auch noch was verlangen wollen b) wehe es w"urde ein Baustein mit 'nem krummen Beinchen ankommen... LPC800 zum Einstieg - da weiss ich auch nicht so recht, was ich sagen soll. Als ich mir den uC zum ersten Mal programmierte (LED an/aus) hab ich geflucht, weil ich dachte das sei sooo kompliziert. Heute weiss ich dass es gar nicht kompliziert ist, denn die Switchmatrix und IOCON braucht man dazu gar nicht. GPIO clock and, DIR0=1<<LED setzen, SET0=1<<LED. Fertig. Wenn man aber richtig "Low Power" will, dann muss man das Ding tendenziell schon in seiner Gesamtheit verstehen. Der SCT ist auch so ein Teil. Erstes mal Kapitel lesen => Schock. Ich will doch nur einen Timer/PWM/Capture...!?? Heute find ich den SCT toll, denn z.B. kann man zum ersten mal den Timer-Ablauf durch ein externes Signal beeinflussen, d.h. man kann Sachen realisieren, die viel schneller sind als eine ISR. Die meisten Peripherieeinheiten sind ganz anders als bei den sonstigen LPCs. UART komplett neu, I2C komplett neu, GPIO wieder anders (mehr Alternativen, Bit-Direktzuweisung z.B.!), Switch Matrix nat"urlich ganz besonders, dann die BOOT-ROM-Routinen, wenn man fertige UART, I2C, PowerMode Routinen verwenden will, SPI anders, usw... Wenn man mit dem LPC800 (oder auch LPC1100) anf"angt, dann wird man allerdings nicht um einen anf"anglichen Frust aufgrund des grossen Manuals umhin kommen.
MarcVonWindscooting schrieb: > Ist das hier eine LPC-freie Zone? Sind die so unattraktiv? Das liegt eher daran dass bei den LPCs fast alles einfach so funktioniert, daher gibt es nicht so viel Diskussionsbedarf :-) Die meisten uC Threads hier sehen doch so aus: Fusebits - Ausgesperrt: Beitrag "Na wunderbar - Fusebits: Ausgesperrt aber mit den richtigen Eingaben?"
Allerdings habe ich auch schon mal einen LPC1114FN28 "verfused". Ich wusste vorher nicht, dass das geht.
chris_ schrieb: > Allerdings habe ich auch schon mal einen LPC1114FN28 "verfused" Bitte um Beschreibung wie das gehen soll. Man könnte höchstens über CRP den ISP-Pin sperren, damit der Bootloader nicht mehr geht, und das geflashte fehlerhafte Programm müsste die SWD-Pins switchen, damit man mit dem Debugger nicht mehr ran kommt.
Lothar schrieb: > Bitte um Beschreibung wie das gehen soll. CRP3 schaltet lt. Doku sowohl ISP als auch SWD ab. Da dürfte es dann auch keine Rettungsmassnahme mehr geben.
:
Bearbeitet durch User
> CRP3 schaltet lt. Doku sowohl ISP als auch SWD ab. Da dürfte es dann > auch keine Rettungsmassnahme mehr geben. Es ist dann halt die Pflicht des geflashten Programms, den bootloader zu aktivieren (reinvoke ISP) :-) Klingt nach Henne-Ei-Problem. Fast genauso gef"ahrlich finde ich den NO_ISP mode, wenn man z.B. bei den wenigen Pins halt SWCLK und SWDIO f"ur was anderes benutzt. Ausl"oten zum neu flashen ist nicht so attraktiv....
>Bitte um Beschreibung wie das gehen soll.
Ich bin mir nicht mehr sicher, wie es genau war, da es schon einige
Monate her ist. Soweit ich mich erinnern kann, habe ich an der PLL
rumgespielt, um die maximale Taktrate zu erreichen, da das vorhandene
Beispiel nur mit 1/4 lief.
>MarcVonWindscooting schrieb: >Ja, das breakout-board ist chic. Verkaufst Du die auch? Schematic in >einem PDF w"are sch"on, denn ich hab auf dieser Maschine z.B. kein EAGLE >habe(w"are ja zuviel verlangt von denen, mal 'ne 64-Bit Linux-Variante >anzubieten). In Debian 64 Bit kannst du EAGLE Light über den Installer installieren.
MarcVonWindscooting schrieb: > Ja, die Teile von Infineon XMC1100 seh ich regelm"assig mach, nur um > festzustellen dass sich noch nichts getan hat :( > Und generell bin ich ein Europ"aer und militanter "Oko, der tendenziell > versucht europ"aische Firmen zu bevorzugen. NXP hat "ubrigens eine gute Bist Du der Meinung, dass Infineon nicht Europäisch ist? Die XMC 1000 werden m.W. in München designed, wo auch die Firmenzentrale von Infineon ist. NXP ist eine niederländische Firma. allerdings ist sie im Wesentlichen im Besitz einer amerikainschen "Heuschrecke". So viel dazu. MarcVonWindscooting schrieb: > @cpldcpu > Ja, das breakout-board ist chic. Verkaufst Du die auch? Schematic in Das wurde ich schon mehrfach gefragt. Die Herstellung scheint kein so großes Problem zu sein, allerdings habe ich keine Ahnung, wie ich das Board effizient vertreiben sollte. Kann hier jemand einen Zwischenhändler empfehlen? Versand, Reklamationsabwicklung usw. selbst durchzuführen, ist für mich einfach zu umständlich. > einem PDF w"are sch"on, denn ich hab auf dieser Maschine z.B. kein EAGLE > habe(w"are ja zuviel verlangt von denen, mal 'ne 64-Bit Linux-Variante > anzubieten). Werde ich mal machen. > LPC800 besch"aftigt mich wegen der Low-Power-Features. Da w"urde mich > ein Breakout-Board mit einem STLQ015 LDO (1uA Ruhestrom oder so!) > reizen. Der kann allerdings nur 150mA. Damit könnte man den LPC812 nicht mehr voll belasten und nur wenig Peripherie ans board hängen.
:
Bearbeitet durch User
Tim schrieb: > ist. NXP ist eine niederländische Firma. allerdings ist sie im > Wesentlichen im Besitz einer amerikainschen "Heuschrecke". So viel dazu. Aber das Wesen einer Firma wird halt stark durch die Mitarbeiter bestimmt, und die sind zum Gl"uck Niederl"ander. Die Steuern landen in den Niederlanden, die Arbeitspl"atze auch, und die erw"ahnte 'Environmental Policy' stammt vmtl. auch nicht aus dem Kopf der nach Geld geifernden Heuschrecke. Und ja, bei Infineon schau ich immer noch vorbei (nur) weil deutsche Firma. MSP430 ist "ubrigens auch eine deutsche Entwicklung, wenn man nachforscht, obwohl TI. @Tim: Nenn mir 'nen Preis f"ur 30 Platinen, ich kauf sie dir alle ab und vertick sie hier im Forum. Der Ansturm wird nicht so gewaltig sein, dass die Aufgabe nicht zu stemmen w"are. Du musst sie herstellen, das will ich nicht (Bleifrei, RoHS-konform, versteht sich von selber, oder?). Ich l"ote selber mehr als genug! Sie zu, dass Du was verdienst, sonst hast Du ganz schnell keine Lust mehr den G"onner zu spielen. So werd ich's auch machen. Es muss nicht kostendeckend sein, nein es muss was rausspringen. Denn sonst hab ich mehr davon, mich z.B. mit dem LPC4300 zu besch"aftigen.
Die LPCs werden soweit ich weiss in Nürnberg designed, das Wesen der Firma ist Niederländisch und das ist positiv gemeint.
MarcVonWindscooting schrieb: > @Tim: Nenn mir 'nen Preis f"ur 30 Platinen, ich kauf sie dir alle ab und > vertick sie hier im Forum. Der Ansturm wird nicht so gewaltig sein, dass > die Aufgabe nicht zu stemmen w"are. Erm - ich habe im Github-Repository einen Link zum Design bei OSH-Park: http://oshpark.com/shared_projects/rQra0bCX Die senden Dir drei Platinen für $3.30 inkl. Porto nach Deutschland. Einfach bestellen. OSH Park fertigt mit RoHS-konformen ENIG-Finish. Edit: Habe das in der Beschreibung noch einmal herausgehoben.
:
Bearbeitet durch User
MarcVonWindscooting schrieb: > Tim schrieb: >> ist. NXP ist eine niederländische Firma. allerdings ist sie im >> Wesentlichen im Besitz einer amerikainschen "Heuschrecke". So viel dazu. > > Aber das Wesen einer Firma wird halt stark durch die Mitarbeiter > bestimmt, und die sind zum Gl"uck Niederl"ander. Die Steuern landen in > den Niederlanden, die Arbeitspl"atze auch, und die erw"ahnte > 'Environmental Policy' stammt vmtl. auch nicht aus dem Kopf der nach > Geld geifernden Heuschrecke. Dann schau aber auch bei Atmel nach, z.b. werden die Automotive Bauteile in Heilbronn gemacht, sämtliche Radio Trx wie AT86xxxx oder ATmegaRF in Dresden. In Frankreich werden die ARM7/9/CortexA5 und M0/3/4 designed, In Norwegen sitzen immer noch Designer. Die Touch Geschichte kommt aus England. In Spanien wird Powerline communication entwickelt. Ist doch schon sehr europäisch
MarcVonWindscooting schrieb: > @Tim: Nenn mir 'nen Preis f"ur 30 Platinen, ich kauf sie dir alle ab und > vertick sie hier im Forum. Der Ansturm wird nicht so gewaltig sein, dass > die Aufgabe nicht zu stemmen w"are. > > Du musst sie herstellen, das will ich nicht (Bleifrei, RoHS-konform, > versteht sich von selber, oder?). Ich l"ote selber mehr als genug! Sie > zu, dass Du was verdienst, sonst hast Du ganz schnell keine Lust mehr > den G"onner zu spielen. So werd ich's auch machen. Wenn Du mit "Platine" einen fertigen Aufbau meinst wird es komplizierter. Schreibe mir halt einfach 'mal eine PM. Kannst Du auch gerne im LPC800 Forum machen.
:
Bearbeitet durch User
Lothar schrieb: > Die meisten uC Threads hier sehen doch so aus: Du hast eine selten selektive Wahrnehmung von "meiste". ;-) MarcVonWindscooting schrieb: > Es ist dann halt die Pflicht des geflashten Programms, den bootloader zu > aktivieren (reinvoke ISP) :-) Mit der gleichen Begründung könntest du es allerdings zur Pflicht eines jeden AVR-Entwicklers machen, dass er vor dem Ändern der Fuses da einen Bootloader programmiert … Davon abgesehen, hat Atmel ja das Dilemma durchaus dann erkannt und bei den Xmegas ein anderes Konzept verfolgt. Der ursprüngliche AVR war nicht dafür konzipiert, dass man zur Laufzeit den Takt umschaltet (hängt mit der Betriebsweise des Flashs zusammen), daher hat man das dort mit den Fuses gemacht. MarcVonWindscooting schrieb: > Ist das hier eine LPC-freie Zone? Sind die so unattraktiv? Die 8-Pinner vermutlich schon. Die gibt's ja nur mit einer so minimalen Ausstattung, bei den 8-Pin-AVRs kann man zumindest noch einen aus vier Modellen wählen (ATtiny13/25/45/85). Ansonsten müssen die LPCs natürlich mit allen anderen ARMs der diversen Hersteller konkurrieren. Da sie sich alle nicht viel nehmen, streut sich die Publikumsresonanz bei denen ein bisschen breiter als bei AVR oder PIC (wobei PIC ja nun auch schon eher wieder ein Sammelbegriff ist).
@ MarcVonWindscooting Sei froh, daß Du was gefunden hast, den Eintrag über die LPC8xx Familie gibt es erst seit dem Wochenende. Die Artikel werden mehr oder minder regelmäßig überarbeitet. Robert ist nicht mehr bei NXP, er hat in San Francisco eine Consulting Firma http://www.mcu-related.com, und fährt damit sehr gut. Die LPCs gibt es fast nur in SMD, und wenn man die Beiträge so liest bekommt man den Eindruck als wären die Meisten hier im Forum DIL-Liebhaber. Vermutlich haben viele noch nicht festgestellt, daß man eine große Auswahl - in SMD - bei http://www.elpro.org für einen sehr guten Preis bekommt... man braucht nur den Mut für SO, TSSOP und QFN. Das mag anspruchsvoll sein, aber für den ambitionierten Hobbybastler auch kein großes Problem. Des Weiteren gibt es die von Arne genannte "super IDE" @ Oscar und Tim Die 5 Artikel zum LPC http://www.mikrocontroller.net/articles/Kategorie:LPC1x wurden maßgeblich von einem Bearbeiter erstellt, ohne deutlich mehr Autoren (oder einem - wie Markus - der mehr Zeit hat) wird das auch nix werden! @ Matthias: Schau doch mal unter http://www.elpro.org/shop/shop.php Microprozessoren ==> 32-Bit Controller ==> "ARM-Cortes-M0 von NXP" oder "ARM-Cortes-M3 von NXP" oder "ARM-Cortes-M4 von NXP" Die Shop-SW ist zwar gewöhnungsbedürftig, die Auswahl aber groß, und die Preise sehr gut. Die LPCs können sehr wohl mit den Preisen mithalten. Oder auch unter http://darisusgmbh.de/shop/advanced_search_result.php?keywords=LPC1&x=0&y=0 Den kleinen LPC1110FD20 - 4kB-Flash, 50MHz im SO20" gibts bereits ab 1,00€! Übrigens: den LPC2220 nicht mit der LPC1xxx Serie vergleichen. Die Preise sind definitiv mit den von STM32 vergleichbar, wenn nicht besser. Fazit: ==> super IDE ==> sehr gute Preise ==> ohne mehr Autoren hier im Forum wirds aber trotzdem nix
Ich muss mich hier auch mal einschalten. Ich persönlich bin Mega begeistert von den lpc13xx Serie. Habe schon viel damit gebastelt und bin sehr zufrieden. Das man hier nich viel Infos bekommt stimmt aber ich find die Dokus von NXP echt gut. Verfügbarkeit stimmt schon aber ich bestell halt einmal im Jahr bei Digikey und dann relativ viel. Wenn jemand Interesse hat habe ich bestimmt welche zum Abgeben.
A. K. schrieb: > CRP3 schaltet lt. Doku sowohl ISP als auch SWD ab. Da dürfte es dann > auch keine Rettungsmassnahme mehr geben. Da ist doch wohl ein wesentlicher Unterschied: beim AVR müssen die Fuses (fast) immer gesetzt werden, dementsprechend die Fehlerhäufigkeit. Beim LPC versehentlich CRP3 zu setzen ist (fast) unmöglich.
Volker K. schrieb: > Die LPCs gibt es fast nur in SMD, und wenn man die Beiträge so liest > bekommt man den Eindruck als wären die Meisten hier im Forum > DIL-Liebhaber. > Ja, merkwürdig. Keine Ahnung warum. Als ich letztens auf die billige Verfügbarkeit von Adaptern auf DIP aller Art (z.B. bei eBay) aufmerksam machte, wurde ich auch gleich komisch angemacht
Lothar schrieb: > beim AVR müssen die Fuses (fast) immer gesetzt werden Nö, so häufig nun auch nicht. Am besten läuft er ohnehin vom internen RC-Oszillator, und das ist die Voreinstellung. (Vor allem wacht er dann schnell auf.) Aber hier geht's um LPC800, nicht um AVRs …
Kappos schrieb: > Wenn jemand Interesse hat habe ich bestimmt welche zum Abgeben. LPC1112FD20, sagen wir 10Stck? Und so 1 oder 2 DIL8 LPC810? In meiner Platine zur Programmentwicklung (LPC1110) d"urfte mal bissl mehr RAM als 1K drin sein, auch wenn sp"ater ein LPC1110 verbaut wird. (Grund: http://www.windscooting.com/softy/ramloader.html) @greg, Volker K.: > bekommt man den Eindruck als wären die Meisten hier im Forum > DIL-Liebhaber. Ich hab das von den DILs auch nur geschrieben, weil ich eben auch den Eindruck gewonnen hatte, dass viel mit dem Breadboard gearbeitet wird. Mach ich auch mal. Wenn ich Spass beim L"oten haben will oder die Platine selber "atzen will, nehm ich SOIC. Wenn's klein werden soll TSSOP (LPC800) oder gleich LQFP. Wer davor Angst hat, benutzt keine Flussmittelchreme!?!!
Jörg Wunsch schrieb: > Die 8-Pinner vermutlich schon. Die gibt's ja nur mit einer so minimalen > Ausstattung, bei den 8-Pin-AVRs kann man zumindest noch einen aus vier > Modellen wählen (ATtiny13/25/45/85). Ernsthaft? Ich sehe da nur zwei Produkte. Der Rest ist zur Verwertung von Dies mit Speicherfehlern.
Tim schrieb: > Der Rest ist zur Verwertung von Dies mit Speicherfehlern. Oder auch nur zur Reduktion des Testprofils. Ist schon eine Weile her, aber irgendwann sagte Atmel mal, dass kein Rebinning stattfindet. Pass oder fail, und fail=Müll. Hinreichende Ausbeute vorausgesetzt ist das wahrscheinlich logistisch einfacher.
A. K. schrieb: > Oder auch nur zur Reduktion des Testprofils. Ist schon eine Weile her, > aber irgendwann sagte Atmel mal, dass kein Rebinning stattfindet. Pass > oder fail, und fail=Müll. Hinreichende Ausbeute vorausgesetzt ist das > wahrscheinlich logistisch einfacher. Naja, man kann immer noch nach Bereichen auf dem Wafer selektieren. Die ATiny25 kommen dann komischerweise immer vom Rand. Das ist nichts Neues... Ebenso: Was ist Rebinning? Nach dem ersten Test lässt sich ja bereits entscheiden, ob es ein 85 oder 25 wird?
:
Bearbeitet durch User
Tim schrieb: > Ebenso: Was ist Rebinning? Nach dem ersten Test lässt sich ja bereits > entscheiden, ob es ein 85 oder 25 wird? Hier ja. Die ursprüngliche Aussage bezog sich auf den damaligen Unterschied zwischen den Fullspeed-Typen mit 5V und den Halfspeed-Typen mit grossem Spannungsbereich. Da ist das eine Testprofil keine Teilmenge des anderen. Leg mich bitte auch nicht auf den Begriff fest, oder lass das "Re" weg. Die Frage ist eher, ob es bei ohnehin guter Ausbeute wirtschaftlich ist, die Produktion unterschiedlich zu labeln und zu lagern, oder ob es ökonomischer ist, grad das dabei zu kriegen, was man braucht. Ich wär bei mancher Fertigung auch nicht erstaunt, wenn Wafer stichprobenweise mit vollem Profil getestet und wenn leidlich brauchbar zunächst auf Halde gelegt werden. Um dann später bei Bedarf zersägt und mit dem gewünschten Testprofil gelabelt verkauft zu werden, abhängig vom Bedarf. Nützt ja nix, wenn man tonnenweise fertig gelabelte und verpackte 85er rumliegen hat, der Kunde aber 25er haben will.
:
Bearbeitet durch User
Der Punkt ist doch eher, dass man aus einem 85er mit teilweise defektem Flash ein 25er machen kann. Da ist ist die Entscheidung zwischen Chip wegwerfen oder als preiswerteres Produkt auf Lager legen. Klar, wenn der Auftragsbestand bei den 25ern gut ist, werden aus 85ern eben 25er gemacht. Das ist dann die Aufgabe der Logistiker. In dem Fall wird eben das Testprogramm "Zerstöre alle 85er" geladen, und die Testingieure machen sich über die "BWLer" lustig... Irgendwie scheint diese Diskussion aber am Thema vorbei zu gehen. Allerdings glaube ich, dass es bei den LPC800 genau so gehandhabt wird und die ganze Serie den gleichen Die verwendet. Offensichtlich wird das daran, dass der LPC810 die komplette Switch-Matrix, sowie alle GPIO-Treiber hat, wie man per Software einfach feststellen kann.
:
Bearbeitet durch User
Tim schrieb: > Der Punkt ist doch eher, dass man aus einem 85er mit teilweise defektem > Flash ein 25er machen kann. Da ist ist die Entscheidung zwischen Chip > wegwerfen oder als preiswerteres Produkt auf Lager legen. Für sowas gibts Pfennigfuchser, die genau ausrechnen, ob der Aufwand lohnt, alle mit vollem Testprofil für 85er zu testen und aus der Fertigung verschiedene Varianten zu kriegen und zu lagern. Oder ob es billiger ist, bei Bedarf an 25ern auch nur das kürzere und damit schnellere Testprofil zu fahren. > Allerdings glaube ich, dass bei den LPC800 genau so gehandhabt wird und > die ganze Serie den gleichen Die verwendet. Ich wäre erstaunt, wenn es anders wäre. Diegrösse einzusparen ist eine Sache, viele Fertigungsmasken kostspielig herstellen und in der Fertigung dann häufig auswechseln zu müssen eine andere. Bei den STM32 gibts ja auch eine Unzahl von Varianten, z.B. bei den F101/102/103. Viele davon sind ein Subset anderer Typen, nicht bloss bei Flash/RAM, sondern auch in I/O-Funktionen. Auch da gehe ich davon aus, dass sich die oft nicht im Die, sondern beim Testprofil oder gar bloss dem Aufdruck unterscheiden. Beim Speicher kanns dann sein, dass es 2 Varianten gibt, die untere und die obere Hälfte der Kapazitäten vielleicht separate Dies sind.
:
Bearbeitet durch User
A. K. schrieb: >> Allerdings glaube ich, dass bei den LPC800 genau so gehandhabt wird und >> die ganze Serie den gleichen Die verwendet. > Ich wäre erstaunt, wenn es anders wäre. Übrigens ist das ein ziemlich interessantes Feature der LPC800. Selbst auf dem 8-Pin LPC810 sind alle GPIO-Treiber vorhanden. Dadurch kann man über die Switchmatrix Peripherie über interne Pins verbinden. Leider will NXP das nicht offiziell bestätigen (Warum wohl?) :) Ein Beispiel ist in diesem Thread: http://www.lpcware.com/content/forum/controlling-ws2812-led-strips-lpc810 Man kann SPI und SCT auf einem LPC810 verknüpfen, ohne externe Pins zu belegen.
:
Bearbeitet durch User
@ A. K. (prx) >Bei den STM32 gibts ja auch eine Unzahl von Varianten, z.B. bei den >F101/102/103. Viele davon sind ein Subset anderer Typen, nicht bloss bei >Flash/RAM, sondern auch in I/O-Funktionen. Auch da gehe ich davon aus, >dass sich die oft nicht im Die, sondern beim Testprofil oder gar bloss >dem Aufdruck unterscheiden. Naja, aber wie machen sie es dann mit den verschiedenen IDs per JTAG etc? Fuse Zapping? Lasertrimmung?
Falk Brunner schrieb: > Naja, aber wie machen sie es dann mit den verschiedenen IDs per JTAG > etc? Fuse Zapping? Lasertrimmung? Werden Fuses sein, aka Flash-Zellen. Wie sonst auch. Die Dinger haben auch eine eindeutige ID drin, d.h. es wird sowieso jedes Exemplar angepasst.
PS: Eindeutige ID = Seriennummer, in jedem Exemplar anders. Die STM32 haben auch einen OTP-Bereich, den der Kunde nur einmal beschreiben kann. Also die Werkzeuge dafür sind da.
Volker K. schrieb: > Des Weiteren gibt es die von Arne genannte "super IDE" An IDEs für ARM gibts es sowieso keinen Mangel mehr: z.B. 'Code::Blocks' http://www.codeblocks.org/ EMIde (basiert auf Code::Blocks) http://emide.org/ Und da sind jede Menge NXP Controller schon bei.
Hat jemand Intersse an einem (oder besser gleich mehreren) bestückten LPC812breakout Board(s)??? Falls genug Interessenten da sind, würde ich mal ( vorrausgesetzt, Tim stimmt zu ) meinen Auftragsfertiger um ein Angebot bitten. Der bestückt auch relativ kleine Stückzahlen (Vorserien/Testserien) per Automaten. Sobald ich die Preise habe, könnte ich die Sache abwickeln. Gruß
Reiner Geiger schrieb: > Hat jemand Intersse an einem (oder besser gleich mehreren) bestückten > LPC812breakout Board(s)??? Billiger als das hier: http://www.diamex.de/dxshop/NXP-LPC812JDH20-auf-Adapterplatine
Lothar schrieb: > Billiger als das hier: > > http://www.diamex.de/dxshop/NXP-LPC812JDH20-auf-Adapterplatine Naja... das ist wirklich ausschließlich ein Adapter ohne irgendwelche Zusatzkomponenten. Das Schöne am Board von cpldcpu war doch, dass da ein bisschen nützlicher Kleinkram mit drauf war: Spannungsregler, Abblockkondensatoren und Reset-Taster. Dazu nette passende Pin-Beschriftung. 8-9 EUR für ausschließlich Adapter finde ich zu teuer. Der LPC812 kostet < 1 EUR und das winzige PCB Centbeträge. Das Breakout-Board von cpldcpu für den Preis wäre vielleicht in Ordnung.
Nachtrag: also wenn mir jemand einfache mit LPC812 fertig bestückte Adapterboards für 8 EUR abkauft, löt ich die gerne zusammen - in Kleinmengen 1,50 EUR Materialkosten pro Stück. Das lohnt sich. ;)
greg schrieb: > Nachtrag: also wenn mir jemand einfache mit LPC812 fertig bestückte > Adapterboards für 8 EUR abkauft, löt ich die gerne zusammen - in > Kleinmengen 1,50 EUR Materialkosten pro Stück. Das lohnt sich. ;) Genau das wollte ich auch gerade schreiben .... Ich dachte auch eher an das originale Board von Tim. Ich glaube dass (bei der kleinen Stückzahl) der Preis für ein automatenbestücktes und getestetes Board so zwischen € 8,- und € 10,- liegen wird, da kein Bauteil in schwierig zu bestückendem (optische Kontrolle mit Stereomikroskop) Gehäuse dabei ist.
Macht doch eine Art Lanchpad/Discovery für den LPC! Plug & Play!
Reiner Geiger schrieb: > Falls genug Interessenten da sind, würde ich mal ( vorrausgesetzt, Tim > stimmt zu ) meinen Auftragsfertiger um ein Angebot bitten. Super idee. Das würde ich aktiv unterstützen.
Falk Brunner schrieb: > Macht doch eine Art Lanchpad/Discovery für den LPC! > Plug & Play! naja, es gibt die LPCXpresso boards, aber damit bin ich bisher noch nicht so richtig warm geworden. Das ist halt ein ziemlich blöder Formfaktor.
Tim schrieb: > Der Rest ist zur Verwertung von Dies mit Speicherfehlern. Das hast du genau autoritativ von wem jetzt so gehört? Sowas hat man vielleich bei DDR-Bastler-ICs gemacht. Bei den Flashs hier würde sich keiner drauf einlassen, einen IC mit teilweise nicht funktionierendem Flash noch zu verkaufen. Solange die Ursache des Fehlers nicht klar ist, wäre ja immer ein hohes Risiko, dass mehr als nur das kaputt sein könnte, was beim ersten Test festgestelt worden is. Die Ursache zu ermitteln, wäre jedoch teurer, als das Ding dann gleich in die Tonne zu kloppen. Aber wenn du das so willst, gibt's halt in dieser Klasse nur den alten ATtiny13 und den Nachfolger ATtiny85; letzterer hat aber dann schon mal mehr Ressourcen als der kleine LPC800. Falls der 8-Pin-LPC800 jedoch nur ein größerer Die mit kleinerer Spezifikation ist, wäre es nicht klar, warum NXP den nicht auch mit 8 Pins aber mehr Features (für mehr Geld) verkaufen möchte. Tim schrieb: > Leider will NXP das nicht offiziell bestätigen (Warum wohl?) :) Das ist genau der Punkt: genauso, wie Atmel es sich offen halten wird, ob der ATtiny25 nun nur ein ATtiny85 mit anderem Etikett ist, oder ob es tatsächlich ein viel kleinerer Chip ist, wird NXP dir eben nicht garantieren, dass das dann ein für allemal so bleibt. Spätestens, wenn der erste Auftrag über ein paar Millionen ICs reinkommt, wird dann der kleinere Chip doch noch hergestellt. Lohnt sich halt nur für den Einstieg nicht. Aber drauf verlassen kannst du dich nicht, nicht in einer Serie. (Fürs einzelne Bastlerexemplar ist es natürlich OK.) A. K. schrieb: >> Naja, aber wie machen sie es dann mit den verschiedenen IDs per JTAG >> etc? Fuse Zapping? Lasertrimmung? > > Werden Fuses sein, aka Flash-Zellen. Ja, OTP-Fuses. Also eine Einbahnstraße, damit man die Teile nicht nachträglich umfusen kann. Neben der JTAG-ID kann man damit natürlich auch tatsächlich Einschränkungen im Device implementieren, also bspw. nicht den gesamten Flash oder RAM sichtbar machen. Auf die paar Gatter in den Adressleitungen kommt es ja dann auch nicht an. ;-)
:
Bearbeitet durch Moderator
Tim schrieb: > Falk Brunner schrieb: > naja, es gibt die LPCXpresso boards, aber damit bin ich bisher noch > nicht so richtig warm geworden. Das ist halt ein ziemlich blöder > Formfaktor. Stimmt, aber es gibt ja noch die Starter-Kits von Embedded Artists: http://www.embeddedartists.com/products/boards/lpc1343_qsb.php http://www.embeddedartists.com/products/boards/lpc11u35_qsb.php Dazu die LPCXPresso IDE ( C,C++ ); für Leute mit etwas Erfahrung ein tolles Tool. Freescale Development-Tools a la LPCXpresso, aber günstiger und besser ausgestattet; Cortex M0, M3 und M4 und eine excellente kostenlose Entwicklungsumgebung (CodeWarrier+ProcessorExpert); jede Menge Libraries und Hilfestellung und und und ....... aber ein bischen Erfahrung braucht man auch hier. Wer sich aber mal auf was neues einlassen will, oder aus irgendwelchen Gründen umsteigen muss ( 8-Bit --> 32 Bit) kann mal im folgenden Blog schnüffeln gehen: http://mcuoneclipse.com/ ... und fast hätte ich vergessen: wer es spartanisch mag (IDE) findet hier noch ein leistungsstarkes und sehr preisgünstiges Board (Cortex M4 mit 256KB Flash und 64kB RAM) mit einer angepaßten "ARDUINO"-Entwicklungsumgebung. Alle AVR Libraries laufen auch auf ARM!
:
Bearbeitet durch User
Jörg Wunsch schrieb: > Das hast du genau autoritativ von wem jetzt so gehört? Ohne Kontext zitieren kann ich auch. Ich arbeite nicht für Atmel, daher kann ich nur Vermutungen äußern. Es ist durchaus auch denkbar, dass die Controller genug Redundanz im Flash haben so dass der Flash-Yield nicht limitiert. Das Binning von Bausteinen und Fusen von defekten Speicherzellen ist aber gängige Praxis. Es gibt allerdings tatsächlich einen Hinweis darauf, dass der ATtiny25 nicht den gleichen Die wie der 85er nutzt: Die 85er ist nicht im 150 mil SOIC erhältlich, was auf einen größeren Die hindeuten könnte.
:
Bearbeitet durch User
Reiner Geiger schrieb: > > ... und fast hätte ich vergessen: > > wer es spartanisch mag (IDE) findet hier noch ein leistungsstarkes und > sehr preisgünstiges Board (Cortex M4 mit 256KB Flash und 64kB RAM) mit > einer angepaßten "ARDUINO"-Entwicklungsumgebung. Alle AVR Libraries > laufen auch auf ARM! Da fehlt natürlich der passende Link: http://www.pjrc.com/teensy/teensy31.html
greg schrieb: > Nachtrag: also wenn mir jemand einfache mit LPC812 fertig bestückte > Adapterboards für 8 EUR abkauft, löt ich die gerne zusammen - in > Kleinmengen 1,50 EUR Materialkosten pro Stück. Das lohnt sich. ;) Kümmerst Du Dich dafür auch um die elektrischen Test und den Versand? :)
@Jörg Wunsch: >Sowas hat man vielleich bei DDR-Bastler-ICs gemacht. Bei den Flashs >hier würde sich keiner drauf einlassen, einen IC mit teilweise nicht >funktionierendem Flash noch zu verkaufen. Solange die Ursache des >Fehlers nicht klar ist, wäre ja immer ein hohes Risiko, dass mehr als >nur das kaputt sein könnte, was beim ersten Test festgestelt worden >is. Die Ursache zu ermitteln, wäre jedoch teurer, als das Ding dann >gleich in die Tonne zu kloppen. Und sowas macht man bestimt auch heute noch. Das ist ja gerade die Kunst beim Schreiben der Testprogramme, dass man so schnell wie möglich herauskitzelt was zuverlässig geht und was nicht. Ich hab jetzt zwar keine konkreten Daten dazu vorliegen, aber ich bin mir sicher das es nur so läuft. Bei den Preisen pro Maskensatz ist es für die Hersteller einfach nicht rentabel für jedes Derivat eine eigene Maske zu machen, selbst wenn die Masken für einen AVR sicher günstiger sind als beispielsweise die für einen PC-Prozessor. Zusätzlich zu den Masken kommt ja dann auch noch das Handling für unterschiedliche Wafer. Aber da müsstest Du ja eigentlich die besseren Quellen für Informationen haben. Wenn sowas gemacht wird ist die Abschaltung von Speicherbereichen ja auch schon im Design vorgesehen, d.h. die Abschaltung ist in der Schaltung irgendwie berücksichtigt. Damit sollte es dann auch keine Wechselwirkungen mit dem defekten Teil geben. Ich vermute mal das selbst die Funktion mit abgeschaltetem Flash schon im Wafertest geprüft werden kann. Und die Gründe für einzelne Ausfälle analysiert heutzutage eh niemand. Da wird viel Statistik über mehrere Wafer gemacht und versucht systematische Fehler und wiederkehrende Fehlermuster zu verstehen. Um nochmal zu den PC-Prozessoren zurückzukommen, wenn ich das richtig in Erinnerung habe geht man da gar nicht von einem immer Fehlerfreien Speicher aus und baut den gleich so, das eine bestimmte Anzahl von Fehlern auf dem Die per Remapping von Reserve-Speicherzellen ausgeglichen wird. Jens
Jens schrieb: > Um nochmal zu den PC-Prozessoren zurückzukommen, wenn ich das richtig in > Erinnerung habe geht man da gar nicht von einem immer Fehlerfreien > Speicher aus und baut den gleich so, das eine bestimmte Anzahl von > Fehlern auf dem Die per Remapping von Reserve-Speicherzellen > ausgeglichen wird. Ja, das wird auch beim DRAM und Flash so gemacht. Die Ausbeute von heutigen Speichern würde ohne Redundanz sehr gering sein...
Tim schrieb: > Jörg Wunsch schrieb: >> Das hast du genau autoritativ von wem jetzt so gehört? > > Ohne Kontext zitieren kann ich auch. > > Ich arbeite nicht für Atmel, daher kann ich nur Vermutungen äußern. Das klang aber wie eine ziemlich definitive Aussage, nicht wie eine Mutmaßung. > Es > ist durchaus auch denkbar, dass die Controller genug Redundanz im Flash > haben so dass der Flash-Yield nicht limitiert. Das Binning von > Bausteinen und Fusen von defekten Speicherzellen ist aber gängige > Praxis. Das mag für große Flashs der Fall sein (also alles, was da so als NAND-Flash im Gigabytebereich herumdümpelt), bei denen müssen die Kosten pro Byte extrem gering gehalten werden. Bei denen kann man aber auch (wie bei normalen Festplatten) mit Sektorersetzungen arbeiten, da muss nicht unbedingt jedes Byte funktionieren. Die vergleichsweise kleinen Flashs von Controllern müssen dagegen 100%ig zuverlässig funktionieren, und das über die spezifizierte Lebensdauer. Die sind auch entsprechend teurer, allein die Kosten für den Test eines großen Controller-Flashs machen einen substanziellen Anteil der Gesamtkosten eines Controllers aus. Jens schrieb: > Ich hab jetzt zwar keine konkreten Daten dazu vorliegen, aber ich bin > mir sicher das es nur so läuft. Ich weiß, dass es (zumindest im Controllerbereich) nicht so läuft. > Bei den Preisen pro Maskensatz ist es > für die Hersteller einfach nicht rentabel für jedes Derivat eine eigene > Maske zu machen, … Das hängt halt davon ab, wie viele verkauft werden. Aber auch, wenn man keine separaten Maskensätze für die ganze Familie baut, betreibt man trotzdem kein "Binning". Da werden dann die kleineren einfach heruntergefuset und so verkauft. Sowie ein genügend großer Kunde in nennenswerten Stückzahlen nach den kleineren fragt, kann man ihn dann immer noch als separates Produkt rausbringen. > Wenn sowas gemacht wird ist die Abschaltung von Speicherbereichen > ja auch schon im Design vorgesehen, d.h. die Abschaltung ist in der > Schaltung irgendwie berücksichtigt. Richtig. > Damit sollte es dann auch keine > Wechselwirkungen mit dem defekten Teil geben. Sagen wir mal so: es ist natürlich möglich, dass im nicht getesteten Teil was defekt ist. Einfach, weil es eben keiner getestet hat (und aufgrund der kürzeren Testzeit sind die Bauteile damit ja sogar wirklich billiger). Aber was nicht gemacht wird ist, dass man nun einen Die für einen ATtiny85 hat, aus dem man dann einen ATtiny45/1 oder einen ATtiny45/2 machen kann, je nach dem Ergebnis des Flash-Tests. Wenn man das macht, dann ist der ATtiny45 eben einer, bei dem die komplette obere Hälfte des Flash brach liegt, logisch abgeklemmt, aber auch nie erst getestet worden ist. Die Ausbeuten der heutigen IC-Prozesse sind gut genug. > Und die Gründe für einzelne Ausfälle analysiert heutzutage eh niemand. Unterschiedlich. Wenn man sich keinen Reim drauf machen kann, wird zuweilen schon ganz schön Aufwand getrieben. Man will ja künftige Fehler vermeiden.
MarcVonWindscooting schrieb: snip > Ich kann mich noch an einen Robert Teufel > erinnern, vor ein paar Jahren, der immer von den LPCs geschw"armt hat. > Das hat aber offensichtlich nicht gefruchtet. Ich nehme das mal als Kompliment und denke es hat schon etwas gefruchtet, wenn auch nicht im gewuenschten Ausmass. Nach STM32 ist der LPC wahrscheinlich der zweitmeist genannt ARM Cortex hier im Forum. (Nicht nachgezaehlt, nur mein Eindruck) - snip Die Forumteilnehmer zu beleidigen ist wenig hilfreich fuer deinen Zweck :( > Ist das hier eine LPC-freie Zone? Sind die so unattraktiv? > > Steckbrett: > Schon mal 'nen LPC810FN8 (DIP8) angeschaut? Nein? > Einen LPC1114FN28 (DIP28) eines Blickes gew"urdigt? Nein? > > Oder vielleicht f"ur die 'modernen' unter euch: LPC812JD20 (20-SOIC-W), > LPC1110FD20 (20-SOIC-W), LPC1112FD20 (20-SOIC-W), die kann 'man' schon > noch ohne Probleme l"oten, wenn man was anderes als 'nen 80W > Schweisskolben aus dem Baumarkt hat. Auch nicht? > > Brauchen zuviel Strom im aktiv-Modus z.B. 2mA@12MHz. Vermutlich. Und im > (Nicht:Deep-) Power-Down sowieso (z.B. 3uA mit Ausgangsregistern aktiv, > self-wakeup-timer laufend, 4 wakeup-pins aktiv). Und die 1.8V..3.6V sind > auch so ungeschickt, wenn man nicht z.B. die ultra-low-level NXP > PMVxxUP/UN MOSFET am Ausgang verwendet (z.B. PMV30UN, wenn's mal wieder > etwas mehr Strom sein muss), sondern seine MOSFET-Restposten aus den > 90er Jahren verbrauchen will (BUZ...). Und die Pins dieser Micros sind > ja auch nicht Arme, sondern eher nur D"aumchen (Thumb2?) mit nicht mal > 10mA, aber allerh"ochstens mal 20mA - l"acherlich f"ur jeden > Bastler-Mindestanforderungskatalog. Dann wohl tats"achlich besser Finger > weglassen, von dem neumodischen Kram. > Als ich noch bei NXP war, wurden die PLCC Varianten immer wieder rausgeschoben, die DIP (TSSOP) Varianten sind recht neu und es dauert hier im Forum SEHR LANGE bis neue Chips es in die Diskussionsrunden schaffen. Ein anderes Beispiel waere der XMEGA, eine klare Verbesserung gegenueber dem urspruenglichen AVR aber anfagns sehr fehlerbehaftet und zu einer Zeit auf den Markt gekommen als Umsteiger auf dem Weg Richtung 32-bit waren. Die LPCs bieten vieles fuers Geld aber auch andere Muetter haben schoene Toechter. ST war einfach schneller am Markt mit dem STM32. NXP blieb zu lange auf dem ARM7 als Core stehen. Beitraege liefern und auch Fragen stellen zu den LPCs und vielleicht geschieht ein Wunder. :) Have fun, Robert
> die DIP (TSSOP) Varianten sind recht neu und es dauert > hier im Forum SEHR LANGE bis neue Chips es in die Diskussionsrunden > schaffen. Nur wenn sie bereits verfügbar sind. Angekündigte Chips werden dagegen in den höchsten Tönen gelobt und sehnlichst erwartet ;).
Jörg Wunsch schrieb: > Aber was nicht gemacht wird ist, dass man nun einen Die für einen > ATtiny85 hat, aus dem man dann einen ATtiny45/1 oder einen ATtiny45/2 > machen kann, je nach dem Ergebnis des Flash-Tests. Wenn man das > macht, dann ist der ATtiny45 eben einer, bei dem die komplette obere > Hälfte des Flash brach liegt, logisch abgeklemmt, aber auch nie erst > getestet worden ist. > > Die Ausbeuten der heutigen IC-Prozesse sind gut genug. Darf ich dann auch fragen, woher diese, absolute und referenzlose, Aussage kommt? Mir scheint dass in dem Fall eher die Margen der Microcontroller-Hersteller noch zu hoch sind. Wenn man sich die Preise der AVRs anschaut, könnte man so etwas bei Atmel vermuten.
:
Bearbeitet durch User
Gerade habe ich mal bei Mouser geschaut, was ein LPC800 kostet: <1 Euro Das ist schon mal gar nicht schlecht. Was nehmt Ihr als Spannungsregler? Bis jetzt habe ich variable LM317 verwendet, weil die viel billiger sind als andere. Allerdings stört mich die Bestückung des Widerstandsteilers.
chris_ schrieb: > Gerade habe ich mal bei Mouser geschaut, was ein LPC800 kostet: <1 > Euro > Das ist schon mal gar nicht schlecht. > Was nehmt Ihr als Spannungsregler? Bis jetzt habe ich variable LM317 > verwendet, weil die viel billiger sind als andere. Allerdings stört mich > die Bestückung des Widerstandsteilers. 1117-3.3 gibt es für cents.
:
Bearbeitet durch User
chris_ schrieb: > Bei Mouser kostet der 1,70€. Hast Du eine Quelle? http://www.aliexpress.com/wholesale?SearchText=1117-3.3&catId=0&initiative_id=SB_20140116005134 Und wenn man nicht die Version von TI nimmt, ist auch Mouser günstiger: http://de.mouser.com/Semiconductors/Power-Management-ICs/LDO-Voltage-Regulators/_/N-5cgac?P=1z0wa2e&Keyword=1117&FS=True&Ns=Pricing|0
:
Bearbeitet durch User
Bei den 3,3V Spannungsregler-IC's muss man ein wenig aufpassen, viele haben nur einen Eingangsspannungsbereich bis 7 oder 10V! auch der 2117-3.3 ist Pinkompatibel. Wenn man bei 3,3V etwas mehr Strom benötigt und das ganze an USB angeschlossen wird, so kann es sich auch lohnen einen Step-Down Wandler zu nehmen. LM2675-3.3 wäre so einer und braucht wenige Teile.
Hier ein Tipp zum LPC810: Die einfachste Art den LPC810 zu programmieren ist über den eingebauen seriellen Bootloader. Dazu muss der Controller lediglich mit einem billigen USB-RS232 Adapter mit dem Computer verbunden werden. Die meisten dieser Adapter haben auch einen 3.3V Ausgang, der zum Betrieb des LPC810 genutzt werden kann. Der CP2102 hat z.B. einen internen Spannungsregler, der bis 100mA belastbar ist. z.B. hier für 1.50 EUR: http://www.ebay.de/itm/400524497015 oder CP2104 Von den PL2xxx. würde ich die Finger lassen. Eine Anleitung gibt es bei Adafruit. Den Spannungsregler kann man, wie gesagt, weglassen. http://learn.adafruit.com/getting-started-with-the-lpc810/programming-the-lpc810-with-flash-magic Hier gibt es auch schon ein Python-Script zum flashen der LPC800 Beitrag "Python Script: LPC810 flashen"
:
Bearbeitet durch User
Bei Farnell gibt es Festspannungsregler mit 3,3V Stückweise ab ca. 10ct und LDO ab ca. 13ct. 2500-er Preise ab ca. 6ct. Bei Reichelt kostet der 1117 29ct
chris_ schrieb: > Gerade habe ich mal bei Mouser geschaut, was ein LPC800 kostet: <1 Euro > Das ist schon mal gar nicht schlecht. > Was nehmt Ihr als Spannungsregler? Bis jetzt habe ich variable LM317 > verwendet, weil die viel billiger sind als andere. Allerdings stört mich > die Bestückung des Widerstandsteilers. LP2950 ist ein guter LDO für 3.3 Volt. Gibts aber nur als TO-92 oder SOIC8. Dann gibts noch TS5204 im SOT23. Ebenso der RT9058 auch im SOT23. Alle bis 30 Volt Eingangsspannung. gruß cyblord
Vielen Dank für die vielen Hinweise. Das hilft mir weiter. >LP2950 ist ein guter LDO für 3.3 Volt. Gibts aber nur als TO-92 oder >SOIC8. Den habe ich schon mal verwendet. TO92 ist ziemlich groß für kleine Platinen. Wenn ich mich recht erinnere, ist der ein wenig empfindlich, wenn die Glättungskondensatoren nicht stimmen.
Der 1117 hätte den Vorteil, dass der eine Übertemperatur sowie Überstrom Schutzbeschaltung drin hat. Ist vielleicht besser zum Experimentieren. Andere haben das auch, muss man lesen im Datenblatt.
chris_ schrieb: > Wenn ich mich recht erinnere, ist der ein wenig empfindlich, > wenn die Glättungskondensatoren nicht stimmen. Das gilt für alle LDOs. Entweder 78xx oder aufpassen.
MarcVonWindscooting schrieb: > Hier im Forum k"onnen anscheinend nur PICs, AVRs, 8051, MSP430 und im > Ausnahmefall ein STM32 wurzeln und vor sich hindursten. So verdorrt und > ausgelaugt ist hier der Boden. Und was darauf vor sich hin darbt, das ...... Nicht jammern, einfach mal selbst anfangen und nicht warten, bis andere was machen. Andererseits, wieso sollte man sich was neues antun, wenn man mit den PICs, AVRs, 8051, MSP430... fast alles erschlagen kann. Schön, dass es Cortex gibt, na und????
Ich hab in einer aktuellen Platine einen STLQ015XG33 (3.3V) verbaut. Deshalb: Iq < 1.5uA. Dann kann man auch low power modes verwenden, wenn die Versorgung "uber 3.3V ist. Kennt jemand einen besseren? Geht noch weniger? Wer weiss was?
Kann ich einen LPC mit meinem ST-Link/V2 flashen und debuggen? Die JTAG- und SWD-Schnittstelle soll bei allen Cortex-M ja gleich sein. Aber geht es praktisch?
chris_ schrieb: > Wenn ich mich recht erinnere, ist der ein wenig empfindlich, > wenn die Glättungskondensatoren nicht stimmen. Das ist Blödsinn. Er benötigt zwingend einen Kondensator am Ausgang. Man nimmt einfach einen gängigen Kerko dafür. Es ist im Datenblatt ein Minimum dafür angegeben, welches bei 1-2µF liegt. Dann steht da noch "can be increased without limit", also größer geht immer. Natürlich sollte der ESR nicht extrem hoch sein, aber bei welchem Kerko ist das schon so.
Walter Tarpan schrieb: > Kann ich einen LPC mit meinem ST-Link/V2 flashen und debuggen? Die JTAG- > und SWD-Schnittstelle soll bei allen Cortex-M ja gleich sein. Aber geht > es praktisch? Bei einem ST-LINK/V2 soll es einen Open-Source Crack geben, damit kann man dann auch andere µC außer ST flashen. Ob das tut weiß ich nicht, wenn man das tut gibt es kein zurück mehr. Hingegen der Segger J-LINK kann alle Cortex-Mx Prozessoren.
Danke für die Info. Markus Müller schrieb: > Hingegen der Segger J-LINK kann alle Cortex-Mx Prozessoren. Zu spät :-). Bin mit dem ST-Link voll zufrieden. Wobei mit "Vendor-lock-in" ein weiterer Punkt für den Verbreitungsgrad einzelner MCUs genannt wäre.
Nun ja, der LPC-Link kann von Haus aus auch nur die LPC's - dafür bieten die µC Hersteller alle samt recht günstige* Debugging Tools (*)außer einer
cyblord ---- schrieb: > Das ist Blödsinn. Er benötigt zwingend einen Kondensator am Ausgang. Man > nimmt einfach einen gängigen Kerko dafür. Es ist wie bei anderen LDOs auch. Elko ist einfacher, weil Mindest-ESR. "A ceramic output capacitor can be used if a series resistance is added (recommended value of resistance about 0.1Ω to 2Ω) to simulate the needed ESR."
:
Bearbeitet durch User
MarcVonWindscooting schrieb: > Hier im Forum k"onnen anscheinend nur PICs, AVRs, 8051, MSP430 und im > Ausnahmefall ein STM32 wurzeln und vor sich hindursten. Hauptsächlich AVR. Wenn es für die ARMs einen Peter Dannegger, K.-H.-Kübeler, Spess53 und andere gäbe, sähe die Welt sicher anders aus. Leider fehlt bei deinen vermissten µC dieser erstklassige Support. Schau doch mal rein. Die ARM sind für den Einstieg eben "komplizierter", weil viel Umfangreicher. Hilfe dafür gibt es fast keine.
Ich schrieb: > Leider fehlt bei deinen vermissten µC dieser erstklassige Support. Schau > doch mal rein. > Die ARM sind für den Einstieg eben "komplizierter", weil viel > Umfangreicher. Was ist jetzt bei einem LPC800 so viel komplizierter? Weil die 3 statt 1 UART haben? Oder weil das Datasheet unglaublich viele 74 Seiten hat?
Ich schrieb: > Hilfe dafür gibt es fast keine. Gibt es schon ausreichend wenn man etwas Englisch beherrscht. Viele Universitäten in EU und USA sowie Südamerika sind in diesem Bereich aktiv, bieten jede Menge Informationen und Hilfestellung. Hier ein einfacher Einstiegspunkt in der Schweiz: (Vom BLOG-Titel nicht täuschen lassen; es geht fast ausschließlich um kleinere ARM Cortex Cores) www.mcuoneclipse.com
Tim schrieb: > Darf ich dann auch fragen, woher diese, absolute und referenzlose, > Aussage kommt? Fragen darfst du. Antworten darf ich nicht. ;-) > Mir scheint dass in dem Fall eher die Margen der > Microcontroller-Hersteller noch zu hoch sind. Ah ja. Klar, die Betriebswirschaftler bei den IC-Herstellern sind alle auf der Wurschtbrühe hergeschwommen, oder wie meinst du das? Die Kosten entstehen keineswegs allein durch die Chifläche. Maskensatzkosten wurden ja schon genannt (sind nicht unerheblich), Kosten für den Fertigungstest machen einen großen Anteil an den laufenden Kosten (und skalieren, wenn ein größeres Bauteil als kleineres verkauft wird, d. h. das Bauteil wird davon in der Tat billiger). Schließlich kommen noch Kosten für die Qualifizierung (Lebensdauertests) der Bauteile hinzu: jedes Produkt mit einem neuen Maskensatz muss diese neu durchlaufen. Ist also alles in allem immer eine Abwägung, die auch ganz stark davon beeinflusst wird, wie die Kundennachfrage dann tatsächlich ist. > Wenn man sich die Preise > der AVRs anschaut, könnte man so etwas bei Atmel vermuten. Soso. Arbeiten STM und NXP denn gern ohne Marge? Aber mal Butter bei die Fische. Auf zu Mouser, weil das oben schon mal als Referenz genannt worden ist. Mal einen ATxmega256A3U als Beispiel für einen aktuellen AVR (256 KiB Flash, 16 KiB SRAM). Kostet bei Abnahme von 100 Stück reichlich EUR 3,23 Jetzt bei NXP über die parametrische Suche einen mit vergleichbaren Daten gesucht (einfach mal auf die 256 KiB beschränkt und Cortex-M3). Der billigste (LPC1763FBD100) ist für EUR 4,02 (bei 250 Stück) zu haben. Ja, der hat mehr SRAM (da machen sich die kleineren Strukturen bezahlt), aber die Größenordnung der Marge dürfte sich da mit dem Xmega wohl nicht viel nehmen. (Die SAM3 von Atmel kommen ziemlich in der gleichen Größenordnung wie die Cortex-M3 von NXP raus, bei 256/64 KiB ist man dort auch mit 4 Euro dabei.)
Markus Müller schrieb: > Was ist jetzt bei einem LPC800 so viel komplizierter? Weil die 3 statt 1 > UART haben? Oder weil das Datasheet unglaublich viele 74 Seiten hat? Naja, die Switch Matrix, SCT usw. sind schon komplexer als die typische Peripherie eines ATMega/ATTiny. Aber auch deutlich leistungsfähiger und flexibler! Der Verweis auf den Datasheet ist aber blödsinnig, da stehen keine Details drin. Das Manual, welches die Peripherie beschreibt, hat ca. 350 Seiten. Ich glaube ich werde mir auch mal ein paar LPC812 bestellen.
Markus Müller schrieb: > Was ist jetzt bei einem LPC800 so viel komplizierter? Weil die 3 statt 1 > UART haben? Oder weil das Datasheet unglaublich viele 74 Seiten hat? Eher weil da noch mit 349 Seiten des User Manuals hinzu kommen. Was aber auch nicht so arg viel ist.
Hi >Oder weil das Datasheet unglaublich viele 74 Seiten hat? Ach, die 349 Seiten vom LPC800 User manual unterschlägst du geflissentlich. Da weiß man ja, was von deinen Aussagen zu halten hat. MfG Spess
Reiner Geiger schrieb: > Gibt es schon ausreichend wenn man etwas Englisch beherrscht. > Viele Universitäten in EU und USA sowie Südamerika sind in diesem > Bereich aktiv, bieten jede Menge Informationen und Hilfestellung. Was nützt mir das? Zum AVR-Problem stellt man hier seine Frage, und wenn die nicht gar zu blöd ist, hat man hier 5 Min später eine qualifizierte Antwort. Als Nicht-Profi kann ich also vertrauen, dass ich hier echte Hilfe bekomme. Und wenn´s der Tritt in den Allerwertesten ist, kann auch helfen. Wer die LPC, ARM etc aus dem FF beherrscht, lächelt da natürlich drüber. greg schrieb: > Naja, die Switch Matrix, SCT usw. sind schon komplexer als die typische > Peripherie eines ATMega/ATTiny. Zum Beispiel. Was das ist, wie die zu nutzen sind, Beispiele in C und ASM dafür, erlernbare Anwendungen...???? Nichts! Dafür soll ich mir aber irgend ein Geschreibsel einer Universität reinziehen? Hilft mir nicht weiter. Pädagogisch wertlos.
@ spess53 (Gast) >>Oder weil das Datasheet unglaublich viele 74 Seiten hat? >Ach, die 349 Seiten vom LPC800 User manual unterschlägst du >geflissentlich. Da weiß man ja, was von deinen Aussagen zu halten hat. ;-) Das böse Wort mit P********a.
spess53 schrieb: > Ach, die 349 Seiten vom LPC800 User manual unterschlägst du > geflissentlich. Da weiß man ja, was von deinen Aussagen zu halten hat. > > MfG Spess Meine Güte nochmal ... auch ein ATMega128 hat eine User Manual mit 386 Seiten. Wo ist das Problem? Umgekehrt würde ein Schuh draus. Seid doch froh dass es die Doku umsonst gibt.
Ich schrieb: > Die ARM sind für den Einstieg eben "komplizierter", weil viel > Umfangreicher. Hilfe dafür gibt es fast keine. Tutorial für LPC13xx und LPC11xx (gleiche Peripherie mit M3 oder M0): http://www.microbuilder.eu/Projects/LPC1343ReferenceDesign/GettingStartedLPC1343.aspx Tutorial für LPC8xx: http://learn.adafruit.com/getting-started-with-the-lpc810/introduction greg schrieb: > Naja, die Switch Matrix, SCT usw. sind schon komplexer als die typische > Peripherie eines ATMega/ATTiny. Mal ganz ohne Libraries und Vorkenntnisse Blinky für den LPC810 - im Manual-PDF Suche nach Pin-Direction und Pin-Register: #define DIR0 0xA0002000 #define PIN0 0xA0002100 void main(void) { // P0_4 set to output *((unsigned long *) DIR0) |= 1<<(4); while (1) { // P0_4 toggle *((unsigned long *) PIN0) ^= 1<<(4); delay(500000); } } void delay(volatile unsigned long cycles) { while (cycles) {cycles--;} }
Alle moderne* Prozessoren verfügen über eine Busmatrix. Nicht nur der LPC800, auch beispielsweise der PIC24 und STM32F4xx. Manche mehr und manche weniger Flexibel. Man ist somit vom HW-Design viel entspannter wenn man weiß dass eine HW-Funktion an mehreren Stellen herausgeführt sind. Somit kann man z.B. den UART Pin auch als Timer Pin verwenden und relativ leicht die Baudrate messen. (*) Die AVR Technologie kommt bereits aus der Steinzeit, vor 15 Jahren und ist heute nicht mehr das Maß der Dinge. Viel zu teuer für die schwache Leistung. (Wobei es natürlich auch Applikationen gibt, bei denen die Leistung ausreicht und aus dem Grund werden 8-Bitter nicht so schnell ausgerottet sein. Oder ist es eher Nostalgie?)
Ich schrieb: > Dafür soll ich mir aber irgend ein Geschreibsel einer Universität > reinziehen? > Hilft mir nicht weiter. > Pädagogisch wertlos. Na ja, war schon immer so: wer lesen kann ist im Vorteil. Und auch in den ARM Foren bekommt man vernünftige Antworten.
Lothar schrieb: > Mal ganz ohne Libraries und Vorkenntnisse Blinky für den LPC810 - im > Manual-PDF Suche nach Pin-Direction und Pin-Register: @Lothar Danke das Du dir die Mühe gemacht hast!. Hatte ich doch glatt recht, wer lesen kann ist doch im Vorteil ;-)
Lothar schrieb: > Mal ganz ohne Libraries und Vorkenntnisse Blinky für den LPC810 - im > Manual-PDF Suche nach Pin-Direction und Pin-Register: IOCON-Clock wird nicht aktiviert? Da blinkt dann doch nix? :)
Reiner Geiger schrieb: > Na ja, war schon immer so: wer lesen kann ist im Vorteil. Lothar schrieb: > Tutorial für LPC13xx und LPC11xx (gleiche Peripherie mit M3 oder M0): > > http://www.microbuilder.eu/Projects/LPC1343ReferenceDesign/GettingStartedLPC1343.aspx > > Tutorial für LPC8xx: > > http://learn.adafruit.com/getting-started-with-the-lpc810/introduction Wertlos. Da zeigt jemand, wie man die IDE installiert und eine LED mit Waitms() blinken lässt. Toll. Das 98987544. Blinky. Ich mag das AVR Tutorium hier im Forum. Jede Funktionseinheit samt der zugehörigen Register des AVR wird darin für einen Einsteiger verständlich erläutert. Und genau das fehlt für die ARM M0-M4 Kerne. Liebe Profis: Ihr versteht sicherlich die "Tutorien", die ihr hier verlinkt. Ich kann davon nichts lernen, ich will den GRUNDAUFBAU kennen lernen, nicht eine LED blinken lassen!
Reiner Geiger schrieb: > Und auch in den ARM Foren bekommt man vernünftige Antworten. Es ging um dieses Forum. Nicht um irgend ein ARM Forum.
Markus Müller schrieb: > Man ist somit vom HW-Design viel entspannter wenn man weiß dass eine > HW-Funktion an mehreren Stellen herausgeführt sind. > Somit kann man z.B. den UART Pin auch als Timer Pin verwenden und > relativ leicht die Baudrate messen. Du magst ja Recht haben, und mit läuft das Wasser im Mund zusammen, wenn ich das lese. ES gibt aber keine einfachen und motivierenden Einstieg in diese Technologie. Alles ist total verstreut, meist Englisch, bruchstückhaft, unverständlich, ohne Zusammenhang, nicht pädagogisch aufgearbeitet.
Was ist an diesem Script der Vorteil zu lpc21isp? Das ist ein etabliertes Tool für diesen Zweck.
Ich schrieb: > ES gibt aber keine einfachen und motivierenden Einstieg in diese > Technologie. Genau, es gibt den "einfachen" Einstieg nicht, weil es keine "einfache" Technik ist; da muss man sich schon mit beschäftigen wollen oder eventuell auch müssen ;-) Aber warum willst Du dich mit etwas beschäftigen was Du nicht benötigst. Niemand muss ARM Prozessoren einsetzen. Solange Du alle Aufgaben mit 8-Bit Prozessoren erledigen kannst und dabei genügend Hilfe erhälst ist doch alles in Ordnung. Und das funktioniert hier im Forum ja wirklich bestens! > Alles ist total verstreut, meist Englisch, bruchstückhaft, > unverständlich, ohne Zusammenhang, nicht pädagogisch aufgearbeitet. Ist aber doch nicht das Problem der Prozessoren; ist halt noch keiner auf die Idee gekommen das mal hier im Forum anzugehen. Kostet halt jede Menge Zeit und Energie. Mit ISBN-Nummer kann man das aber alles schon haben.
Reiner Geiger schrieb: > Ist aber doch nicht das Problem der Prozessoren; ist halt noch keiner > auf die Idee gekommen das mal hier im Forum anzugehen. Kostet halt jede > Menge Zeit und Energie. Mit ISBN-Nummer kann man das aber alles schon > haben. Nun, die Eingangsfrage war, warum niemand den LPC800 einsetzt. Und darauf gabs hier eine Antwort.
greg schrieb: > IOCON-Clock wird nicht aktiviert? Da blinkt dann doch nix? :) Lustigerweise braucht es diese Clock nur, wenn man mit den Pins etwas anderes machen möchte als die Default-Funktion, also z.B. Pin auf 2. Funktion umschalten oder Pin als Interrupt nutzen.
Lothar schrieb: > greg schrieb: >> IOCON-Clock wird nicht aktiviert? Da blinkt dann doch nix? :) > > Lustigerweise braucht es diese Clock nur, wenn man mit den Pins etwas > anderes machen möchte als die Default-Funktion, also z.B. Pin auf 2. > Funktion umschalten oder Pin als Interrupt nutzen. Hab mich da auch vertan. Ich meinte den GPIO-Clock. Im Manual steht jedenfalls man muss den aktivieren. Ist der nach dem Booten schon aktiv?
Ich schrieb: > Wertlos. Da zeigt jemand, wie man die IDE installiert und eine LED mit > Waitms() blinken lässt. Toll. Vielleicht mal umblättern! Nur mal als Beispiel: man weiss schon was PWM ist, aber nicht wie es mit LPC geht. Dann ein Blick ins Tutorial: http://www.microbuilder.eu/Projects/LPC1343ReferenceDesign/LPC1343_LPC1114_PWM.aspx Natürlich kann man jetzt noch anmerken, er hätte erwähnen sollen, warum er die Match Register 0 und 3 nimmt (nämlich weil 3 keinen rausgeführten Pin hat, und daher für die Periode genommen werden soll). Ich schrieb: > Ich mag das AVR Tutorium hier im Forum. Jede Funktionseinheit samt der > zugehörigen Register des AVR wird darin für einen Einsteiger > verständlich erläutert. Das möchte ich doch bezweifeln. Es geht los mit einem unmotivierten Assembler-Programm. Wieso überhaupt mit Assembler anfangen? Und hätte man nicht erst mal die Befehle und Register erklären müssen? Dann die Ausführungen zum Stack, braucht man nicht unbedingt zu wissen (übrigens stackt der Cortex-M automatisch).
Lothar schrieb: > (übrigens stackt der Cortex-M automatisch). Stack? Was ist das? g Um den musste ich mich beim Cortex-Mx noch nie kümmern. Mach alles der C-Compiler und µC, ganz von alleine.
Markus Müller schrieb: > Lothar schrieb: >> (übrigens stackt der Cortex-M automatisch). > > Stack? Was ist das? g > Um den musste ich mich beim Cortex-Mx noch nie kümmern. Mach alles der > C-Compiler und µC, ganz von alleine. Den richtigen Startup-Code brauchst du auf jeden Fall, das macht der Compiler nicht für dich.
Lothar schrieb: > Das möchte ich doch bezweifeln. Es geht los mit einem unmotivierten > Assembler-Programm. Wieso überhaupt mit Assembler anfangen? Und hätte > man nicht erst mal die Befehle und Register erklären müssen? Weil ASM auf dem AVR einfach g*il ist. Ich habe vor gut 20 Jahren Z80 Assembler gelernt. Dann den Beruf gewechselt. Mit Hilfe des Tutoriums ist es mir gelungen, innerhalb weniger Wochen den AVR zu begreifen und alles was ich will in Assembler zu programmieren. Ich brauche kein C dafür, wenn es auch einfach geht. Nun möchte ich schon gern die einfachen ARM kennen lernen, aber nicht in C. Problem: macht kaum einer. Lösung: Entweder C lernen oder bei AVR bleiben und auf Xmega erweitern.
Lösung:Assembler für ARM lernen. USB, SD-Card oder Ethernet machen wohl nicht wirklich spass die in Assembler zu proggen - auch nicht beim AVR.
Hier gibt es ein Beispiel für ASM auf LPC800: http://www.windscooting.com/softy/ramloader.html Aber Vorsicht: Laut Webseite "WARNING: The author is NOT your friendly neighbour. He has harsh opinions and these opinions may be expressed here or in the program's output." Was immer das zu bedeuten hat...
Ich schrieb: > Weil ASM auf dem AVR einfach g*il ist. Ich habe vor gut 20 Jahren Z80 Assembler gelernt. Und ich hab 1989 Assembler auf dem ARM2 gelernt :-) Also vor 25 Jahren und auf dem Acorn Archimedes :-) Und von wegen geil, hier (wieder mal) der größte gemeinsame Teiler in ARM (ist in Assembler einfacher): int gcd (int a, int b) { while (a != b) { if (a > b) a = a - b; else b = b - a; } return a; } gcd CMPS R0, R1 SUBGT R0, R0, R1 ; greater than > SUBLE R1, R1, R0 ; less or equal <= BNE gcd ; not equal
Lothar schrieb: > CMPS R0, R1 > SUBGT R0, R0, R1 ; greater than > > SUBLE R1, R1, R0 ; less or equal <= > BNE gcd ; not equal Tja, das gilt aber nicht für die Thumb-Befehle.
Tim schrieb: > Tja, das gilt aber nicht für die Thumb-Befehle. Es ging ja nur ums ARM Assembler lernen. Der M3 Assembler fügt einen fehlenden ITE automatisch ein. Beim M0 sollte man Assembler vielleicht doch bleiben lassen, zu sehr "optimiert".
@ greg (Gast) >> Um den musste ich mich beim Cortex-Mx noch nie kümmern. Mach alles der >> C-Compiler und µC, ganz von alleine. >Den richtigen Startup-Code brauchst du auf jeden Fall, das macht der >Compiler nicht für dich. Du hast noch nie C programmiert. Na logisch kümmert sich der Compiler / die IDE um den Startup Code. Wer den per Hand beackert ist selber Schuld. 99% aller Anwendungen brauchen NICHT in den Internas von Compiler und IDE rumoperieren. Gott sei Dank.
Falk Brunner schrieb: > Wer den per Hand beackert ist selber > Schuld. 99% aller Anwendungen brauchen NICHT in den Internas von > Compiler und IDE rumoperieren. Gott sei Dank. Außer man benutzt GCC und ARM :-/ der liefert nämlich keine Linkerscripte & Startupcode für 1000000 verschiedene Mikrocontroller mit...
Apropos: gibt es irgendwo ein Beispiel für "Blinky" from Sratch für den LPC800, also ohne große Lib wie z.B. CMCIS? Register direkte einstellen etc.
Franz schrieb: > Apropos: gibt es irgendwo ein Beispiel für "Blinky" from Sratch für den > LPC800, also ohne große Lib wie z.B. CMCIS? > Register direkte einstellen etc. Beitrag "Re: LPC800 existiert (fast) nicht in diesem Forum" Ja, ein paar posts weiter oben. Dieser Thread offenbart mal wieder die Probleme mit diesem Forum und vielen Postings. Etliche Dinge sind in diesem Thread mehrmals geposted worden.
Mannomann, der Thread "uberfordert mich langsam. @mmvisual: Danke f"ur den Tip mit dem MCP1702 - der hat einen viel gr"osseren Eingangsspannungsbereich :) greg schrieb: > IOCON-Clock wird nicht aktiviert? Da blinkt dann doch nix? :) Gut aufgepasst! ;-) es geht ohne IOCON-clock, aber nicht ohne die GPIO-clock (die ist aus nach dem Reset). Ganz schw"ammig will ich mal behaupten, das NXP versucht die RESET-Defaults sinnvoll zu setzten. Auf den gr"osseren MCUs ist viel nach dem RESET 'viel' Peripherie an, w"ahrend bei dem Stromsparern fast alles aus ist. Das macht ein Blinky auf einem LPC17 einfacher als auch dem 'Einsteiger-' LPC800 / LPC1100. > sicherlich die "Tutorien", die ihr hier verlinkt. Ich kann davon nichts > lernen, ich will den GRUNDAUFBAU kennen lernen, nicht eine LED blinken > lassen! Was meinst Du mit Grundaufbau? Es gibt die Werkzeuge: Compiler, Assembler, Linker, Bibliothekswerkzeuge (=> info gcc as ld / ar). Es gibt das Zusammenspiel der Werkzeuge: Makefile oder "ahnliches. (=> info make). Es gibt die ARM-Cortex-M0 Architektur: Speicher, Exceptions, Befehlssatz, Stack(s) (=> "The Definitive Guide to the Cortex-M0, dto. f"ur Cortex-M3, ARM Architecture Reference Manual= 'ARM ARM' ). Es gibt Aufrufkonventionen 'AEABI': (=> AAPCS), ... Es gibt die Peripherieeinheiten (=> LPC800 user manual). Es gibt x M"oglichkeiten die Peripherieeinheiten in 'C' abzubilden. CMSIS, und andere, wobei ich CMSIS plump finde und nicht nutze. Es gibt Benutzerpr"aferenzen/Hardwareanforderungen und die muss man in Linker-Scripts und Startup-Code abbilden. y M"oglichkeiten. Es gibt die M"oglichkeit Bibliotheken zu bauen und zu verwenden, aber lassen wir das mal vorerst weg. Ich sch"atze Du meinst nicht die 15 Zeilen Code in der main.c mit Grundaufbau, richtig? DIE 15 Zeilen, von denen IDE-Benutzer oftmals glauben, dass sie DAS PROGRAMM AN SICH ausmachen w"urden... (neben der Auswahl eines Bausteins LPC8xx in einem Projektsetting). Tsss. Ziemlich gut finde ich dieses hier (obwohl LPC17). Da ist sehr viel erkl"art: http://pygmy.utoh.org/riscy/cortex/led-lpc17xx.html (Falk): > Du hast noch nie C programmiert. Na logisch kümmert sich der Compiler / > die IDE um den Startup Code. > ... > Gott sei Dank. Wenn Du schon das Christentum ins Spiel bringst, dann ist Adam der Programmierer, und die IDE der Apfel... Wer hier im Forum die Schlange ist, das find ich auch noch raus...! Ich hab schon einen Verd"achtigen... ;-) (Kindergaertner): > Außer man benutzt GCC und ARM :-/ der liefert nämlich keine > Linkerscripte & Startupcode für 1000000 verschiedene Mikrocontroller > mit... und das ist auch gut so. Linker Scripts sind starker Tobak, aber die M"oglichkeiten sind gewaltig. Und der Startup-Code h"angt da eng mit zusammen. Momentan verwalte ich die Adressen der Peripherieeinheiten z.B. im Startup-Code. USART0, IOCON, GPIO, usw. das sind bei mir keine Makros, und keine Pointer, sondern (Struktur-) Variable. Das kann man so in 'C' nicht hinbekommen. Das ist f"ur ein minimales Blinky gut:
1 | *((unsigned long *) PIN0) ^= 1<<(4); |
Im sp"ateren Gebrauch will ich aber:
1 | GPIO.pin0 ^= 1<<4; |
Besser noch (atomar):
1 | GPIO.not0 = 1<<4; |
> Aber Vorsicht: Laut Webseite > "WARNING: The author is NOT your friendly neighbour. > ... > Was immer das zu bedeuten hat... Ein paar Beispiele: 1. dass der Autor Programme, z.T. ABSICHTLICH Programme so schreibt, dass sie nicht einfach auf ein Betriebssystem - nenne wir es einfach mal W - zu portieren sind. 2. dass der Autor in der Hilfestellung eines seiner Programme pr"aventiv schon mal einen potentiellen 'Helfer' beleidigt, der dem Programm eine GUI verpassen will. 3. dass der Autor es typischerweise nicht mehr als 2 mal duldet, wenn jemand Hilfe will und genau das tut wovon der Autor explizit abgeraten hat. Beim zweiten Male typischerweise in einer sehr unmissverst"andlichen Art und Weise. Beim dritten Male wird der Absender als SPAM markiert und seine Mails landen ungesehen in der Tonne. 4. dass der Autor auf das Wort IDE heftig mit der Aussch"uttung von Histamin und Adrenalin reagiert.
Marc P. schrieb: > Momentan verwalte ich die Adressen der Peripherieeinheiten > z.B. im Startup-Code. USART0, IOCON, GPIO, usw. das sind bei mir keine > Makros, und keine Pointer, sondern (Struktur-) Variable. Wie geht das denn?
Kindergärtner schrieb: > Marc P. schrieb: >> Momentan verwalte ich die Adressen der Peripherieeinheiten >> z.B. im Startup-Code. USART0, IOCON, GPIO, usw. das sind bei mir keine >> Makros, und keine Pointer, sondern (Struktur-) Variable. > Wie geht das denn? z.B. so:
1 | extern struct { |
2 | ...
|
3 | volatile Uint32 clr0; |
4 | ...
|
5 | } GPIO; |
6 | |
7 | void main(void) { |
8 | GPIO.clr0 = 1<<4; |
9 | }
|
Und GPIO ist in crt0 definiert durch #include lpc8Symbols.s aus der Anlage. GPIO ist nur eine Addresskonstante. Wenn nicht benutzt, dann braucht sie auch keinen Platz.
Marc P. schrieb: > Und GPIO ist in crt0 definiert durch #include lpc8Symbols.s aus der > Anlage. Mit anderen Worten du missbrauchst den Startup-Code um Linker-Symbole mit den entsprechenden Adressen in Assembler anzulegen? Okay, in Standard-C geht das nicht. Was aber geht ist:
1 | struct GPIO_Type { |
2 | ...
|
3 | volatile Uint32 clr0; |
4 | ...
|
5 | };
|
6 | volatile GPIO_Type* GPIO = (volatile GPIO_Type*) 0xA0000000; |
7 | |
8 | int main () { |
9 | GPIO->clr0 = 1<<4; |
10 | }
|
Braucht auch keinen extra Platz (Compiler-Optionen), braucht aber keine Assembler-Magic. Und man muss "->" statt "." schreiben. In C++ kann man "." haben:
1 | struct GPIO_Type { |
2 | ...
|
3 | volatile Uint32 clr0; |
4 | ...
|
5 | };
|
6 | volatile GPIO_Type& GPIO = *reinterpret_cast<volatile GPIO*>(0xA0000000); |
7 | |
8 | int main () { |
9 | GPIO.clr0 = 1<<4; |
10 | }
|
PS: Man sollte natürlich den Standard-Typ uint32_t verwenden.
Marc P. schrieb: > greg schrieb: >> IOCON-Clock wird nicht aktiviert? Da blinkt dann doch nix? :) > > Gut aufgepasst! ;-) > es geht ohne IOCON-clock, aber nicht ohne die GPIO-clock (die ist aus > nach dem Reset). Da das Programm ja blinkt hab es jetzt extra debugged mit: #define SYSAHBCLKCTRL 0x40048080 volatile unsigned long temp = *((unsigned long *) SYSAHBCLKCTRL); Ergebnis: 11011111 GPIO ist bit 6, Reset-Value ist also 1 und nicht 0 - Fehler im Manual Aber ich muss zugeben: ich arbeite ohne Manual und schaue nur rein, wenn was nicht geht :-)
C++ kann ich nicht ;-) '->' kann ich nicht, weil ich von Java verdorben bin. Wie bekommst Du den Platz von GPIO (4-byte, Pointer) mit Compiler-Optionen weg? Welche? Warum volatile, nicht const (woanders):
1 | GPIO_Type* const GPIO = (GPIO_Type*) 0xA0000000; |
Der Charme der asm-L"osung ist auch die einfache zentrale Verwaltung der Peripherieadressen und die hinterh"altige aber kurze Umgehung s"amtlicher Typecasts f"ur diese Adressen.
Marc P. schrieb: > C++ kann ich nicht ;-) > '->' kann ich nicht, weil ich von Java verdorben bin. Wenn du schon dank Java OOP beherrschst ist doch C++ naheliegend... > Wie bekommst Du den Platz von GPIO (4-byte, Pointer) mit > Compiler-Optionen weg? Welche? -O2 sollte reichen. Vermutlich sollte man die Adresse noch konstant & static machen:
1 | static volatile GPIO_Type* const GPIO = (volatile GPIO_Type*) 0xA0000000; |
Dann müsste die Variable komplett verschwinden. > Warum volatile, nicht const (woanders): > GPIO_Type* const GPIO = (GPIO_Type*) 0xA0000000; volatile wie immer damit der Compiler die Zugriffe nicht wegoptimiert. Das "const" hatte ich vergessen. > Der Charme der asm-L"osung ist auch die einfache zentrale Verwaltung der > Peripherieadressen und die hinterh"altige aber kurze Umgehung > s"amtlicher Typecasts f"ur diese Adressen. Naja mit C geht das auch zentral, einfach alles in eine Datei packen. Die asm-Lösung bedient sich aber bösartiger Linker-Magic und ist aus C-Sicht ziemlich undurchsichtig... Genausogut könntest du die Adressen im Linkerscript eingeben...
Lothar schrieb: > GPIO ist bit 6, Reset-Value ist also 1 und nicht 0 - Fehler im Manual Tats"achlich! Oh je, kann man sich nicht mal darauf verlassen... Willst Du das nicht im LPCWare-Forum melden - wir wollen doch korrekte Manuals?!
Marc P. schrieb: > Lothar schrieb: >> GPIO ist bit 6, Reset-Value ist also 1 und nicht 0 - Fehler im Manual > > Tats"achlich! Oh je, kann man sich nicht mal darauf verlassen... Völlig normal, die Errata zum Manual sind ja inzwischen schon 2 Seiten :-) Übrigens SWM ist bit 7, also auch Reset-Value 1 und nicht 0. Anderseits würde es ja keinen Sinn machen, dass man nach Reset keine I/Os und keine Switch-Matrix hat. Wenn ich eine Bibliotheksfunktion mache, setze ich aber immer alle benötigten Bits, egal was im Manual steht.
Lothar schrieb: > Anderseits > würde es ja keinen Sinn machen, dass man nach Reset keine I/Os und keine > Switch-Matrix hat. Das hätte etwas mit dem Stromverbrauch zu tun haben können. Nicht jeder braucht gleich zu Anfang alle Features. Derjenige der I/Os braucht, kann sie selbst aktivieren. Welchen uC benutzt du genau? Welche Revision? Bootloader-Version? Aber vielleicht Vorsicht: Hängst du mit JTAG drauf? Oder kommst du aus dem seriellen Bootloader? Da könnten die Bits anders sein, als wenn er Standalone bootet. Auch die Ausgabe ist entscheidend. Ich denke man müsste den Wert von SYSAHBCLKCTRL in einer Variablen speichern, dann die Ausgabe (z.B. seriellen Port) initialisieren und dort dann ausgeben.
Ingo P. schrieb: > Das hätte etwas mit dem Stromverbrauch zu tun haben können. > Nicht jeder braucht gleich zu Anfang alle Features. > Derjenige der I/Os braucht, kann sie selbst aktivieren. Die Default-Funktion der Pins braucht man wohl immer. Und die weiteren Pin-Funktionen und Interrupts sind ja abgeschaltet. > Welchen uC benutzt du genau? Welche Revision? Bootloader-Version? LPC810 neueste Revision 4C > Aber vielleicht Vorsicht: Hängst du mit JTAG drauf? > Oder kommst du aus dem seriellen Bootloader? > Da könnten die Bits anders sein, als wenn er Standalone bootet. Es blinkt auch beim Standalone-Start, also ist das GPIO Bit gesetzt. > Auch die Ausgabe ist entscheidend. Das Programm bindet ja keine Library ein, der Startup-Code definiert nichts als die Vektortabelle, und es wird nur direkt auf DIR0 und PIN0 zugegriffen. Übrigens z.B. LPCxpresso versteckt die Default-Initialisierung im Startup-Code, das muss man natürlich raus machen.
@ Lothar (Gast) >Übrigens z.B. LPCxpresso versteckt die Default-Initialisierung im >Startup-Code, das muss man natürlich raus machen. Sehr sinnvoll, in den Eingeweiden der IDE rumzumurksen.
Falk Brunner schrieb: > Sehr sinnvoll, in den Eingeweiden der IDE rumzumurksen. Bitte nachlesen, es ging um einen Test, ob beim uC Startup ein Bit defaultmäßig gesetzt ist oder nicht, und wenn nicht, wo das denn gesetzt wird. Kann der Normaluser gleich wieder vergessen.
Marc P. schrieb: >> Außer man benutzt GCC und ARM :-/ der liefert nämlich keine >> Linkerscripte & Startupcode für 1000000 verschiedene Mikrocontroller >> mit... > und das ist auch gut so. Linker Scripts sind starker Tobak, aber die > M"oglichkeiten sind gewaltig. Und der Startup-Code h"angt da eng mit > zusammen. AVR-GCC / avr-libc machen vor, dass man in 99,99 % der Fälle prima mit völlig allgemeingültigen Implementierungen dafür aufwarten und diese mit ausliefern kann. Mögliche Hooks für projektspezifische Anpassungen kann man ja trotzdem problemlos vorsehen. Es ist einfach hanebüchen, wie viele teilweise verbuggte Versionen von ARM-Linkerscripts so durch das Internet geistern, nur, weil Compiler und Bibliothek diese nicht von Haus aus mitbringen und sich jeder sein eigenes Süppchen kocht. Allerdings hätte sich dafür natürlich jemand den Hut aufsetzen müssen, am besten wäre wohl ARM selbst. Die Hersteller der einzelnen ARMs haben ja kein großes Interesse an einer Standardisierung, denn die sehen nur ihre eigene (aus ihrer Sicht perfekte) IDE und die Einbidung der Tools in diese; an einer herstellerübergreifenden Austauschbarkeit haben die doch rein gar kein Interesse. Das kann aber durchaus auch jemand ganz anderes als ARM tun. Beim AVR-GCC/avr-libc stand ja auch nicht Atmel selbst hinter der Entwicklung.
Jörg Wunsch schrieb: > AVR-GCC / avr-libc machen vor, dass man in 99,99 % der Fälle prima > mit völlig allgemeingültigen Implementierungen dafür aufwarten und Tja, vielleicht bin ich nicht repr"asentativ, das k"onnte ich mir gut vorstellen. Aber 99.99% sind's bei mir nicht mal ann"ahernd. Nur beim Schreiben von Programmen auf dem PC f"ur den PC brauch ich auch nie ein eigenes. Ich habe unterschiedliche Linkerscipts f"ur unterschiedliche uCs, Entwichlungsverianten (RAM-Ausf"uhrung) und Releasevarianten (FLASH), 'Viel' Stack und 'Wenig' Stack, C-Programme oder ASM-Programme, usw. ... Man KANN mit weniger auskommen, aber dann verlagert man ein paar Funktionalit"aten in den C-Code, z.B. misbr"auchliche Verwendung von __attribute__((section("xyz"))) um was woanders hinzuschummeln. Und woher das 99.99% LD-Script schon heute weiss, in welchem Adressbereich morgen der Hersteller X f"ur Chip Y einen Fetzen RAM f"ur die Peripherie Z legt w"urde ich gern wissen. Eben geschaut in meinen Umgebungen: LPC1700: 12 St"uck LPC2100: 8 St"uck LPC800: 4 St"uck
Marc P. schrieb: > Und woher das 99.99% LD-Script schon heute weiss, in welchem > Adressbereich morgen der Hersteller X f"ur Chip Y einen Fetzen RAM > f"ur die Peripherie Z legt w"urde ich gern wissen. Ich glaube Jörg meint, dass man einmalig für einen bestimmten MCU-Typ ein allgemein verwendbares Linkerscript und allgemeinen Startup-Code verfassen kann. Genau das macht avr-libc doch. Dann braucht nicht jeder das Rad immer wieder neu zu erfinden.
Marc P. schrieb: > einen Fetzen RAM f"ur die Peripherie Z legt w"urde ich gern wissen. Sowas steht doch normalerweise als feste Adresse im device header file drin. Das ist ja auch kein RAM, den der Linker dann verwalten muss.
greg schrieb: > Ich glaube Jörg meint, dass man einmalig für einen bestimmten MCU-Typ > ein allgemein verwendbares Linkerscript und allgemeinen Startup-Code > verfassen kann. Selbstverständlich kommen alle relevanten ARM IDEs (Eclipse/LPCxpresso, Keil, IAR) mit Linkerscripten und Startup-Codes für alle uC und die sind in 99% der Fälle anwendbar. Es gibt nur wenige Ausnahmen für den Profi z.B.: - Anschluss von externem RAM/Flash, muss natürlich ins Linkerscript - Library-Objekt von anderer IDE, dann müssen im Startup-Code die eventuell Handler-Namen geändert werden - Privileged-Aktionen (Software-Interrupts nutzen, Memory Protection, Fault Handler), dann muss der Startup-Code angepasst werden Dann gibt es noch die kleine Problematik, dass NXP es dem User bequem machen möchte. So macht der CMSIS-Library-Call System_Init() auf einem 100 MHz uC einfach 96 MHz, damit z.B. auch USB mit 48 MHz funktioniert. Wenn man da ran möchte, muss man tatsächlich selbst was machen, nämlich eine weitere PLL starten für 48 MHz und dann die Main-PLL auf 100 MHz. Wenn das daneben geht ist der uC aber nicht "verfused", der Bootloader startet immer noch mit dem internen Oszillator :-)
Lothar schrieb: > Selbstverständlich kommen alle relevanten ARM IDEs (Eclipse/LPCxpresso, > Keil, IAR) mit Linkerscripten und Startup-Codes für alle uC und die sind > in 99% der Fälle anwendbar. Naja, IDE != Compiler. Mit der avr-libc ist man nicht auf die Hilfe irgendeiner IDE angewiesen, und das ist auch gut so. Ich würde mich über ein umfangreiches Repository an Linkerscripten & co für den GCC freuen. Momentan muss man immer ein Linkerscript und Startup-Code mitliefern, wenn man sich nicht auf eine Entwicklungsumgebung festlegen möchte. Oder übersehe ich etwas?
Seh ich auch so. Die paar .x - files die beim gcc dabei sind, mit denen hab ich noch nie was angefangen. Die sind sooo kompliziert und in keinster Weise auf den Speicher eines uC eingestellt. Ich hab noch nie mit C++ f"ur den uC entwickelt, immer nur C, unter anderem weil ich mir's noch nie angetan habe genau zu schauen, wie ich den ganzen C++ Plunder (Konstruktoren, Destruktoren, ...) in der crt0 verwurstet bekomme. Anbei mal 'ein Vorschlag f"ur ein LD-Skript f"ur den LPC812, Ausf"uhrung im FLASH (der normale Fall: das 99.99%-Script). crt0 kopiert __data_romimage ins .data Segment (RAM) mit memcpy. Wir gesagt, f"ur C++ reicht das NICHT.
MarcVonWindscooting schrieb: > Wir gesagt, f"ur C++ reicht das NICHT. Was ist hiermit: http://midibel.com/blink1.html greg schrieb: > Naja, IDE != Compiler. Bei den genannten Keil und IAR sind IDE und Compiler ja "aus einer Hand". Bei LPCxpresso ist es gcc, vielleicht mal das Linkerscript vom Meister ansehen: https://github.com/microbuilder/LPC810_CodeBase
Lothar schrieb: > Was ist hiermit: http://midibel.com/blink1.html Eigentlich sehr interessant. In der praktischen Umsetzung aber ziemlich "Stillos"
1 | typedef unsigned int volatile * vp; |
2 | |
3 | ...
|
4 | // via UM-4.3.1
|
5 | *(vp)0x40048238 &= ~(1 << 7); // PDRUNCFG - enable syspll |
6 | *(vp)0x40048040 = 0; // SYSPLLCLKSEL - pll input to IRC |
7 | *(vp)0x40048044 = 0; // SYSPLLCLKUEN - toggle pllenable |
8 | *(vp)0x40048044 = 1; |
9 | *(vp)0x40048008 = 0x24; // SYSPLLCTRL - M=4+1,P=1 -> 12Mhz*5/1=60Mhz |
10 | ...
|
11 | public: |
12 | UART(int nr_) |
13 | : nr(nr_) // addr + nr * 0x4000 |
14 | {
|
15 | }
|
16 | bool putChar(char c) |
17 | {
|
18 | if (!(*(vp)0x40064008 & 0x4)) return -1; |
19 | *(vp)0x4006401c = c; |
20 | return c; |
21 | }
|
22 | void putCharBlocking_(char c) |
23 | {
|
24 | while (!(*(vp)0x40064008 & 0x4)) ; // STAT |
25 | *(vp)0x4006401c = c; // TXDAT |
26 | }
|
27 | int getChar() |
28 | ...
|
29 | extern unsigned int __data_end__; |
30 | extern unsigned int __etext; |
31 | unsigned int * f = (unsigned int *)(&__etext); |
32 | unsigned int * t = (unsigned int *)(&__data_start__); |
33 | unsigned int * e = (unsigned int *)(&__data_end__); |
Damit das nocht jemand versteht, sollte man sich einfach die Basisaddressen der Peripheriemodule als #Define in einem headerfile definieren. Mit C-99 typen (uint32_t) sieht der Code dann auch noch einmal etwas besser aus.
Himmel Hergott, ist das der Beitrag "schöner Code ?" Eigentlich wäre es ganz einfach, Magic Numbers durch #defines zu ersetzen. http://www.techrepublic.com/article/avoid-using-magic-numbers-and-string-literals-in-your-code/#.
chris_ schrieb: > Eigentlich wäre es ganz einfach, Magic Numbers durch #defines zu > ersetzen. Enums, wenn schon! (Um die Debatte hier gleich mal bissl aufzuheizen :)
MarcVonWindscooting schrieb: > Enums, wenn schon! > (Um die Debatte hier gleich mal bissl aufzuheizen :) Dann kann man aber die Register nicht mehr mit SYSCLKBASEPLLREGCTRL = 0 oder SYSCLKBASEPLLREGCTRL->CLKDIVMUL = 1<<33 Ansteuern
Aber mit dem kryptischen *(vp) davor schon. So, ich hab mal was geleistet und hab meinen Context-Switcher (Multitasking?) f"ur den LPC800 in die Code-Sammlung gestellt auf dass ihr ihn in Haut und Fetzen zerreissen k"onnt! Um nicht so schnell marktschreierisch "uberboten zu werden, h"atte ich es yokto-OS taufen sollen (nano-OS, pico, usw. sind ja schon Alltagsbegriffe).
Marc P. schrieb: > So, ich hab mal was geleistet und hab meinen Context-Switcher > (Multitasking?) f"ur den LPC800 in die Code-Sammlung gestellt auf dass > ihr ihn in Haut und Fetzen zerreissen k"onnt! Hättest für Dein tlYield wenigstens SVC nehmen können :-) Watchdog für abgerauchte Threads braucht auch nicht viel Platz, ebenso Memory Fault Handler für Stack-Überlauf.
SVC? Mich hat gestern jemand 'Sadist' genannt, daher bin ich eher f"ur
1 | BKPT 0 |
:o)
Marc, weisst Du was für Dein Anliegen wirklich nützlich wäre? Ein vernünftiger Basiscode für den LPC810. Kevin Townsend hat mal mit diesem hier angefangen: https://github.com/microbuilder/LPC810_CodeBase Ich habe dort vor eine Weile schon einige Redundanzen herausoptimiert. Was aber toll ware: - Startcode ohne CMSIS - Includes für Registerzugriff ohne CMSIS - Linkerscript für die GCC-Toolchain (z.B. vom ARM Launchpad) LPCXpresso ist zwar gut, geht mir in der Geschwindigkeit und mit den ganzen zusätzlichen Kladderadatsch auf die Nerven. Und CMSIS ist nicht wirklich für ein Device mit 4kb Flash geeignet. Ramloader und Multitasking sind tolle Fingerübungungen, zum Einstieg aber nur für sehr Abstrakt denkende Personen geeignet :) Wenn das auf Github läuft, helfen sicherlich auch noch Leute mit (ich z.B.). Will mir aber selbst den Schuh gerade mal nicht anziehen. Den 8 Pin LPC810 finden viele spannend. Und man kann sich die benötigte Hardware (Device, USBtoRS232) für unter fünf Eure besorgen. Nur mit dem Anfangen hapert es noch...
:
Bearbeitet durch User
> Den 8 Pin LPC810 finden viele spannend. > Und CMSIS ist nicht > wirklich für ein Device mit 4kb Flash geeignet. Wie viel Speicher braucht der Multitasker? 4kB ist eine Grenze, die für viele Anwendungen zu knapp ist, da die C-Bibliotheken immer schon gleich einiges verbrauchen. 8kB wäre deutlich besser.
chris_ schrieb: > 4kB ist eine Grenze, die für viele Anwendungen zu knapp ist Der LPC810 ist 8-bit-Ersatz und beim 8051 sind 1/2/4kB Standard. Natürlich muss man sich als verschwenderischer ARM-Programmierer erst mal mit Speicher sparen befassen, aber z.B. ich habe schliesslich einen PID-Regler mit Farb-LCD-Treiber für ST7735 und grafischer Anzeige der Regelung für den LPC810 in 3.5kB untergebracht. Ansonsten gibt es ja noch den LPC812 als SO-20 mit 16kB
greg schrieb: > Markus Müller schrieb: >> Lothar schrieb: >>> (übrigens stackt der Cortex-M automatisch). >> >> Stack? Was ist das? g >> Um den musste ich mich beim Cortex-Mx noch nie kümmern. Mach alles der >> C-Compiler und µC, ganz von alleine. > > Den richtigen Startup-Code brauchst du auf jeden Fall, das macht der > Compiler nicht für dich. Der Startup-Code für die LPC2000 war bei Keil in Assembler. Von den Jungs, die mit mir daran arbeiteten, schaute da niemand hinein, da gibts so eine Weigerung gegen Assembler. Das durfte dann ich machen, aber sowas macht mir auch Spaß. Tutorials für ARM-Assembler fand ich in der Anfangszeit nur bei Chinesen. Aber warum auch nicht bei denen mal was abschauen? Im Startup-Code habe ich dann in ARM-Assembler noch einiges angestrickt, z.B. an den Interruptvektoren. In C kommt man auch nicht weit, wenn man auf den Registersatz zugreifen muß. Im normalen Programm braucht man das aber nicht. Also es gibt durchaus solche Ausnahmen, wo man mal ein Schnipselchen Assembler braucht. Die Stacks für die verschiedenen Betriebsmodes mußte man auch manuell einstellen. Die muß man halt ermitteln.
ARM7 ohne ASM im Startup geht nicht. Cortex-M hingegen schon.
:
Bearbeitet durch User
chris_ schrieb: > Wie viel Speicher braucht der Multitasker? 86Bytes FLASH 8 Bytes RAM Context plus die Stackgr"osse >= 36 Bytes jeweils pro Thread. Und nur 36Bytes auch bloss, wenn Du keine lokale Variable auf'm Stack haben wirst. Du kriegst schon paar Threads unter, in den mickrigen 1k ;-) > ARM7 ohne ASM im Startup geht nicht. Cortex-M hingegen schon. Wie geht das denn? Ich meine mit 'C' ? Man verwendet 'C' + __attribute__((...)) um die ersten 4 Pointer dahinzubekommen, wo sie sein m"ussen, nur um keinen ASM zu verwenden. _attribute_ ist f"ur mich nicht sch"oner als ASM. Oder "ubersehe ich was?
MarcVonWindscooting schrieb: > Man verwendet 'C' + __attribute__((...)) um die ersten 4 Pointer > dahinzubekommen, wo sie sein m"ussen, nur um keinen ASM zu verwenden. > _attribute_ ist f"ur mich nicht sch"oner als ASM. Ich schrieb nicht davon, was du als schön empfindest - wie könnte ich das? - sondern von ASM und non-ASM. Und Attributes sind kein ASM. Aber wo wir nun einmal schon bei Ästhetik sind: Ich finde Attributes schöner als deine Umlaute. ;-)
:
Bearbeitet durch User
Okay, dann will ich's anders formulieren: __attribute__(()) hat ein Aroma, das stark an Assembler erinnert. Es ist sogar eine nicht-Standard Compiler-Erweiterung. Dann haette man auch gleich dem Compiler eine Option -fauto-generate-that-nasty-startup-code geben koennen und dann behaupten, da geht alles in 'C'. Und mit einem anderen Flag geht's dann ploetzlich f"ur den ARM7 auch.
Marc P. schrieb: > Okay, dann will ich's anders formulieren: __attribute__(()) hat ein > Aroma, das stark an Assembler erinnert. Die C-Fraktion scheint so einen Mist mehr zu lieben, als wirklich Assembler.
Wilhelm F. schrieb: > Die C-Fraktion scheint so einen Mist mehr zu lieben, als wirklich > Assembler. Steht irgendwo geschrieben, dass die Assembler-Fraktion partout nicht ihren heiss geliebten Assembler verwenden darf? Oder warum seid ihr so sauer?
:
Bearbeitet durch User
Tim schrieb: > weisst Du was für Dein Anliegen wirklich nützlich wäre? Ein vernünftiger > Basiscode für den LPC810. > ... > Wenn das auf Github läuft, helfen sicherlich auch noch Leute mit (ich > z.B.). Will mir aber selbst den Schuh gerade mal nicht anziehen. > ... Das mit dem Schuh anziehen kenn ich. Mit Basiscode meinst Du eine einfache Bibliothek f"ur die Peripherie? Und vielleicht noch einige Routinen zum Formatieren von Zahlen usw.? Wenn dass einfach bedeutet: einfache *.h und einfache "Ubersetzung eines Programms und (fast) einfache crt0 und (fast) einfache Linkerscripts und kein C++, dann hab ich das in der Schublade! Ich hatte mir eigentlich mehr erhofft, von dem ROM-Routinen im LPC800. I2C, ja die benutz ich - Platzersparnis! Beim UART hab ich das Gef"uhl, es ist einfacher direkt das Register-Interface zu benutzen.
MarcVonWindscooting schrieb: > Mit Basiscode meinst Du eine einfache Bibliothek f"ur die Peripherie? > Und vielleicht noch einige Routinen zum Formatieren von Zahlen usw.? > Wenn dass einfach bedeutet: einfache *.h und einfache "Ubersetzung > eines Programms und (fast) einfache crt0 und (fast) einfache > Linkerscripts und kein C++, dann hab ich das in der Schublade! Im Grunde genau das. Und es muss natülich auch irgendwie dokumentiert sein. Das mit Problem mit den LPCXpresso Standardeinstellungen: -Selbst die harmlose CMSIS SystemInit() frisst etliche hundert Bytes, obwohl sie nichts nützliches macht. (Der IRC ist sowieso schon initialisiert). Ich habe in dem oben verlinkten code SystemCoreClock schon einfach durch ein Define ersetzt. Da kann man aber CMSIS auch gleich weglassen. NXP empfielt sowieso die ROM-Routinen für die Clock-Settings. -Die LPC libs sind übel dokumentiert. Selbst im Source gibt es keine Funktionsbeschreibungen. Oder habe ich da etwas übersehen? -cr_startup ist für einen größeren Prozessor gedacht. -Es gibt einen Haufen von undurchsichtigen Abhängigkeiten. MarcVonWindscooting schrieb: > Ich hatte mir eigentlich mehr erhofft, von dem ROM-Routinen im LPC800. > I2C, ja die benutz ich - Platzersparnis! Beim UART hab ich das Gef"uhl, > es ist einfacher direkt das Register-Interface zu benutzen. Vor allem gab es zum ROM ein komisches Erratum, dass es nicht mit null waitstates betrieben werden soll?
:
Bearbeitet durch User
Fer T. schrieb: > Oder was ist mit den XMC von Infinion? Super Chips aber nirgends > erhältlich da die Autoindustrie da schon die ganze Produktion aufkauft > ;) Also zumindest sind die XMC Eval-Boars durchaus erhältlich: http://shop.myavr.de/ARM-Produktlinie/XMC4500%20Relax%20Lite%20Kit.htm?sp=article.sp.php&artID=200120 http://shop.myavr.de/ARM-Produktlinie/XMC1100%20Boot%20Kit.htm?sp=article.sp.php&artID=200119 und die Controller gibts auch: http://www.digikey.de/product-search/de?x=0&y=0&lang=de&site=de&KeyWords=XMC4500 Uli
MarcVonWindscooting schrieb: > Man verwendet 'C' + __attribute__((...)) um die ersten 4 Pointer > dahinzubekommen, wo sie sein m"ussen, nur um keinen ASM zu verwenden. Ist keineswegs nötig. Die Objektdateien werden vom Linker in der Reihenfolge ihres Auftretens auf der Kommandozeile eingebunden. Solange die Startup-Datei also als erste steht (was der Compilertreiber immer so macht), wird der darin enthaltene Code auch am Anfang der fertigen Objektdatei platziert. Da diese Datei lediglich eine einzige Tabelle enthalten muss, gibt's da auch nichts umzuschichten durch den Linker. Die Leutchen bei ARM haben sich schon was gedacht bei ihrem Konzept. Es war ein Design-Ziel der Cortex-M-Produkte, dass man nicht mehr zwinged Assembler benutzen muss.
Fer T. schrieb: > Oder was ist mit den XMC von Infinion? Super Chips aber nirgends > erhältlich da die Autoindustrie da schon die ganze Produktion aufkauft Und dazu muss man für das Herunterladen der Datenblätter, User Manuals und Schaltpläne eine NDA abnicken. Würg...
Uli.R schrieb: > und die Controller gibts auch: > > http://www.digikey.de/product-search/de?x=0&y=0&lang=de&site=de&KeyWords=XMC4500 aber halt bloss die GROSSEN, nicht die XMC1100. Kann man die eigentlich ohne 'DAVE' benutzen. Wie flasht man die? Vielleicht sogar unter Linux? Hab schon 2 mal im Manual gesucht, war jedesmal so schlau wie vorher...
Die Parallax Propeller Leute haben es geschafft, mit nur einem I/O-Pin einen Sigma-Delta Wandler zu bauen. Da der LPC800 keine ADC hat: gibt es so was?
chris_ schrieb: > Da der LPC800 keine ADC hat: gibt es so was? Google: AN11329: Implementing sigma-delta ADC with LPC800 comparator Fürs Grobe kann man es aber auch so machen: die Voltage-Ladder hat 32 Stufen, also kann man direkt einen 5-bit ADC realisieren (für ein Poti reicht das): #define CMP_LAD_MAX 31 for (n=CMP_LAD_MAX; n>0; n--) { // CMP voltage ladder value change *((unsigned long *) CMP_LAD) = (n<<(CMP_VAL_POS)) | 1<<(CMP_LAD_ENABLE_BIT); // CMP result val = *((unsigned long *) CMP_CTRL); // CMP <> threshold ? if (val & (1<<(CMP_STATUS_BIT))) { d = n; break; } }
Du meinst dieses: http://www.lpcware.com/content/nxpfile/an11329-implementing-sigma-delta-adc-lpc800-comparator Von Parallax gibt es eine ähnliche Applikation Note: http://www.parallaxsemiconductor.com/an008 Aber sie haben es dann später mit nur einem Pin geschafft: http://forums.parallax.com/showthread.php/149185-DEMO-Single-Pin-Sigma-Delta-ADC-Driver-v1?highlight=sigma+delta
Naja, zum Poti auslesen reichen diese Hacks... aber sonst? Der fehlende ADC ist durchaus unschön.
greg schrieb: > Naja, zum Poti auslesen reichen diese Hacks... aber sonst? Der fehlende > ADC ist durchaus unschön. Du schreibst doch sonst immer man soll den minimalen uC nehmen. Der ist eben für Anwendungen die keinen ADC benötigen, gibt ja genügend. Die kleinen 8051 haben auch keinen.
Lothar schrieb: > greg schrieb: >> Naja, zum Poti auslesen reichen diese Hacks... aber sonst? Der fehlende >> ADC ist durchaus unschön. > > Du schreibst doch sonst immer man soll den minimalen uC nehmen. Der ist > eben für Anwendungen die keinen ADC benötigen, gibt ja genügend. Die > kleinen 8051 haben auch keinen. Darum greifen die meisten dann zum Tiny85, der hat das alles. Darum ist der LPC800 auch so tot. Heute brauchen die typischen "Bastler-Controller" viel Peripherie.
>> Du schreibst doch sonst immer man soll den minimalen uC nehmen. Der ist >> eben für Anwendungen die keinen ADC benötigen, gibt ja genügend. Die >> kleinen 8051 haben auch keinen. > > Darum greifen die meisten dann zum Tiny85, der hat das alles. Darum ist > der LPC800 auch so tot. Heute brauchen die typischen > "Bastler-Controller" viel Peripherie. Das ist aber eine ziemlich unfundierte Aussage. Außer dem ADC hat der LPC800 deutlich bessere Peripherie als z.B. ein ATtiny85. Da liegen Welten dazwischen. Dank SCT und internem DAC ist der Aufbau von einem Sigma-Delta ADC auch recht effizient. Es war m.E. geplant, die LPC800 Serie auch mit ADC zu erweitern.
Lothar schrieb: > Du schreibst doch sonst immer man soll den minimalen uC nehmen. Kann mich nicht dran erinnern. Ich hab nur behauptet, dass die Switch Matrix die Flexibilität erhöht und man so in manchen Fällen nur einen kleineren Controller benötigt.
cyblord ---- schrieb: > Darum greifen die meisten dann zum Tiny85, der hat das alles. Darum ist > der LPC800 auch so tot. Heute brauchen die typischen > ... Und ein paar andere greifen halt zu einem LPC1110/LPC1112. Gibt's ebenfalls in SOIC20 und hat den ADC (aber keine Switchmatrix, keinen SCT). Ich springe zwischen LPC800 und LPC1100 hin und her - die haben einiges gemeinsam.
Oder wenn man DIP mag eben den LPC1114FN28 ;-) Hier habe ich mal mit einem ein wenig experimentiert: http://www.hobby-roboter.de/forum/viewtopic.php?f=5&t=140 >Fürs Grobe kann man es aber auch so machen: die Voltage-Ladder hat 32 >Stufen, also kann man direkt einen 5-bit ADC realisieren (für ein Poti >reicht das): > > #define CMP_LAD_MAX 31 > > for (n=CMP_LAD_MAX; n>0; n--) Um auch bei einem ARM ein wenig Rechenzeit zu sparen: Via SAR ( http://www.vias.org/mikroelektronik/adc_succapprox.html ) sollte es in 5 Schritten gehen.
Hinweis noch auf diesen Fehler: (falls jemand noch alte Sourcen in Verwendung hat) http://www.lpcware.com/content/bugtrackerissue/lpc800-acmp-ladder-selection-value-misaligned
:
Bearbeitet durch User
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.