Forum: Mikrocontroller und Digitale Elektronik Cortex M3 Hobby: STM32* oder LPC17* ?


von Manfred Sch. (Gast)


Lesenswert?

Hallo,

wie der Titel schon sagt: Ich will jetzt von den AVR (ATmegas) zum 
Cortex M3 wechseln. Nur kann ich mich erstmal generell nicht zwischen 
den beiden genannten entscheiden, weil beide ihre Vor- und Nachteile 
haben (andere habe ich mittlerweile ausgeschlossen). Ja ich weiß: "Dann 
nimm doch einen von beiden und gut ist's". So langsam komme ich auch an 
den Punkt. Ich bin ehrlich offen und will keine Glaubenskriege, deshalb 
hier meine bisherige Abwägung:

Pro LPC17*:
- hat eine gute RTC (Verständlichkeit)
- billiger, ist aber bei meinem Hobbydurchsatz absolut egal
- bis 100 MHz (neuerdings sogar 120). Aber ob ich die wirklich 
brauche...

Contra LPC17*:
- nur als 80 oder gar 100 Pinner erhältlich
- hat 5 zerstückelte 32 bit-Ports, um zum LPC2irgendwas kompatibel zu 
bleiben; es fehlen immer irgendwo Pinnummern (auch noch abhängig, ob 80 
oder 100 Pinner)
- noch nicht so etabliert, nicht so viel Beispielcode zu finden
- weniger RAM im Verhältnis zum Flash

Pro STM32*:
- ist in vielen Gehäusegrößen zu kriegen
- hat (vollständige) 15 bit Ports
- enorm viel Beispielcode im Web
- hat sich schon als "vernünftig" bewiesen
- Mehr RAM im Verhältis zum Flash
- deutlich besseren ADC (mehr, synchron, schneller etc.)

Contra STM32*:
- RTC ist eine Frechheit, einfach nur ein Counter
- etwas teurer, aber wie gesagt egal
- Nur bis 72 MHz

Daneben gibt es natürlich noch unsäglich viele Geschmacksfragen, von 
denen ich aber wohl gar nicht alle wirklich beurteilen kann, z.B.
- LPC hat einen Bustakt bis max. 100 MHz (120), STM hat 2 (einer max. 72 
MHz und einer max. 36 MHz
- beim LPC muß man bei GPIO immer eine Maske benutzen, beim STM nicht
- LPC wirkt generell deutlich "moderner"; schwer in Worte zu fassen
- STM wirkt auf mich weniger komplex und einfacher zu Programmieren.

Nachdem ich das jetzt mal so zusammengeschrieben habe, würde ich eher 
den STM nehmen ...

von Koch (Gast)


Lesenswert?

Bin jetzt vllt. kein Erfahrener Microcontroller-typie, aber der LPC17 
scheint nicht so wirklich Vorteile zu bringen.

Der Preis ist nicht wichtig, und die Geschwindigkeit nicht nötig, die 
RTC, Naja ist halt umständiger mit dem anderen, gibt jedoch bestimmt 
Beispielcode für ;)

von Jörg S. (joerg-s)


Lesenswert?

>Contra LPC17*:
>- nur als 80 oder gar 100 Pinner erhältlich
Könntest ja auch die LPC13xx nehmen, die gibt's auch "kleiner".

von (prx) A. K. (prx)


Lesenswert?

Die LPC1300 sind aber auch drinnen kleiner, nur 32KB, kein CAN. Bei den 
STM32ern gibt es 48-Pinner mit dem vollem Funktionsumfang der 103er bis 
128K Flash.

Auffällig ist der Unterschied beim ADC. Die STM32 haben einen 12-Bit ADC 
mit +/-2 LSB abs error, die LPC1300 einen 10-Bit ADC mit +/-4 LSB.

von Robert T. (robertteufel)


Lesenswert?

Schon mal dran gedacht beide zu nehmen ?  ;-)

