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 ...
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 ;)
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.
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
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
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.
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 ;-).
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.
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
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?
Hallo,
Lt. OpenOCD Dokumentation sollte dieser Amontec gehen:
http://www.amontec.com/jtagkey.shtmlhttp://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.
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.
@ 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.
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.
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?
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
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.
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.
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 ;)
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.
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
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.
