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 ;)
>Contra LPC17*: >- nur als 80 oder gar 100 Pinner erhältlich Könntest ja auch die LPC13xx nehmen, die gibt's auch "kleiner".
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.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.
@Plan: Gibts eigentlich für die Firmware-Libs irgendwo ne Doku? Oder muss man sich durch die Beispiele durchwühlen? Gruß Tom
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.
@Plan: Dank Dir, ich hatte das .chm nicht als Doku verstanden.
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?
Für STM32 siehts besser aus http://www.tme.eu/de/katalog/index.phtml#cleanParameters%3D1%26search%3DSTM32F%26bf_szukaj%3D+
Arne schrieb: > BTW: Gibt es in D Bezugsquellen für LPC17xx? Mal abgesehen von digi-key > und anderen Importeuren? Farnell bzw. hbe
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 ;)
Arne schrieb:
> Dann kannst Du gleich wieder den LPC17xx nehmen ;)
Touché! Die beiden sind dort wieder sehr überschaubar...
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.