Manfred Sch. schrieb:
> Hallo,
------snip------------->
Pro LPC17*:
> - hat eine gute RTC (Verständlichkeit)
Halte ich fuer Hobbyeinsatz nicht fuer so wichtig!?
> - billiger, ist aber bei meinem Hobbydurchsatz absolut egal
> - bis 100 MHz (neuerdings sogar 120). Aber ob ich die wirklich
> brauche...
Mit Performance ist das so wie mit Geld. Wieviel braucht man wirklich? 
Es ist allerdings immer schoen noch etwas in Reserve zu haben.
>
> Contra LPC17*:
> - nur als 80 oder gar 100 Pinner erhältlich
Moechtest Du Dir die Platinen selbst bauen? Die Nachfrage nach SW-Ing. 
mit Hardware Kenntnissen ist VIEL hoeher als die Nachfrage nach 
Board-Designern. Also fang mit einem Eval-Board an. Jetzt sind die 
kleinen Gehaeuse ploetzlich voellig unwichtig, die grossen bieten 
einfach mehr I/O
Kleine Gehaeuse, schau dir die LPC1300 oder gar 1100 an. Die haben auch 
weniger Performance, falls das eine Anforderung ist.

> - hat 5 zerstückelte 32 bit-Ports, um zum LPC2 irgendwas kompatibel
> bleiben; es fehlen immer irgendwo Pinnummern (auch noch abhängig, ob 80
> oder 100 Pinner)
Welche Anwendung geht heute noch mit Parallelports raus? Brauchst du 
einen ext. Bus? Dann sind eigentlich die Vielpinner sowieso angesagt. 
Ansonsten Erweiterungen durch SPI oder I2C anschliessen.
> - noch nicht so etabliert, nicht so viel Beispielcode zu finden
> - weniger RAM im Verhältnis zum Flash
Versteh ich nicht so ganz. Bei ST gibts's ein paar Chips (noch nicht), 
die mehr als 64K SRAM haben. Bei NXP ein paar mit 64k wie auch bei ST. 
Verfuegbare Kombinationen sind bei beiden 512/64. Es gibt auch bei 
beiden 256/64. Woher kommt diese Aussage?
>
> Pro STM32*:
> - ist in vielen Gehäusegrößen zu kriegen
> - hat (vollständige) 15 bit Ports
Ooops, Seit wann ist ein 16-bit port vollstandig mit 15 bit
> - enorm viel Beispielcode im Web
Den besten Beispielcode fuer den STM32 findet man auf
http://www.stm32circle.com
> - hat sich schon als "vernünftig" bewiesen
na wat dat denn fuer ein Argument :-)
> - Mehr RAM im Verhältis zum Flash
s.o.
> - deutlich besseren ADC (mehr, synchron, schneller etc.)
Yeap, das sehe ich allerdings auch genauso. Klarer Vorteil fuer ST hier.

>
> Contra STM32*:
> - RTC ist eine Frechheit, einfach nur ein Counter
> - etwas teurer, aber wie gesagt egal
> - Nur bis 72 MHz
Hat in der seriellen Schnittstellen immer etwas weniger zu bieten.
Mag mehr zusammenhaengende aber insgesamt weniger I/O pins beim selben 
Package
>
> Daneben gibt es natürlich noch unsäglich viele Geschmacksfragen, von
> denen ich aber wohl gar nicht alle wirklich beurteilen kann, z.B.
> - LPC hat einen Bustakt bis max. 100 MHz (120), STM hat 2 (einer max. 72
> MHz und einer max. 36 MHz
> - beim LPC muß man bei GPIO immer eine Maske benutzen, beim STM nicht
> - LPC wirkt generell deutlich "moderner"; schwer in Worte zu fassen
> - STM wirkt auf mich weniger komplex und einfacher zu Programmieren.
Insgesamt weniger Features -> einfacher, das stimmt schon
>
> Nachdem ich das jetzt mal so zusammengeschrieben habe, würde ich eher
> den STM nehmen ...
Das musst du schon selbst entscheiden.

Warum nicht den Keil Simulator fuer beide mal anwerfen und ausprobieren.

Gruss aus California, Robert
Mehr Info zu verschiedenen Cortex-M3 Produkten gewuenscht ->
http://mcu-related.com/architectures/35-cortex-m3

von Thomas O. (tarzanwiejane)


Lesenswert?

Ich habe mich fuer den stm32 entschieden. Die Kompatibilitaet durch die 
ganze Serie hat schon was. Die RTC habe ich noch nie benutzt, aber die 
sollte doch mehr als ein Counter sein. Ich schau nachher noch mal in 
Handbuch...

cu Tarzanwiejane

von Manfred Sch. (Gast)


Lesenswert?

Robert Teufel schrieb:
> Schon mal dran gedacht beide zu nehmen ?  ;-)
Das mit der eierlegenden Wollmilchsau ist eine unendliche Geschichte. In 
der Theorie das Erstrebenswerte ...

