NXP hat heute den 32-bit Vogel erst mal abgeschossen. Die neue Baureihe LPC1100, die fuer Dezember angekuendigt ist soll (bei 10000 Stueck ;-) weniger als 50 Eurocent kosten. Das waere dann ein 33-pin Microcontroller, nein das ist kein Scherz, mit 8k Flash und 2k SRAM. Der soll dann bis 50 MHz schnell laufen und dabei weniger als 10 mAs benoetigen. Ich weiss, das ist immer noch kein 8-pin Chip aber es werden immer weniger, die Power immer niedriger, die Preise immer niedriger... Die Welt der ARM MCUs draengt immer mehr in den 8-bit Bereich waehrend sie gleichzeitig am enderen Ende Intel angreift, doch das soll hier nicht so sehr zur Debatte stehen. Also hier gibts mehr Info, Link zum Data Sheet... http://mcu-related.com/architectures/35-cortex-m3/92-lpc1100 Gruss, Robert
Warum sollte sich ein 32Bitter billiger herstellen lassen als ein 4 Bit Mikrocontroller? Und letzterer reicht oft für alles aus. Oder redest du vom Hobbybereich? ;)
Wieviel MIPS macht der denn ? Mehr als 20 ?
@Simon Hobby und professional. 32-bit wird in neuester Technologie gemacht, ist somit wahrscheinlich kleiner als ein 15 Jahre alter 4-bit.. @Krishna Soll 45 DMips koennen und Compiler von Keil, IAR und noch ein paar mehr gibt's auch. Robert
45 Mips sind ja schonmal sehr ok :-) Schön. Ist bei all den Compilern auch eine kostenfreie Variante dabei ? Nicht, daß der Chip 50 Cent kostet, und der Compiler das hundertfache :-)
Och, kein EEPROM..schade naja, manchmal braucht man ja auch keins. Ansonsten aber interessant ! Datasheet: http://www.standardics.nxp.com/products/lpc1000/datasheet/lpc1111.lpc1112.lpc1113.lpc1114.pdf
>Nicht, daß der Chip 50 Cent kostet, und der Compiler das hundertfache
Das waeren 50 EUR - meine Vermutung: Das wird wohl lange nicht reichen.
Gast
> mit 8k Flash und 2k SRAM Damit läge er aber auch in der Kategorie eines ATMega8 nur schneller. Und in Einzelstückzahlen wird er sicher auch mehr als 50 Cent kosten. Aber stimmt schon, mehr Rechenleistung fürs gleiche Geld. > Gibts einen Compiler ? Müsste nicht eventuell der gcc gehen? ARM wird doch von dem unterstützt, oder?
Malte __ schrieb: > Müsste nicht eventuell der gcc gehen? ARM wird doch von dem unterstützt, > oder? Im Prinzip ja, denn der Befehlssatz entspricht ungefähr dem Thumb(1) aus ARM7TDMI, etwas erweitert. Insofern steckt das im Compiler grundsätzlich drin. Ob dieser Cortex-M0 Mix allerdings schon im GCC so auswählbar ist habe ich grad nicht parat.
Malte __ schrieb: > Müsste nicht eventuell der gcc gehen? ARM wird doch von dem unterstützt, > oder? Zumindest Sourcery G++ Lite 2009q1-161 unterstützt alle aktuell erhältlichen Cortex-M Prozessoren. Vor wenigen Tagen ist mal wieder eine neue Version rausgekommen. Gruß Marcus http://www.doulos.com/arm/
5V tolerant und nur eine VCC klingt schonmal gut. Die 8kB Flash kann man natürlich nicht mit nem 8-Bitter gleichsetzen, die entsprechen eher einem 2..4kB 8-Bitter. Ich bin auch etwas irritiert, hat der Cortex nun Bitbefehle oder nicht? D.h. wie lange dauert es, einen Portpin zu setzen, 1 Befehl oder 3 Befehle? Peter
Peter Dannegger schrieb: > Ich bin auch etwas irritiert, hat der Cortex nun Bitbefehle oder nicht? > D.h. wie lange dauert es, einen Portpin zu setzen, 1 Befehl oder 3 > Befehle? Letztlich 3 Befehle, egal ob ARM7, CM3 oder CM0. Einer um die Konstante zu laden, einer um die Adresse vom Portregister zu laden, und einer um sie dort reinzuschreiben. Alle mir bekannten vollintegrierten Controller auf ARM Basis besitzen Portregister mit denen ohne erst lesen zu müssen Pins gesetzt und gelöscht werden können. Details über den CM0 Core, also beispielsweise ob Bitbanding drin ist oder nicht, hat ARM m.W. noch nicht öffentlich verraten. Mal sehen wer schneller ist, NXP mit den Controllern oder ARM mit der Dokumentation dazu. ;-)
Peter Dannegger schrieb: > 5V tolerant und nur eine VCC klingt schonmal gut. > Die 8kB Flash kann man natürlich nicht mit nem 8-Bitter gleichsetzen, > die entsprechen eher einem 2..4kB 8-Bitter. > > > Ich bin auch etwas irritiert, hat der Cortex nun Bitbefehle oder nicht? > D.h. wie lange dauert es, einen Portpin zu setzen, 1 Befehl oder 3 > Befehle? Im Thumb mode schätze ich die Codelänge nicht sehr unterschiedlich zu den 8bit MC's ein. Beim RAM Verbrauch ist darauf zu achten, daß der Linker die Adressen von Arrays und Strukturen generell auf durch 4 teilbare Adressen setzt.Dadurch konnen "Löcher" in der RAM-Belegung entstehen. Weiters ist bei den Strukturen darauf zu achten, dass 16bit und 32bit variable auf geraden bzw. durch 4 teilbaren Adressen liegen.Geht sich das nicht aus, so entstehen in der Struktur ebenfalls "Löcher". Der ARM Kern scheint generell nicht für das setzen non einzelnen Port-Bits entwickelt zu sein. So um die 100ns muß man bei 50MHz Core rechnen. Dennoch: Meiner Meinung nach bieten die Cortex MC's für jede auch nur wenig anspruchsvolle Applikation das beste Preis-Leistungsverhältnis. Ach ja, kostenlosen GCC Compiler gibts natürlich auch. Grüße
@Robert: Kannst Du mir dann Samples (PLCC44) besorgen ? Muss nicht umsonst sein ;-)
Gebhard Raich schrieb: > Im Thumb mode schätze ich die Codelänge nicht sehr unterschiedlich zu > den 8bit MC's ein. Je grösser der Code wird, je mehr Software-Layer beteiligt sind, desto eher liegt Cortex vorne. Aber für Port-I/O und Steuerregister geht bei den Cortexen deutlich mehr Platz drauf als bei kleinen 8-Bittern. Um ein Steuerregister zu schreiben, egal ob Portpin oder SPI-Control, braucht man bei AVR oder 8051 2-4 Bytes, beim CM0 um die 10 Bytes (3 Befehle à 2 Bytes, 2 Konstanten à 4 Bytes), und aufgrund der grösseren Komplexität der Module hat er auch deutlich mehr davon. Ebenso sind globale Variablen deutlich teurer (Adressbreite). D.h. eine 1:1 Umsetzung eines Programmierstils, der für PIC und 8051 optimal war, wird auf dem CM0 nicht unbedingt genauso gut abschneiden.
Hm, das widerspricht sich dann aber - Programme mit viel IO brauchen also auch viel Platz - Aber grade die Mikros setzt man doch hauptsächlich für IO-Lastige Sachen ein. So gesehen wird der verfügbare Flash aber sehr sehr schnell knapp - wodurch kein Platz mehr für "Intelligenteres" mehr bleibt.
Krishna schrieb: > Hm, das widerspricht sich dann aber - Bischen schon. > Programme mit viel IO brauchen also auch viel Platz - Aber grade die > Mikros setzt man doch hauptsächlich für IO-Lastige Sachen ein. Aber das lässt schnell nach. Wenn man die I/O-Module geschrieben sind, dann war's das. Man hat einen Bodensatz von einigen KB, in denen der lowlevel-Kram abgewickelt wird. Der Rest sitzt dort drauf und greift nicht direkt auf die Hardware zu.
Krishna schrieb: > Kannst Du mir dann Samples (PLCC44) besorgen ? Bin mal gespannt ob es dem genauso ergeht mit dem LPC2103 in PLCC44. Der wurde vor ein paar Jahren angekündigt und kam nie.
>In 4KB kann ein 8051 mehr machen als ein >CM0. In 32KB kann ein CM0 bei passendem Programmierstil mehr >unterbringen als ein 8051 Hm, der "neue" bietet ja eben nur 8 KB...
Krishna schrieb:
> Hm, der "neue" bietet ja eben nur 8 KB...
8/16/24/32KB ROM, 2/4/8KB RAM.
Huch, ok, hatte ich nicht "registriert" :-)
Im Bastelbereich finde ich die LPC1100 nicht allzu interessant. Ob das Ding 2€ oder 4€ kostet spielt da nicht die grosse Rolle und ein QFN33-Gehäuse ist auch nicht mein Traum (PLCC44 ist schon interessanter). Beim LQFP48-Gehäuse wiederum gibt es die wesentlich reicher ausgestatteten und ebenso bezahlbaren STM32F103Cx. Industriell sieht das natürlich anders aus.
Krishna schrieb:
> Hm, der "neue" bietet ja eben nur 8 KB...
Solche Spar-Zwerge mit 8KB Flash auf CM3 Basis hat(te) Luminary Micro
rausgebracht, in SO28. Aber in denen ist nicht nur wenig ROM und RAM
drin, sondern auch sonst fast nichts. Wenn man mit sowas nicht dauernd
32-Bit Zahlen multipliziert und dividiert, dann ist ein Mega8 allemal
nützlicher.
Ich warte immer noch die Firma, die für uns Bastler all die kleinen Dinger - bezahlbar! (und damit meine ich weniger als 5€ Aufpreis) - auf Headerboards liefert :-)
Gebhard Raich schrieb: > Beim RAM Verbrauch ist darauf zu achten, daß der Linker die Adressen > von Arrays und Strukturen generell auf durch 4 teilbare Adressen > setzt.Dadurch konnen "Löcher" in der RAM-Belegung entstehen. Aber nicht grundsätzlich. Das Alignment einer Struktur entsprcht dem größten Aligment ihrer Elemente. Besteht die Struktur z.B. nur aus char, dann hat die Struktur selbst auch nur Byte Alignment. > Weiters ist bei den Strukturen darauf zu achten, dass 16bit und > 32bit variable auf geraden bzw. durch 4 teilbaren Adressen > liegen. Je nach Compiler kann man auch ein packed-Attribut (oder __packed) angeben. Damit wird das Alignment aufgehoben. Zu Lasten der Speicherbandbreite, da Zugriffe möglicherweise[1] mehr als einen Zyklus benötigen. Gruß Marcus http://www.doulos.com/arm/ Footnotes: [1] Im Gegensatz zu früheren ARM cores (z.B ARM7, ARM9) hat das keine zusätzlichen Instruktionen zur Folge, die einen konstanten Overhead erzeugen.
A. K. schrieb: > Details über den CM0 Core, also beispielsweise ob Bitbanding drin ist > oder nicht, hat ARM m.W. noch nicht öffentlich verraten. Der Cortex-M0 implementiert die selbe Architektur wie der Cortex-M1 (v6-M). Man kann sich den M0 in etwa als ASIC Version des M1 vorstellen. Cortex-M0 und -M1 haben kein bit-banding. Gruß Marcus http://www.doulos.com/arm/
Krishna schrieb: > Ich warte immer noch die Firma, die für uns Bastler all die kleinen > Dinger - bezahlbar! (und damit meine ich weniger als 5€ Aufpreis) - auf > Headerboards liefert :-) Ich habe mich mittlerweile damit anfreunden können: http://cgi.ebay.com/8x-LQFP-TQFP-SMT-ADAPTER-DIP-05-1-27-PROTO-AREA-LOT_W0QQitemZ330377221367QQcmdZViewItemQQptZLH_DefaultDomain_2?hash=item4cec0454f7
Marcus Harnisch schrieb: > [1] Im Gegensatz zu früheren ARM cores (z.B ARM7, ARM9) hat das > keine zusätzlichen Instruktionen zur Folge, die einen konstanten > Overhead erzeugen. Doch. Im Gegensatz zu den CM3 unterstützt der CM0 kein unaligned access.
@A. K. Oh, das ist aber schonmal sehr okay. Danke für den Tip.
A. K. schrieb: > Je grösser der Code wird, je mehr Software-Layer beteiligt sind, desto > eher liegt Cortex vorne. Aber für Port-I/O und Steuerregister geht bei > den Cortexen deutlich mehr Platz drauf als bei kleinen 8-Bittern. Um ein > Steuerregister zu schreiben, egal ob Portpin oder SPI-Control, braucht > man bei AVR oder 8051 2-4 Bytes, beim CM0 um die 10 Bytes (3 Befehle à 2 > Bytes, 2 Konstanten à 4 Bytes), und aufgrund der grösseren Komplexität > der Module hat er auch deutlich mehr davon. > > Ebenso sind globale Variablen deutlich teurer (Adressbreite). D.h. eine > 1:1 Umsetzung eines Programmierstils, der für PIC und 8051 optimal war, > wird auf dem CM0 nicht unbedingt genauso gut abschneiden. Interessanterweise habe ich hierzu vor etwa drei Jahren mal eine Untersuchung angestellt und den C code aus dem c't-Bot (target: AVR) für den Cortex-M3 übersetzt -- wohlgemerkt ohne ihn vorher auf die speziellen Eigenschaften der ARM Architektur anzupassen. Das Ergebnis war dennoch niederschmetternd für den AVR. Bei einzelnen Sachen wie Peripheriezugriff mag der acht-bitter möglicherweise überlegen sein. Sobald, wie Du vermutest, diese Ebene verlassen wird, geht die Schere auf. Bei der Datein motor.c (stark algorithmisch), z.B. lag die Größe des erzeugten Thumb-2 Codes bei etwa 60-75% des entsprechenden AVR codes, abhängig vom Compiler und Optionen. GCC hat durchweg schlechter abgeschnitten als der RealView Compiler. Gruß Marcus http://www.doulos.com/arm/
>Untersuchung angestellt und den C code aus dem c't-Bot (target: AVR) >für den Cortex-M3 übersetzt -- wohlgemerkt ohne ihn vorher auf die >speziellen Eigenschaften der ARM Architektur anzupassen. Das Ergebnis >war dennoch niederschmetternd für den AVR. Was mir jetzt nicht ganz klar ist: Hast Du den Code für den AVR mit dem GCC für ARM kompiliert? Das ist meistens ziemlich gut möglich, da es ja der selbe Compiler ist. Interessant wäre da die resultierende Codegröße. >GCC hat durchweg schlechter >abgeschnitten als der RealView Compiler. Du hast also nicht GCC verwendet. Es wäre ja gut möglich, dass auch der IAR Compiler für den AVR wesentlich kleinere Codegrößen erzeugt.
>LPC1100, die fuer Dezember angekuendigt ist soll (bei 10000 Stueck ;-) >weniger als 50 Eurocent kosten. Das waere dann ein 33-pin >Microcontroller, nein das ist kein Scherz, mit 8k Flash und 2k SRAM. Der >soll dann bis 50 MHz schnell laufen und dabei weniger als 10 mAs Hmm, finde ich jetzt nicht sooo überzeugend. Der winzige SRAM stört mich schon bei den ganzen 8-Bittern, warum soll ich mir einen 32-Bitter kaufen, der so ärmlich mit SRAM bestückt ist? Und die Bauform, naja. Eine Innovation wäre ja mal ein 32-Bit-uC als DIP.
Gastino schrieb: > Eine Innovation wäre ja mal ein 32-Bit-uC als DIP. Ein Kompromiss ist LQFP48 auf obigem DIP48-Träger. Und wenn der LPC1100 tatsächlich als PLCC44 kommt, dann nützt das zwar nicht für Breadboards, aber für Lötpunktraster taugt es.
>>> Interessanterweise habe ich hierzu vor etwa drei Jahren mal eine >>> Untersuchung angestellt Wo kann man das Ergebnis dieser Untersuchung sehen? Gibt es einen Link?
Gastino schrieb: > Hmm, finde ich jetzt nicht sooo überzeugend. Der winzige SRAM stört mich > schon bei den ganzen 8-Bittern, warum soll ich mir einen 32-Bitter > kaufen, der so ärmlich mit SRAM bestückt ist? Und die Bauform, naja. > Eine Innovation wäre ja mal ein 32-Bit-uC als DIP. Schau dir mal die PIC24H bzw. dsPIC33F an, die gibts bis 128kByte Flash und 16kByte SRAM in DIP28. Sind aber nur 16bit, mit 40MIPs und Harvard Architektur dürften die ähnlich schnell sein wie der ARM.
@Benedikt Bei einem MC im Dip-Gehäuse und auf Steckbrett oder Lochraster muß und kann nix mehr rasend schnell gehen.Da hat man Platz und Zeit wie vor 20 Jahren... Grüße
>Ein Kompromiss ist LQFP48 auf obigem DIP48-Träger. Und wenn der LPC1100 >tatsächlich als PLCC44 kommt, dann nützt das zwar nicht für Breadboards, >aber für Lötpunktraster taugt es. Prinzipiell ja. Das Problem ist nur, dass diese Träger ziemlich teuer sind und ein Vielfaches des Controllers kosten. >Bei einem MC im Dip-Gehäuse und auf Steckbrett oder Lochraster muß und >kann nix mehr rasend schnell gehen.Da hat man Platz und Zeit wie vor 20 >Jahren... Diese "Logik" verstehe ich nicht. >Schau dir mal die PIC24H bzw. dsPIC33F an, die gibts bis 128kByte Flash >und 16kByte SRAM in DIP28. Sind aber nur 16bit, mit 40MIPs und Harvard >Architektur dürften die ähnlich schnell sein wie der ARM. Jep, die habe ich mir schon mal angesehen (nur ganz grob). Das scheint die einzige Alternative zu sein, wenn man etwas mehr SRAM benötigt. Zur Zeit komme ich zum Glück noch mit den RAMs der ATmega16/32/644 aus, aber wenn das nicht mehr reicht, wird es unschön. Dann bleiben nur die Alternativen Adapter (teuer) oder jedesmal eine Platine herstellen lassen (sehr teuer).
Gastino schrieb: > Prinzipiell ja. Das Problem ist nur, dass diese Träger ziemlich teuer > sind und ein Vielfaches des Controllers kosten. Muss der Controller aber sensationell günstig sein. Diese Träger kosten 80¢ pro Stück inklusive Porto (bei 8 Stück). Drauf ein STM32F103C8 mit USB/CAN und 64KB Flash 20KB RAM bei 72MHz (6,50€ plus MWSt bei TME). Akzeptables Preis/Leistungsverhältnis, ggf. pinkompatibel ausbaufähig auf 128KB Flash.
Olaf schrieb: > Wo kann man das Ergebnis dieser Untersuchung sehen? Gibt es einen Link? Falls Du Zugriff auf die Vorträge der ARM Developers Conference 2006, möglicherweise auch 2007 hast, könntest Du das finden. Es ging aber hierbei ausdrücklich nicht um ARM vs. AVR, sondern lediglich darum, die Vorurteile gegenüber 32bit Prozessoren beim Einsatz in traditionellen 8bit Domänen auszuräumen. Ein Teil dieses Vortrags behandelte die Codegröße. Es handelte sich übrigens nicht um eine Untersuchung nach anerkannten wissenschaftlichen Standards. Schon die genaue Dokumentation der Vorgehensweise ist möglicherweise lückenhaft (hüstel). Vielleicht finde ich noch die Compile-Scripte. Gruß Marcus http://www.doulos.com/arm/
chris schrieb: > Was mir jetzt nicht ganz klar ist: Hast Du den Code für den AVR mit dem > GCC für ARM kompiliert? Das ist meistens ziemlich gut möglich, da es ja > der selbe Compiler ist. Aber für eine andere Architektur. GCC für AVR ist nun mal im Nachteil, da GCC stark auf 32bit optimiert ist. GCC ist aber der im c't-Bot Projekt verwendete Compiler und somit Referenz. >>GCC hat durchweg schlechter >>abgeschnitten als der RealView Compiler. > Du hast also nicht GCC verwendet. Es wäre ja gut möglich, dass auch der > IAR Compiler für den AVR wesentlich kleinere Codegrößen erzeugt. Woraus liest Du das denn? Der (ungefähren) Fairness halber, habe ich natürlich auch GCC für ARM verwendet (Code Sourcery). Daneben habe ich den RealView Compiler eingesetzt. Auf IAR für AVR habe ich leider keinen Zugriff. GCC für ARM hat sich auch nicht gerade mit Ruhm bekleckert. Gruß Marcus http://www.doulos.com/arm/
>GCC für ARM hat sich auch nicht gerade mit Ruhm bekleckert.
Dafür das er nichts kostet ist er sehr ruhmreich. Die kastrierten
Versionen der "guten" Compiler reichen auch für den Privatgebrauch
längst nicht immer. Wenn man z.B. durch einen dummen Zufall mal einen
TCP-Stack verwendet oder mehr als einen Zeichensatz braucht.
Und: Bei den Vergleichen die ich vor ca. zwei Jahren zwischen RealView
und GCC gemacht habe war der RealView zwar durchweg besser, sein
Vorsprung betrug aber nie mehr als 5% (Code und Speed). Und dafür >2000€
berappen? No Sir!
>> ... betrug aber nie mehr als 5% ...
Wo kann man das Ergebnis dieser Vergleiche sehen? Gibt es einen Link?
>Muss der Controller aber sensationell günstig sein. Diese Träger kosten >80¢ pro Stück inklusive Porto (bei 8 Stück). Das hier verlinkte Adapter-Board kostet 7,20$. Wo beziehst Du die für 80Cent?
Gastino schrieb: > Das hier verlinkte Adapter-Board kostet 7,20$. Wo beziehst Du die für > 80Cent? Also ich habe das Inserat so verstanden, dass 8 St. soviel kosten.
>Also ich habe das Inserat so verstanden, dass 8 St. soviel kosten.
Das habe ich glatt überlesen... :)))
>Wo kann man das Ergebnis dieser Vergleiche sehen? Gibt es einen Link?
Nirgendwo. Die Tests habe ich in meinem stillen Kämmerlein gemacht. Ich
wurde auch nicht dafür bezahlt.
Die meisten Vergleiche bezogen sich auf Geschwindigkeit: Verschachtelte
Funktionsaufrufe, Arrayzugriffe (Offsetberechnung), Strukturzugriffe und
arithmetische Operationen (Integer). Bei letzterem hat es mich besonders
interessiert ob und wie gut der Compiler Zwischenergebnisse aus
vorherigen Berechnungen wiederverwenden kann.1 | a = 2*b + x + 9; |
2 | b = 2*b + x + 10; |
Da nehmen sich die beiden aber nichts. Die libc habe ich nicht (wissentlich) verwendet. printf(), itoa() und co sind selbst programmiert. PS: Controller dürfte ein LPC2103 gewesen sein, also ARM7. Auf jeden Fall im ARM Mode. Wofür war Thumb nochmal gut? ;)
Mehmet Kendi schrieb:
> Also ich habe das Inserat so verstanden, dass 8 St. soviel kosten.
Ist so. Hab's mit dem STM32F101C6 (32K/36MHz) vom gleichen Shop
ausprobiert. Liess sich astrein mit der Flussmittel+Entlötlitzenmethode
einlöten. Mega32/644 ade.
Wie programmiert man den, d.h. wo gibt es Schaltplan + Software für den Programmer ?
Beispielsweise per fertig enhaltenem Bootloader über die serielle Schnittstelle. Programm dazu gibt's bei ST. Ein Pin steuert, ob der Bootloader oder das Flash startet. Bequemer siehe Beitrag "STM32 Programmiertool", da steuert die serielle Schnitstelle an Stelle von Schaltern die BOOT0+Reset Pins und automatisiert den Vorgang. Alternativ geht das natürlich auch via JTAG-Adapter für's Debugging, dafür siehe hiesigen Shop, die üblichen Verdächtigen wie Segger oder selber gebaut mit FT2232.
Hm, nachdem ich grade den Niche TCP/IP Stack dafür entdeckt habe, habe
ich große Lust mein angedachtes Webradio mit dem STM zu realisieren :-)
Soweit ich gelesen habe, ist der doch kostenlos ("For customers") -
Reicht es, wenn ich mich bei STM anmelde ?
Da muss ich mich nun wohl ein wenig auf STM einarbeiten - gibt es
irgendwo Deutschsprachige Seiten für den Anfang ? Habe zwar mit Englisch
kein Problem, aber auf Deutsch liest es sich doch immer noch flüssiger.
Nicht deutsch, aber nützlich: Über den Cortex-M3: http://www.amazon.de/Definitive-Guide-Cortex-M3-Embedded-Technology/dp/0750685344/ref=sr_1_1?ie=UTF8&s=books-intl-de&qid=1258492724&sr=1-1 Über die STM32 Implementierung: http://www.st.com/mcdfiles/1221142709.pdf
Ich werde mir für den Anfang mal das hier besorgen: http://www.ehitex.de/p_info.php?products_id=430 Da kann man nicht meckern. 256 K Flash, 64KB Ram, Ethernet, Usb..
A. K. schrieb: > Muss der Controller aber sensationell günstig sein. Diese Träger kosten > 80¢ pro Stück inklusive Porto (bei 8 Stück). > > Drauf ein STM32F103C8 mit USB/CAN und 64KB Flash 20KB RAM bei 72MHz > (6,50€ plus MWSt bei TME). Akzeptables Preis/Leistungsverhältnis, ggf. > pinkompatibel ausbaufähig auf 128KB Flash. Bei Farnell sind die Preise günstiger: 1 - 9 st. 5,30 ab 10 st 4,15
Mehmet Kendi schrieb:
> Bei Farnell sind die Preise günstiger:
Jo, aber in meinem Fall geht es um privaten Gebrauch. Und HBE als
deutscher Vertrieb für solche Kunden will für den STM32F103C8
indiskutable 13,40€. Kurioserweise will er für die grössere 128KB
Version davon (CB) nur 12,90€.
Da hat doch aber die LPC17xx Serie von NXP noch ein besseres P/L Verhältnis, oder? Immerhin kostet der LPC1752 mit 64k Flash, 16k RAM, 100MHz, USB/CAN gerade mal 5,20€ INKL MWSt (HBE). Und der große Brocken (LPC1768) mit 512k Flash, LAN, USB ect. nur 9€.
Ich gebe privat ab STM32F103CBT6 für 9,20 Euro inkl. Versandkosten im Kompaktbrief.
Jörg S. schrieb: > Da hat doch aber die LPC17xx Serie von NXP noch ein besseres P/L > Verhältnis, oder? Bezogen auf die merkwürdige Preispolitik von HBE schon, aber auf Träger ist mit der 80-Pin NXP-Klops für viele Fälle zu gross. LQFP48 gefällt mir besser. Und TME hat ihn, jedenfalls in der 64KB Version.
Gast schrieb: > Ich gebe privat ab STM32F103CBT6 für 9,20 Euro inkl. Versandkosten > im Kompaktbrief. Danke, komme ich ggf. darauf zurück, aber vorzugsweise Kontakt per email.
A. K. schrieb: > Bezogen auf die merkwürdige Preispolitik von HBE schon, aber auf Träger > ist mit der 80-Pin NXP-Klops für viele Fälle zu gross. ... und zu frisch. Das erste Jahr lasse ich gerne andere Leute die Fehler suchen. ;-)
Nur noch mal zurueck zum Original-Thread. Es ging mir darum, dass es jetzt (bald) 32-bit controller gibt, die in fast allen Dingen den 8-bittern ueberlegen sind. Es ging mir jedenfalls nicht darum das obere Producktspektrum der Cortex-M3 Chips nochmals zu beleuchten, denn diese haben einen anderen Zielmarkt, naemlich das untere Ende von 32-bit Anwendungen bzw. den Schwerpunkt von 32-bit Flash MCU Anwendungen. Robert
>Es ging mir darum, dass es >jetzt (bald) 32-bit controller gibt, die in fast allen Dingen den >8-bittern ueberlegen sind. Was für eine Feststellung!
Hi >Nur noch mal zurueck zum Original-Thread. Es ging mir darum, dass es >jetzt (bald) 32-bit controller gibt, die in fast allen Dingen den >8-bittern ueberlegen sind. Na und. In vielen Anwendungen langweilen sich schon 8-Bitter oder sogar 4-Bitter. Warum dann einen 32-Bitter bemühen? MfG Spess
Ich finde auch, der Grat ist schmal. Wenn z.b. ein avr mit 20MHZ nicht mehr reicht, warum dann nicht gleich zu etwas wesentlich stärkerem greifen. Für Bastler - und dies ist ja ein "Bastel"-Forum - ist die Gehäuseform viel wichtiger, als ein paar Cent beim Prozessor zu sparen. Und da seh ich den neuen nicht wirklich im Vorteil gegenüber anderen - die dann aber auch direkt mit 256 KB Flash, 64K Ram usw. aufwarten können. OK, PLCC44 und dann für unter 5 EUR (Endkundenbastlereinzelstückpreis) wäre ein echtes Argument - wenn es denn wirklich kommt. Ansonsten kaufe ich mir eine stamp mit STM32 drauf für 18 € aus Thailand und habe dann gleich was in jeder Beziehung stärkeres - und muss mich nicht mit SMD herumplagen. Das sagt einer, der grade von AVR in diese Liga wechselt.
Hallo, wenn ich mir das Datenblatt bezüglich ADC anschaue, bleibe ich doch lieber bei einem PIC. Der ADC des LPC ist zwar schneller, liefert aber nur "typisch" 8 Bit Genauigkeit. Beim PIC sind die Worst-Case angaben noch besser als die typischen des LPC.
spess53 schrieb: > Na und. In vielen Anwendungen langweilen sich schon 8-Bitter oder sogar > 4-Bitter. Warum dann einen 32-Bitter bemühen? Jenseits kleiner Anwendungen (einige KB) nervt mich bei vielen 8- und 16-Bittern die Adressraumtrennung, die beispielsweise bei Strings zu Verrenkungen führt. Mit besserem Compiler-Support als GCC ist das zwar weniger krass, aber immer noch nervend.
@Anja Die STM32 Serie hat 12bit ADC's, ebenso die ADUC70xx und die sind bei entsprechendem Layout wirklich bis zum letzten Bit stabil. Grüße
@spess53 Warum 32-bit fuer kleine Anwendungen? Ich wuerde die Frage mal anders rum stellen. Was bringt es mir meine getesteten Code Bausteine immer wieder benuetzen zu koennen? Was bringt es mir immer dieselben Tools zu benutzen fuer meine 8k Anwendungen und fuer meine 512K Anwendungen? Was bringt es wenn meine Ingenieure eine Architektur wirklich toll beherrschen anstelle von Architekturen recht ordentlich? Was bringt Standardisierung? Es geht nicht darum ob ein 4-bit oder 8-bit Rechner das noch schaffen kann oder nicht. Die 4-bit Rechner wuerden auch heute noch vieles schaffen wofuer schon lange AVRs oder 8051 eingesetzt werden. Aber die 8051 und AVRs sind einfach ein Standard geworden. Jetzt koennte sich ein neuer Standard auf 32-bit anbahnen, dann macht es wirklich nicht sehr viel Sinn bei vergleichbaren Kosten und Power noch einen 8-bit fuer neue Projekte einzusetzen. Wer natuerlich annimmt er braucht nie einen 32-bit, fuer den ist dieser Thread nicht angebracht. So wie der Schoepfer des erster PCs / DOS es fuer unvorstellbar hielt, dass der verfuegbare Speicher von 64K bzw. die DOS Grenze von 640K jemals ueberschritten werden koennte :-) Robert
>So wie der Schoepfer des erster PCs / DOS es >fuer unvorstellbar hielt, dass der verfuegbare Speicher von 64K bzw. die >DOS Grenze von 640K jemals ueberschritten werden koennte :-) Das Zitat ist genauso fehlerhaft wie deine Pro-32-Bit Liste im selben Beitrag. Es lautete, dass kein normaler Mensch je mehr als 640K wirklich benötigen werde. Dass es locker möglich ist, mehr als das tausendfache zu verschwenden, war damals auch schon klar. >Warum 32-bit fuer kleine Anwendungen? Ich wuerde die Frage mal anders >rum stellen. >Was bringt es mir meine getesteten Code Bausteine immer wieder benuetzen >zu koennen? Ne Menge Copy&Paste bringt es. Ein Programm als Gesamtkonzept ist eben mehr als die Summe der Einzelteile. >Was bringt es mir immer dieselben Tools zu benutzen fuer meine 8k >Anwendungen und fuer meine 512K Anwendungen? Sicher bringt es auch Bequemlichkeit, was nicht immer der Qualität zuträglich ist. >Was bringt es wenn meine Ingenieure eine Architektur wirklich toll >beherrschen anstelle von Architekturen recht ordentlich? Sie werden immer versuchen, Probleme genau damit zu lösen. >Was bringt Standardisierung? Mehr Pflicht, weniger Spaß. >Wer natuerlich annimmt er braucht nie einen 32-bit, fuer den ist dieser >Thread nicht angebracht. Ist bei mir keineswegs der Fall, habe schon alle Abstufungen von 8 bis 32 Bit eingesetzt. Immer das, was halt am besten passt. Man muss halt schon mal ein paar Tage Recherche einplanen, da geht es sicher schneller sich einfach einen fetten 32Bitter von ner Liste zu schnappen. Ich verstehe unter einem ordentlich durchdachten Design aber was anderes. Hier noch bissl was zum lesen: QUESTION: I read in a newspaper that in 1981 you said, ``640K of memory should be enough for anybody.'' What did you mean when you said this? ANSWER: I've said some stupid things and some wrong things, but not that. No one involved in computers would ever say that a certain amount of memory is enough for all time.
Ich pflichte Robert in allen Punkten bei. Es dauert so seine Zeit, bis man sich in eine MCU-Familie und deren Toolchain eingearbeitet hat. Und ehrlich gesagt fehlt mir die nötige Zeit und (vermutlich die nötige) Brainpower, um für jedes Projekt die geeignete MCU-Familie auszusuchen. Deshalb waere es ideal, wenn man in einer 32bit Familie zu hause waere, die preislich und leistungsmaessig eine grosse Flaeche abdeckt. Und dieser LPC1100 ist ein Argument mehr, um nun endlich mal die AVR-Welt hinter sich zu lassen.
@ DAC (Gast) >>Was bringt es mir meine getesteten Code Bausteine immer wieder benuetzen >>zu koennen? >Ne Menge Copy&Paste bringt es. Käse. Schon mal was von modularem Aufbau gehört? Wozu ein Programmteil 10mal neu erfinden? Bibliotheken? >>Was bringt es mir immer dieselben Tools zu benutzen fuer meine 8k >>Anwendungen und fuer meine 512K Anwendungen? >Sicher bringt es auch Bequemlichkeit, Nicht nur. Es bingt aus eine meist sinnvolle Vereinheitlichung. >>Was bringt Standardisierung? >Mehr Pflicht, weniger Spaß. Unsinn. Ingenieure sind keine freien Künstler, die vollkommen losgelöst von der Realität sich frei entfalten können und wollen! Daß es zu jeder Sache immer Pro und Kontra gibt ist klar, da ist Standardisierung keine Ausnahme. Sie bringt u.a. vor allem auch eine Vereinfachung und Entlastung beim Lösen bekannter Problemstellungen. >Ist bei mir keineswegs der Fall, habe schon alle Abstufungen von 8 bis >32 Bit eingesetzt. Immer das, was halt am besten passt. Man muss halt >schon mal ein paar Tage Recherche einplanen, da geht es sicher schneller >sich einfach einen fetten 32Bitter von ner Liste zu schnappen. Richtig! MFG Falk
Mehmet Kendi schrieb: > Und dieser LPC1100 ist ein Argument mehr, um nun endlich mal die > AVR-Welt hinter sich zu lassen. Warum sollte man denn sowas tun? Wenn man sich mit den AVRs auskennt, gibt es keinen Grund, auch nicht weiterhin Projekte damit zu machen, für die er geeignet ist. Man hat Erfahrungen, wo die Fallgruben liegen und wie stabil er arbeitet (never change a winning team). Ich werde 32Bitter nur da einsetzen, wo sie auch Vorteile haben. Es bringt ja nichts, einen ATtiny25 durch nen LPC zu ersetzen und dafür eine erheblich komplexere und damit deutlich länger dauernde Programmierung in Kauf zu nehmen. Programmierzeit ist auch Geld. Wenn ich mir z.B. diesen Thread hier ansehe, kann ich mir nur an den Kopf fassen: Beitrag "CMSIS und die Interrupt-Prioritäten" Ich hab ja den ersten Beitrag echt für einen Joke gehalten (linksbündige Interrupts). Ich verstehe nicht, wie man als Programmierer die Prioritäten mit der Gießkanne verteilt, damit die dann hinterher auf die tatsächlich verfügbaren runtergebrochen werden. Wenn ich Prioritäten vergebe, dann denke ich mir auch was dabei und verlange auch, daß nicht plötzlich doch Interrupts wieder die gleiche Priorität haben können. Peter
Peter Dannegger schrieb: > Ich werde 32Bitter nur da einsetzen, wo sie auch Vorteile haben. > Es bringt ja nichts, einen ATtiny25 durch nen LPC zu ersetzen und dafür > eine erheblich komplexere und damit deutlich länger dauernde > Programmierung in Kauf zu nehmen. Programmierzeit ist auch Geld. Okay, ATtiny25 ist jetzt ein krasses Beispiel. Und da waere ein Einsatz eines LPC wohl sicherlich 'etwas' daneben. Meine obige Konklusion kommt wohl daher, dass meine Porjekte so ab Atmega32 anfangen. Und ich in der Mehrzahl meiner Projekte stets nach mehr RAM und mehr MHz gelechzt habe. Wenn Du die zeitlichen und geistigen Mittel dazu hast, zwischen den 8-bit und 32-bit Welten je nach Bedarf hin und her zu wechseln: ich beneide Dich! Würde ich auch gerne.
Peter Dannegger schrieb: > Ich hab ja den ersten Beitrag echt für einen Joke gehalten ("linksbündige > Interrupts). Das steht da nirgends drin. Drin steht etwas von linksbündigen Prioritäten, nicht von linksbündigen Interrupts. Darf ich davon ausgehen, dass du die in vielen ADCs verfügbare "linksbündige Spannung" (d.h. die linksbündige Darstellung des Ergebnisses) ebenfalls für einen Witz hältst? Da steckt letztlich die gleiche Systematik dahinter. > Wenn ich Prioritäten vergebe, dann denke ich mir auch was dabei und > verlange auch, daß nicht plötzlich doch Interrupts wieder die gleiche > Priorität haben können. Ich konnte gut nachvollziehen, was der Designer des NVIC sich dabei gedacht hatte, immerhin geht die linksbündige Darstellung auf ihn zurück, nicht auf mich. Aber egal ob links- oder rechtsbündig: Meine Kritik richtete sich primär an die Verwirrung durch diesbezüglich unterschiedliche Konventionen von NVIC und CMSIS. Dieser Designer hat damit ein Modul entwickelt, dessen Schema unabhängig von der Anzahl real implementierter Bits für alle Cortexe den gleichen Gesamtraum realisiert. Das halte ich weder für zufällig, noch für irgendwie hardwaremässig effizienter, sondern für Absicht.
A. K. schrieb: > Das steht da nirgends drin. Drin steht etwas von linksbündigen > Prioritäten, nicht von linksbündigen Interrupts. Sorry, Schreibfehler. > Darf ich davon > ausgehen, dass du die in vielen ADCs verfügbare linksbündige Darstellung > des Ergebnisses ebenfalls für einen Witz hältst? Da steht letztlich die > gleiche Systematik dahinter. War jetzt nicht so bierernst gemeint. Ich wollte nur drauf aus, daß manche Sachen beim 32Bitter ungewohnt komplex sind und man sich erstmal wundert, was das überhaupt soll. Ich hab mir das aber noch nicht angesehen, daher weiß ich nicht, was linksbündige Prioritäten bedeutet. Beim 8051 habe ich für jeden Vector 2 Bits und stelle damit Priorität 0..3 ein, fertig. Ich lese z.B. einen 1-wire Sensor im Timerinterrupt aus und dabei kommt es auf µs an. Deshalb hat dieser als einziger die Priorität 3 und alle anderen Interrupts nur 0..2. Peter
Peter Dannegger schrieb: > Ich hab mir das aber noch nicht angesehen, daher weiß ich nicht, was > linksbündige Prioritäten bedeutet. Der NVIC definiert Prioritäten als 8-Bit Werte. Von denen aber nur N Bits implementiert sind (Cortex-M3: wählbar, STM32=4; Cortex-M0: fix=3). Und diese N Bits stehen linksbündig im betreffenden Register, d.h. beim CM0 werden effektiv die Werte 0x00,20,40,60,80,A0,C0,E0 unterschieden. CMSIS bildet diesen Wertebereich in Parameter/Ergebnis auf 0..7 ab. Folglich hat man je nach Blickwinkel 0x60 oder 3 dastehen, beim Debugging steht im NVIC 0x60, im Quellcode und irgendwelchen Variablen 3.
@Falk Brunner >Käse. Schon mal was von modularem Aufbau gehört? Wozu ein Programmteil >10mal neu erfinden? >Bibliotheken? Meine Aussage war etwas provokativ (aber nicht aggressiv gemeint), weil die Frage des TE sich aus Sicht eines jeden Programmierers selbst beantwortet. Genau aus den Gründen die du eben genannt hast. Die wiederum aber nicht fest an eine einzige Architektur gebunden sind, daher wollte ich einen Kontrapunkt setzen. >Unsinn. Ingenieure sind keine freien Künstler, die vollkommen losgelöst >von der Realität sich frei entfalten können und wollen! Ich bin Entwickler, ich entfalte mich in der Realität, wenn du so willst. >Daß es zu jeder Sache immer Pro und Kontra gibt ist klar, da ist >Standardisierung keine Ausnahme. Eben, darüber würd ich auch nicht streiten wollen. >Sie bringt u.a. vor allem auch eine Vereinfachung und Entlastung beim >Lösen bekannter Problemstellungen. Das ist die Intention dahinter, klappt mal mehr - mal weniger. >Käse. >Unsinn. Ist das der Ausdruck des letzten Rests Kreativität, der dem Ingenieur von heute noch bleibt? ;)
Robert Teufel schrieb: > @Krishna > Soll 45 DMips koennen und Compiler von Keil, IAR und noch ein paar mehr > gibt's auch. > Robert Und das kostet Schotter, ist proprietaer und laeuft nur unter Windows. Ausserdem eine neues und damit sicherlich noch reichlich fehlerhaftes Silizium gepaart mit einer Alpha-Toolchain. Da kommt Freude auf! Da sag ich: nein danke ;)
Michael G. schrieb: > gepaart mit einer Alpha-Toolchain. So schlimm kann es kaum sein, denn der Cortex M0 ist nicht viel anders als ARM7TDMI ohne ARM, nur Thumb-Modus. Existiert also im Compiler schon. Und für die Systemumgebung nimmt man den Kram vom Cortex M3, wirft die nicht existierenden Teile vom Systeminterface raus und fertig. Es ist eher andersrum: Mancher Compiler hat den Schritt von Thumb1 zu Thumb2 (Cortex-M3) immer noch nicht so weit verdaut, dass er dessen Möglichkeiten effektiv nutzen würde (GCC beschränkt sich meiner Erkenntnis nach auch dann auf R0-R7 wenn R8-R12 wirklich opportun wären).
@A. K., danke für die Erklärung, so kompliziert ist das also garnicht. Mir gefällt allerdings auch die Darstellung 0..7 besser. Beim 8051 muß man die Priorität sogar in 2 Registern setzen (ein Register pro Bit), d.h. da ist die Umrechnung noch "komplizierter". Ich bin aber auch nicht derjenige, der große Programme schreibt und sich dann mühsam mit dem Debugger durchkämpft. Ich schreibe lieber kleine Module, die ich einzeln teste. Dann habe ich beim Zusammenbau zum kompletten Programm wenig in den Eingeweiden rumzuwühlen. Es sind fast nur logische Fehler (z.B. ein ! an der falschen Stelle). Peter
Peter Dannegger schrieb:
> danke für die Erklärung, so kompliziert ist das also garnicht.
Nö. Allerdings war das nur die vereinfachte Kurzfassung. Man kann diese
N Bits noch ein zwei Teile spalten, eine Ebene für's Nesting und eine
Priorität innerhalb der Ebene ohne Nesting. Muss man aber nicht tun.
Lustiger ist was anderes: Dieser NVIC ist der vielleicht einzig
existierende Interrupt/Exception-Controller, bei dem auch synchrone
Core-Exceptions wie irregeleitete Speicherzugriffe oder Division durch 0
frei wählbare Prioritäten haben. Das kann also heissen, dass solche
Exceptions in einem ggf. höher priorisierten Interrupt-Handler nicht auf
den passenden Handler verzweigen können - das gibt dann allerdings
trotzdem eine Exception, aber ersatzweise als Hardfault.
Sinnlos ist das nicht, nur ungewöhnlich, denn so kann man in Umgebungen
mit User/System-Trennung wie Linux gleich von vorneweg zwischen
kritischen (im Systemkontext) und unkritischen Exceptions (normaler
Prozess) unterscheiden, ohne das jeweils im Handler abfragen zu müssen.
Man spürt, dass in das NVIC Design eine Menge Erfahrungen aus der
Vergangenheit eingeflossen sind. Auch in Hinblick auf effiziente
Implementierung eines RTOS ohne dabei wie sonst oft jeden
Interrupt-Handler aufblasen zu müssen (PendSV). Und es wird klar, dass
Anwender ohne entsprechendem Background solche Aspekte nicht oder nicht
ohne Erklärung verstehen werden.
A. K. schrieb: > Das kann also heissen, dass solche Exceptions in einem ggf. höher > priorisierten Interrupt-Handler nicht auf den passenden Handler > verzweigen können - das gibt dann allerdings trotzdem eine > Exception, aber ersatzweise als Hardfault. Das hat sogar noch einen weiteren Vorteil, der diesen Teil des Threads möglicherweise wieder auf das eigentliche Thema zurückführt: In softwaremäßig eher einfach gestrickten Systemen kann ich alle System Exceptions, die ich nicht gesondert behandeln möchte, auf den Hardfault Handler abbilden. Damit erspare ich mir, erstmal die ganzen Handler aufzusetzen -- ohne jedoch die Information über sie ganz zu verlieren. Gruß Marcus http://www.doulos.com/arm/ PS: Cortex-M0 implementiert nur zwei Bits, und die Prioritätsregister lassen sich sich nicht unterteilen. Man hat also effektiv immer vier preemptive priorities.
Gastino schrieb:
> Eine Innovation wäre ja mal ein 32-Bit-uC als DIP.
Gibt es doch. Sogar 8 einzelne 32bit Prozessoren auf einem Chip, und mit
32kByte RAM. Das ganze im DIP40 Gehäuse.
Kostet auch nur 99 cent ($-cent) pro Prozessor (also knapp 8$ für den
ganzen Chip) und das bei 1 Stück.
Optimiert für Bit-Banging, dafür sonst wenig Peripherie integriert.
Kurz: mein Lieblingsprozessor, der Parallax Propeller Chip.
Andi
Andi schrieb:
> Kurz: mein Lieblingsprozessor, der Parallax Propeller Chip.
Er hat seinen Charme, das muss man sagen. Aber es gibt halt gerade mal
einen Chip in der Familie und die Plaene zur Weiterentwicklung wurden
ziemlich gestutzt, nachdem man gemerkt hat, dass gewisse Ziele
unrealistisch waren ;) Ausserdem hat er halt einfach zu wenig RAM und
ist auf ein externes EEPROM zur Programmablage angewiesen. Dann wird das
meiste der Rechenleistung durch den (HW)-Interpreter der Spin-Sprache
wieder verschenkt.
Am Rande: Ich hab nen weitgehend kompletten Parser fuer Spin geschrieben
(JavaCC), wer einen Compiler fuer nativen Maschinencode entwickeln will
kann sich bei mir melden :P
Michael
@DAC, ist es moeglich, dass Du in einer kleinen Firma arbeitest? Einfach nur zu meinem Verstaendnis, wie ist dieser Satz zu verstehen: "..... genauso fehlerhaft wie deine Pro-32-Bit Liste im selben Beitrag." Wie koennen Fragen falsch sein? Ich hab mit sehr grossen Kunden gearbeitet, die hatten Stueckzahlen, die es in Deutschland wohl nicht in einer einzigen Anwendung gibt (40 Mio MCUs / Jahr). Da lohnt es sich einen absolut massgeschneiderten Chip einzusetzen, keine Diskussion. Da wuerde ich auch einen 8-bit Rechner einsetzen wenn er kann was verlangt wird, wenn ich auch nur einen Cent einsparen kann, denn 1 cent enspricht dann 400000 (es waren $) Andererseits haben sich auch schon viele kleine und mittlere Firmen mit der Vielfalt ihrer Architekturen totentwickelt. Warum denkst Du gibt es bei allem grossen Firmen starke Bestrebungen die Anzahl der Architekturen klein zu halten bzw. sie du reduzieren? Wenn ich aber nur wenige Architekturen einsetzen darf, dann ist doch ein logischer Fokus auf Architekturen mit grosser Bandbreite und grosser Preisspanne. p.s. sorry, dass meine Quotation etwas zu frei uebertragen war. @Falk, ich denke mal Du arbeitest in einer groesseren Firma :-), da gibt es einfach Regeln fuer Wiederverwendung von Code. @Peda, auch ich hab viel mit dem 8051 programmiert und der Umstieg auf 32-bit erschien erst mal kompliziert. Ist nicht alles was anders ist erst mal kompliziert? Versuchs doch mal damit, das Wort kompliziert und das Wort komplez mit dem Wort "anders" zu ersetzen. Nur so ein Vorschlag die Welt etwas positiver zu sehen. Gruss, Robert
@ Robert Teufel (robertteufel) >@Falk, >ich denke mal Du arbeitest in einer groesseren Firma :-), da gibt es >einfach Regeln fuer Wiederverwendung von Code. Wenn 80 Leute für dich gross sind . . . Nööö, das ist ein Grundprinzip. Und unser Chef drängt auch immer auf Wiederverwendung von Hard- und Software, manchmal ein wenig zu viel. Aber im Prinzip ist das schon richtig, denn auch bei uns gibt es viel Kleinkram, den man besser nicht ausufern lässt. MFG Falk
Marcus Harnisch schrieb: > PS: Cortex-M0 implementiert nur zwei Bits [...]. Man hat also effektiv > immer vier preemptive priorities. Ich hatte die 3 Bits aus dem Datasheet des LPC1100 abgeleitet, dort werden nämlich ausdrücklich 8 Prioritäten erwähnt. Die ARMv6-M Referenz spricht aber tatsächlich nur von 2 Bits.
@Robert >ist es moeglich, dass Du in einer kleinen Firma arbeitest? Vieles ist möglich. Zu meinen Kunden gehören durchaus auch Größere. Hab den Eindruck, manch Einer hier hat Probleme über seinen Tellerrand zu schauen. >Einfach nur zu meinem Verstaendnis, wie ist dieser Satz zu verstehen: >"..... genauso fehlerhaft wie deine Pro-32-Bit Liste im selben Beitrag." Sagte ich oben schon, dass mein Beitrag eine kleine Provokation enthielt um mal einen Kontrapunkt zu setzen. >Wie koennen Fragen falsch sein? Du hast hier keine reinen Fragen gestellt, sondern damit implizit etwas aussagen wollen. Genau wie in folgendem Zitat von dir: >Andererseits haben sich auch schon viele kleine und mittlere Firmen mit >der Vielfalt ihrer Architekturen totentwickelt. Warum denkst Du gibt es >bei allem grossen Firmen starke Bestrebungen die Anzahl der >Architekturen klein zu halten bzw. sie du reduzieren? WO lässt du denn hier bitte noch Platz für eine Antwort?
Hab lieber den alten Thread benuetzt als einen neuen aufzumachen. Ab morgen gibt es die Moeglichkeit sich fuer einen Design Wettbewerb fuer den LPC1100 einzutragen, es gibt auch einige Gewinne. Bedingung: Registrieren und eine kurze Beschreibung eines moeglichen Projektes. Dann stehen 2000 Platinen mit Tools LPCXpresso zu Verfuegung. Info ueber den LPC1100 gibts unter anderem hier: http://mcu-related.com/architectures/35-cortex-m3/92-lpc1100 Die homepage ueber den Design Wettbewerb gibt's hier: http://www.lpc1100challenge.com/
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.