>> - hat eine gute RTC (Verständlichkeit)
> Halte ich fuer Hobbyeinsatz nicht fuer so wichtig!?
Da ich (zumindest bei dem mir derzeit vorschwebenden Hobbyprojekt) sehr 
viel loggen möchte (Temperatur, Luftfeuchte, Zeit, Start- und 
Stoppzeitpunkt etc.), ist es für mich schon nicht unwichtig. Betonung 
richtigerweise auf derzeit. Klar, wenn man sich einmal einen 
vernünftigen Softwarelayer "drübergelegt" hat, ist das Problem auch aus 
der Welt. Ist ja auch ein Ziel des Hobbies.

>> - bis 100 MHz (neuerdings sogar 120). Aber ob ich die wirklich
>> brauche...
> Mit Performance ist das so wie mit Geld. Wieviel braucht man wirklich?
> Es ist allerdings immer schoen noch etwas in Reserve zu haben.
Da hast Du natürlich absolut recht; ist ehrlich gesagt, auch mein 
"Hauptzögerargument". Der Appetit kommt bekanntlich beim Essen. Und sei 
es nur temporär, in dem man vorerst eine fette Lib einbindet, um erstmal 
ein Ergebnis zu haben.

>> Contra LPC17*:
>> - nur als 80 oder gar 100 Pinner erhältlich
> Moechtest Du Dir die Platinen selbst bauen? Die Nachfrage nach SW-Ing.
> mit Hardware Kenntnissen ist VIEL hoeher
> als die Nachfrage nach Board-Designern. Also fang mit einem Eval-Board
> an. Jetzt sind die kleinen Gehaeuse ploetzlich voellig unwichtig,
> die grossen bieten einfach mehr I/O
"Bauen" ist wohl übertrieben; ich will selber was hinätzen, was 
hoffentlich funktioniert.

>Die Nachfrage nach SW-Ing. mit Hardware Kenntnissen ist VIEL hoeher
> als die Nachfrage nach Board-Designern. Also fang mit einem
> Eval-Board an. Jetzt sind die kleinen Gehaeuse ploetzlich
> voellig unwichtig, die grossen bieten einfach mehr I/O
Richtig, die sind ja auch viel weitläufiger einsetzbar. Aber für mich 
ist das Hobby und daher kein Thema.

> Kleine Gehaeuse, schau dir die LPC1300 oder gar 1100 an. Die haben auch
> weniger Performance, falls das eine Anforderung ist.
Ja, aber ich hätte gerne CAN und das ist mit den Dingern echt nicht gut. 
Außerdem möchte ich bei einer Familie bleiben, ist als Hobby deutlich 
einfacher und auch billiger.

>> - weniger RAM im Verhältnis zum Flash
> Versteh ich nicht so ganz. Bei ST gibts's ein paar Chips (noch nicht),
> die mehr als 64K SRAM haben. Bei NXP ein paar mit 64k wie auch bei ST.
> Verfuegbare Kombinationen sind bei beiden 512/64. Es gibt auch bei
> beiden 256/64. Woher kommt diese Aussage?
Ich bleib bei meiner Hobbysicht (kleine Brötchen): Ein LPC mit
32 kB Flash hat 8 kB RAM, mit
64 kB FLASH 16 kB RAM, mit für mich unerreichbaren
128 kB Flash 32 kB RAM.
Ein STM (103) hat bei
32 kB Flash 10 kB RAM, bei
64 kB Flash 20 kB RAM und bei
128 kB Flash auch (nur) 20 kB RAM.
Also nach oben hin (quasi aus meinem Hobbybereich hinaus) sieht es für 
den LPC besser aus, in meinem Zielbereich aber für den STM.

>> - hat (vollständige) 15 bit Ports
> Ooops, Seit wann ist ein 16-bit port vollstandig mit 15 bit
Man wird sich doch mal vergrüßen dürfen ...

>> - STM 32 hat sich schon als "vernünftig" bewiesen
> na wat dat denn fuer ein Argument :-)
Keiner schreit "kannste nich gebrauchen, buggy ohne Ende, Datenblatt 
erlogen, unlogische Strukturen". Unter der Prämisse gemeint.

Es ist halt nicht leicht ...
Danke für die Anregungen.

von (prx) A. K. (prx)


Lesenswert?

Thomas Otto schrieb:

> Ich habe mich fuer den stm32 entschieden. Die Kompatibilitaet durch die
> ganze Serie hat schon was. Die RTC habe ich noch nie benutzt, aber die
> sollte doch mehr als ein Counter sein. Ich schau nachher noch mal in
> Handbuch...

Stimmt schon, das ist inhaltlich wirklich nur ein Counter mit Prescaler. 
Es läuft darauf hinaus, dass man für Uhrzeit von einen Wert "Sekunden ab 
irgendwann" in Datum/Zeit umrechnen muss (wie man es in Windows/Linux 
auch tut).

Es bedeutet andererseits, dass man diesen Counter und seinem auslesbaren 
Prescaler direkt als Quelle von Zeitverzögerungen (polling) mit einer 
Auflösung von ~30µs verwenden kann, ohne dazu einen weiteren Timer 
bemühen zu müssen. Und man Alarm-Zeiten (aufwecken in 30 Minuten) nicht 
erst von jetzt+1800 Sekunden in dd:mm:yy-HH:MM:SS-Format umrechnen muss.

So hat alles seine 2 Seiten ;-).

von Plan (Gast)


Lesenswert?

Hallo,

ich habe mich auch für den STM32 entschieden. Einmal musste ich in der 
Firma eine CPU verwenden die sehr schnell ist und einen guten AD Wandler 
hat.
Das Ende vom Lied ist, dass jetzt dieser Chip als Standard eingeführt 
wird...

Weil es da einfach superviel Chips, Gehäuse usw. gibt und man den Code 
sehr einfach ohne größeren Aufwand in allen Chips laufen lassen kann.

Hier im Forum gibt es auch eine gute Unterstützung, einfach mal den 
Filter "ARM" auswählen, die meisten Beiträge sind für den STM32.

Privat nutze ich jetzt auch nur noch den STM32. Siehe hier:
Beitrag "Re: Heizungssteurung im Eigenbau"

Der Vorteil von STM32 liegt vor allem in der Software. Dank FW-Lib von 
ST kommt man deutlich schneller zum Ziel. Im Hobby hat man zwar 
unendlich Zeit, aber dennoch ist es schön wenn man schnell zum Ergebnis 
kommt.

Die Programmierumgebung mit Eclipse/Coudesourcery/OpenOCD ist auch 
kostenlos. Es braucht nur noch ein JATG Adapter. Ich nutze den Olimex 
USB-ARM-OCD. (Aber damit kann man alle Cortex-M3 usw. proggen)

Ach ja, der STM32 hat noch ein Vorteil:
Die SDIO Schnittstelle um auf MMC-Card / SD-Card schreiben zu können. 
Hat der LPC17xx nicht. Ist in dem STM32 ab 256 KB Flash drin 
(HD-Device). Könnte auch für Log-Anwenungen intererssant sein.

von Seppel (Gast)


Lesenswert?

Hallo "Plan",

ich hab eine Prototypenboard und einen Amontec JTAG-Key, könntest Du mir 
sagen wie ich eine Toolchain ohne Codesourcery mit dem Debugger zum 
laufen bekomme? Eine freie, gut funktionierende Toolchain scheint es 
nicht zu geben.

Vielen Dank.

Grüße

Seppel

von Arne (Gast)


Lesenswert?

Manfred Sch. schrieb:
> Keiner schreit "kannste nich gebrauchen, buggy ohne Ende, Datenblatt
> erlogen, unlogische Strukturen". Unter der Prämisse gemeint.
Das nicht, aber bei den 103 kannste USB und CAN gleichzeitig abhaken. 
Ist echtes XOR Feeling: entweder USB ODER CAN. Die AD-Wandler sind m.E. 
komplex und kompliziert, dito Timer. Da gefällt mir der LPC17xx besser. 
Hat NXP die buggy CAN Schnittstelle der LPC 21xx hier korrigiert?

von Plan (Gast)


Lesenswert?

Hallo,

Lt. OpenOCD Dokumentation sollte dieser Amontec gehen:
http://www.amontec.com/jtagkey.shtml
http://www.amontec.com/jtagkey2.shtml

Auf der Amontec Seite:
http://www.amontec.com/openocd.shtml
müsste beschrieben sein wie man die GDB Befehle verwenden muss.

Ich habe keinen Amontec, daher kann ich das nicht nachvollziehen. Sicher 
kann man hier (http://www.amontec.com/contact.shtml) auch mehr erfahren.

>Toolchain ohne Codesourcery
Welchen Compiller möchtest Du gerne verwenden? Codesourcery light ist 
zumindest eine kostenloser Compiller.

Eclipse ist nur der Editor. OpenOCD und Coudesourcery werden darin 
eingebunden, damit wird es erst eine vollwertige Toolchain.

>aber bei den 103 kannste USB und CAN gleichzeitig abhaken
Es kommt auf das Device drauf an. In der Connectivity Line gehen beide 
gemeinsam.

von Thomas B. (escamoteur)


Lesenswert?

@Plan: Gibts eigentlich für die Firmware-Libs irgendwo ne Doku? Oder 
muss man sich durch die Beispiele durchwühlen?

Gruß
Tom

von Manfred Sch. (Gast)


Lesenswert?

Plan schrieb:
> Die SDIO Schnittstelle um auf MMC-Card / SD-Card schreiben zu können.
> Hat der LPC17xx nicht. Ist in dem STM32 ab 256 KB Flash drin
> (HD-Device).
Hatte ich auch gelesen, ist dann aber erst ab den erwähnten 256 kB Flash 
drin und daher wieder out of range für Hobby. Andererseits: Der Preis 
von gaaanz wenigen µC pro Jahr ist auch egal und man kann sich dann auch 
die fertige Schnittstelle gönnen (und hat auch noch Reserven ohne Ende).

Arne schrieb:
> Das nicht, aber bei den 103 kannste USB und CAN gleichzeitig abhaken.
> Ist echtes XOR Feeling: entweder USB ODER CAN.
Zumindest derzeit ist USB für mich kein Thema, aber das Hobby wächst ja 
auch. Aber damit auch die Chips. Und die neuen können ja jetzt schon 
beides.

von Plan (Gast)


Lesenswert?

@ Thomas Burkhart:
Du hast die FW-Lib V 3.2 sicher schon von der ST Seite geladen und 
entpackt. Darin gibt es die Datei "stm32f10x_stdperiph_lib_um.chm". Über 
14 MB Doku.

>Hatte ich auch gelesen, ist dann aber erst ab den erwähnten 256 kB Flash
>drin und daher wieder out of range für Hobby.
Ich nutze den STM32F103RC mit 256 KB Flash in meinen Hobby Projekten.
Gibts bei Farnell.

von Thomas B. (escamoteur)


Lesenswert?

@Plan: Dank Dir, ich hatte das .chm nicht als Doku verstanden.

von thorstendb (Gast)


Lesenswert?

Hi,

STM32 hab ich schon einiges mit geproggt (ist mein Haupt-µC wenn ich was 
proggen will), und mir gefällt das dingen soweit gut (wenn man Sachen 
wie GPIO Config erst mal verstanden hat, die ist etwas komplexer als 
beim AVR).


LPC hab ich erst wenig mit gemacht.

LPC empfehle ich dir aber den Cortex-M3 LPC1x als Board von ARM, den 
mbed.
Den kann man auf ein Steckbrett stecken, braucht z.B. nur noch 
Netzwerkbuchse und USB Buchse ankabeln.

Z.Zt. gibt es ne gute community mit Code um das dingen, allerdings ist 
das mit einem (freien) Online-Compiler. Im Grunde der ARMcc aus dem 
RVCT, der da hinterhängt.

Läuft prinzipiell aber mit jedem Compiler, denn man muss lediglich das 
Image in das Flash Drive schieben, dass das Board am USB aufmacht, dann 
auf Reset drücken.

Für uVision habe ich mal ein Blinky geschrieben, dass für FlashDownLoad 
das Image rüberkopiert.


Debug gibtz derzeit leider (noch) nicht.



VG,
/th.

von Arne (Gast)


Lesenswert?

Plan schrieb:
>>aber bei den 103 kannste USB und CAN gleichzeitig abhaken
> Es kommt auf das Device drauf an. In der Connectivity Line gehen beide
> gemeinsam.

Richtig, da Manfred aber den 103 erwähnte...

BTW: Gibt es in D Bezugsquellen für LPC17xx? Mal abgesehen von digi-key 
und anderen Importeuren?

von Plan (Gast)


Lesenswert?


von Plan (Gast)


Lesenswert?


von Arne (Gast)


Lesenswert?

@Plan:
Danke! Leider keine 1768/1769 :-(

von Jörg S. (joerg-s)


Lesenswert?

Arne schrieb:
> BTW: Gibt es in D Bezugsquellen für LPC17xx? Mal abgesehen von digi-key
> und anderen Importeuren?
Farnell bzw. hbe

von Stefan V. (vollmars)


Lesenswert?

Manfred Sch. schrieb:
> Contra STM32*:
> - RTC ist eine Frechheit, einfach nur ein Counter

Ich favorisiere die STM32* Familie unter anderem wegen der RTC, die 
einfach die Sekunden zählt, damit wird die Software so viel einfacher 
wenn du Zeiten vergleichen willst oder Zeitabstände berechnen willst, 
ich sag nur Schaltjahr, Sommerzeit. Du brauchst nur 2 Routinen für die 
Ein- und Ausgabekonvertierung und die gibts in allen möglichen Varianten 
im Netz.

Gruß Stefan

von Pete K. (pete77)


Lesenswert?

Falls die RTC nicht gefällt kann man ja immer noch eine DS3132 oder 
DS1307 nehmen.

von Manfred Sch. (Gast)


Lesenswert?

Stefan V. schrieb:
> Ich favorisiere die STM32* Familie unter anderem wegen der RTC, die
> einfach die Sekunden zählt, damit wird die Software so viel einfacher
> wenn du Zeiten vergleichen willst oder Zeitabstände berechnen willst,
> ich sag nur Schaltjahr, Sommerzeit.
Unter dem Gesichtspunkt ist das sogar ein Vorteil (bzw. zumindest kein 
Nachteil), stimmt.

Pete K. schrieb:
> Falls die RTC nicht gefällt kann man ja immer noch eine DS3132 oder
> DS1307 nehmen.
Na ja, ich kauf doch aber keinen "Mörderchip" mit allem drauf und 
substituiere dann alle eigentlich "all inclusive" features durch 
stand-alone-Varianten. Andererseits ist der Gedanke (theoretisch) so 
schlecht auch nicht: Bevor man sich durch den STM-Timer oder den ADC mit 
all seinen gewaltigen Möglichkeiten gewühlt hat, kann man vielleicht 
doch einfach einen Standard-Timer und einen Standard-ADC nehemn, die 
wirklich nur das machen und daher super einfach zu konfigurieren sind 
(=> quasi einfach nur starten ...). Im Hobbybereich, wie gesagt. Im 
Professionellen wär's aber undenkbar.

von Plan (Gast)


Lesenswert?

Der AD-Wandler von STM32 finde ich nicht so schlecht.

Mit der Lib kann man den so konfigurieren, dass der endlos wandelt.
Dann kann man mehrere Kanäle wandeln.
Dann den DMA belästigen, der z.B. für 5 Wandlungen dann die in 5 RAM 
Adressen kopiert.
Der DMA macht das auch immer im Kreis.

Somit hat man an 5 RAM Adressen (am besten ein Array) immer die aktuelle 
Wandlung die man einfach nur aus liest.
Nur ein mal initialisieren und es läuft von alleine.

Ja, der AD-Wandler von ST sieht komplex aus, aber anhand der Demos kommt 
man schnell zu Ziel.
Es wird erst kniffelig wenn man die Injected-Channels nutzen möchte oder 
die Alarmfunktionen.

Der DMA kann auch ein Interrupt generieren, wenn alle 5 Wandlungen 
fertig sind, dann weiß man genau wenn garantiert neue Werte da sind.

von Arne (Gast)


Lesenswert?

Manfred Sch. schrieb:
> Bevor man sich durch den STM-Timer oder den ADC mit
> all seinen gewaltigen Möglichkeiten gewühlt hat, kann man vielleicht
> doch einfach einen Standard-Timer und einen Standard-ADC nehemn, die
> wirklich nur das machen und daher super einfach zu konfigurieren sind

Dann kannst Du gleich wieder den LPC17xx nehmen ;)

von Manfred Sch. (Gast)


Lesenswert?

Arne schrieb:
> Dann kannst Du gleich wieder den LPC17xx nehmen ;)
Touché! Die beiden sind dort wieder sehr überschaubar...

von Manfred Sch. (Gast)


Lesenswert?

Nachtrag zum Vergleich, hier CAN:
Wenn ich es nicht falsch verstanden habe, kann der LPC17* nur eine 
akzeptierte Nachricht puffern, weil im anderen Teil des 
Double-Receive-Buffer die nächste Nachricht eingelesen wird und erst 
dann auf Gültigkeit geprüft wird; also immer belegt ist. Wird auch diese 
Nachricht gültig, findet schon ein Overrun statt, da ja jetzt beide 
Buffer belegt sind und keine neue Nachricht mehr empfangen werden kann. 
Nun kann man bei den Taktfrequenzen ja bei eingehenden CAN-Nachrichten 
eher von "einsickern" sprechen, aber aufpassen muß man da schon (dauer 
von ISRen usw.). Andererseits will ich (momentan) auch gar nicht mit so 
hohen Taktfrequenzen fahren, da ansonsten unnötig. Da war ja selbst die 
Struktur des MCP2515 besser; der hat ein Register, wo jede Nachricht 
erstmal reinkommt und erst dann in einen der beiden Receivebuffer 
verschoben wird, wenn die Nachricht akzeptiert wurde.

Beim STM32* hingegen gibt es zwei dreistufige Receive-FIFOs. Die können 
auch wirklich voll genutzt werden, da nur akzeptierte Nachrichten dort 
landen.

von Robert T. (robertteufel)


Lesenswert?

Manfred Sch. schrieb:
> Nachtrag zum Vergleich, hier CAN:
> Wenn ich es nicht falsch verstanden habe, kann der LPC17* nur eine
> akzeptierte Nachricht puffern, weil im anderen Teil des
> Double-Receive-Buffer die nächste Nachricht eingelesen wird und erst
> dann auf Gültigkeit geprüft wird; also immer belegt ist. Wird auch diese
> Nachricht gültig, findet schon ein Overrun statt, da ja jetzt beide
> Buffer belegt sind und keine neue Nachricht mehr empfangen werden kann.
> Nun kann man bei den Taktfrequenzen ja bei eingehenden CAN-Nachrichten
> eher von "einsickern" sprechen, aber aufpassen muß man da schon (dauer
> von ISRen usw.). Andererseits will ich (momentan) auch gar nicht mit so
> hohen Taktfrequenzen fahren, da ansonsten unnötig. Da war ja selbst die
> Struktur des MCP2515 besser; der hat ein Register, wo jede Nachricht
> erstmal reinkommt und erst dann in einen der beiden Receivebuffer
> verschoben wird, wenn die Nachricht akzeptiert wurde.
>
> Beim STM32* hingegen gibt es zwei dreistufige Receive-FIFOs. Die können
> auch wirklich voll genutzt werden, da nur akzeptierte Nachrichten dort
> landen.

Nennen wir den CAN controller auf dem LPC17xx mal gewoehnungsbeduerftig 
aber auf keinen Fall ist er ohne sehr nette Feinheiten. Vorneweg, die 
Doku ist vielleicht nicht so ganz klar, doch es ist ein doppelter 
Buffer, overflow also erst wenn die 3. Message vollstaendig empfangen 
wurde und die erste noch nicht ausgelesen war.
Acceptance Filter: Da gibt es meistens CAN controller, die koennen auf 
32 verschiedene Messages Filtern oder eben alles reinlassen, was auf dem 
CAN Bus so abgeht. Die Filtermoeglichkeiten den LPC sind bisher von 
keinem anderen mir bekannten CAN Controller auch nur annaehernd 
erreicht. Wenn ich nicht ganz daneben liege, dann muss der uC mindestens 
8x (vielleicht auch 16x) die Taktrate von CAN laufen. Bei 8x hat man 
also bei back to back kuerzeste messages immer noch ca. 300 Zyklen (+ 2 
messages) zur Verfuegung um die erste Message auszulesen. Angenommen CAN 
wird per Interrupt bearbeitet!
Jetzt sind back to back messages schon mal nicht so haeufig und wenn sie 
kommen dann meistens mit max. Dateninhalt weil ein Datenblock 
uebertragen wird. Somit hat man ca 1000 Zyklen (+ 2 messages) Zeit um zu 
reagieren. Wenn man jetzt einen groesseren Datenblock per CAN 
uebertraegt, dann ist es auch sinnvoll dem CAN entsprechende Prioritaet 
zuzuschreiben.
Das wuerde ich also definitiv nicht als Limitierung sehen. Die 
Programmierung des CAN ist allerdings nicht so ganz ohne!

Robert

von Manfred Sch. (Gast)


Lesenswert?

Robert Teufel schrieb:
> Vorneweg, die
> Doku ist vielleicht nicht so ganz klar, doch es ist ein  doppelter
> Buffer, overflow also erst wenn die 3. Message vollstaendig empfangen
> wurde und die erste noch nicht ausgelesen war.

The Receive Buffer (RXB) represents a CPU accessible Double Receive 
Buffer.
***********************************************************
It is located between the CAN Controller Core Block and APB Interface 
Block and stores all received messages from the CAN Bus line.
With the help of this Double Receive Buffer concept the CPU is able to 
process one message while another message is being received.
***********************************************************
...
If there is not enough space for a new message within the Receive 
Buffer, the CAN Controller generates a Data Overrun condition when this
message becomes valid and the acceptance test was positive.
A message that is partly written into the Receive Buffer (when the Data 
Overrun situation occurs) is deleted.

Dann sollten die das aber in der Tat eindeutiger schreiben. Ich hatte es 
so rausgelesen, daß erstmal alles im Double Receive FIFO landet und dort 
bewertet wird. Ganz besonders wegen den Sätzen zwischen den Sternen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.