Ganz früher hab ich viel mit 51ern gemacht und mit ASM, Keil, IAR gearbeitet. Jetzt ist mir für eine automotive-Anwendung der ganze Overkill von stromintensiven Prozessörchen mit anstrengenden IDE zu viel, ich habe mir von Silabs ein EFM8BB52 - Demoboard herausgesucht und würde gerne wieder in Pascal programmieren. Ob ich mit Turbo51 da zum Ziel komme? Oder lohnt sich das Geld für den mikroE - Compiler? Warum kein C: ist mir zu unliterarisch und C++ zieht unnötig viel Zeug dazu / ist ineffizient, wenn man in Maschinen(raum)nähe bleibt. Früher hab ich zum Teil auch INLINE verwendet. Hat jemand aktuelle Erfahrung mit RTOS auf 8051-Kernen? Silabs gibt an, daß das geht. Deren IDE hab ich noch nicht installiert, weil mein APEX /trendmicro meint, daß es unsicher ist. Muß ich erst einen "Inselrechner" ertüchtigen, den ich zur Not auch wieder plätten / aufgeben kann. Der Chinese ist neugierig? - Der job: PWM-codierte Sensoren lesen und an einen CAN Netzwerk-ast abgeben. Evtl. noch ein kleines Display bespielen. - Dank für valide Kommentare! moppi
Braucht man für CAN nicht spezielle Peripherie im µC? Eine CAN Einheit sehe ich da nämlich nicht. Die Can Tranceiver schlucken IIRC auch so viel Strom das es auf den µC überhaupt nicht mehr ankommnt (Faktor >10). Wenn der Virenscanner übers Simplicity Studio meckert sollte man das dem Hersteller als false Positive melden. Fast sicher ein Fehlalarm, das ist AFAIK nur gebrandetes Eclipse. Für RTOS sehe ich keinen Platz in einem µC der nur 2K XRAM hat. Da kennt man doch noch jedes Byte einzeln mit Namen! Man erinnere sich auch daran das memcpy() von und zum XRAM auf den Dingern derart lahm ist das oft der Watchdog zuschlägt bevor die Startup Routine den RAM vom Flash initialisiert hat... Das war jedenfalls ein Problem mit den C8051gern. Ich würde auch zu Bedenken geben das es durchaus RTOS Support für die EFM32 gibt, z.B. Zephyr. Keine Ahnung ob da welche CAN Support hatten.
Jochen W. schrieb: > Oder lohnt sich das Geld für den mikroE - Compiler? eher nicht, weil du damit nur unterstützte Controller programmieren kannst. Die EFMxxx gehören nicht dazu. Nachrüsten geht auch nicht so ohne weiteres da die CPU Dateien nicht im Quellcode vorliegen. Das kannst du aber selber ausprobieren die haben eine Demoversion. Generell halte ich von MikroE Compilern nicht so viel. Der Turbo51 Compiler ist ganz ok aber nicht besonders gut dokumentiert.
Ja, eine CAN-Karte wird gebraucht, gibts fertig sogar für "SPI-huckepack" mit MCP2518 und trx, das wär nicht das Problem. Die älteren 51 Derivate AT89... mit internem CAN können meist nur Standard-CAN und kein FD. Auf der Karte ISOLATED-CAN-EK von Silabs ist ein EFM32 mit CAN-Hardware zusammengespannt. Die eur für was Fertiges wären nicht das Problem. Overkill? Und Pascal fällt auch aus... bzgl. Strom: ich meinte nur, daß ich nicht unbedingt Mehrkernprozessoren benötige für mein bischen Aufgabe. Noch ist das Kind nicht in den Brunnen gefallen, ich muß das EFM8 ja nicht nehmen und kann ggf. noch eine andere Plattform wählen. Danke für die Compiler-Einschätzung. Bei MikroE brauche ich wg. der EFM8 wohl nicht anzuklopfen, deren letzte Version ist ja auch schon gut abgehangen. (Pflege?) RTOS war nur eine Randnotiz... danke für den Hinweis auf die EFM32. Ich werd die Apex-Meldung zu simplicity mal an Silabs schicken.
SPI-CAN ist eine Notlösung. Das nimmst Du dann und genau nur dann, wenn alle anderen sinnvollen Möglichkeiten ausgeschöpft sind. Wenn Du CAN-FD brauchst, nimm einen Controller, der den MAC eingebaut hat. Da gibts ja genug von. Wenn Du was kleines mit wenig Pins, einmal CAN-FD und automotive Qualifizierung -40°C...+150°C brauchst, gäbe es da z.B. https://www.microchip.com/en-us/product/dspic33ck256mp502 Pascal ist da aber eben nicht drin. fchk
Hmmm, was meinst Du mit MAC? Ich brauche neben dem uController einen CAN-Controller und den Transceiver. MAC ist bei mir mit IEE802.3 interface (OPEN) oder media access control (ISO11898) begrifflich belegt... Wo siehst Du denn die Nachteile der "Notlösung?" Ob ich FD wirklich brauche weiß ich nicht, da ich mich mit nagelneuen Denso-Steuergeräten vertragen muß, zu denen es keine Infos gibt. Es kann sein, daß für updates die Rate angehoben wird. Sonst 500k. dsPic33 kenne ich. Dafür müßte ich erst noch eine Karte anfertigen. :o(
Jochen W. schrieb: > von > stromintensiven Prozessörchen Aktuelle 32bitter haben einen ähnlichen oder sogar geringeren Verbrauch bei dramatisch höherer Leistung und angenehmerer Programmierung. Jochen W. schrieb: > C++ zieht unnötig viel Zeug > dazu / ist ineffizient, wenn man in Maschinen(raum)nähe bleibt. Das zieht nur das dazu, was du auch nutzt. Es gibt eine Menge extrem nützlicher Features in C++, die überhaupt nicht externes einbinden. Unter gewissen Umständen ist es sogar effizienter als C. Jochen W. schrieb: > RTOS auf 8051-Kernen? Du möchtest alles minimal und effizient halten aber dann ein RTOS ausgerechnet auf einem 8-Bitter nutzen? Wie war das mit der Maschinennähe? Jochen W. schrieb: > Der job: PWM-codierte Sensoren lesen und an einen CAN Netzwerk-ast > abgeben. Evtl. noch ein kleines Display bespielen. Dazu brauchst du ein RTOS? Frank K. schrieb: > SPI-CAN ist eine Notlösung. Das nimmst Du dann und genau nur dann, wenn > alle anderen sinnvollen Möglichkeiten ausgeschöpft sind. Sehe ich auch so. Ein integrierter CAN-Controller ist viel einfacher und effizienter anzusteuern, als wenn man alles durch den SPI quetschen muss.
Jochen W. schrieb: > Hmmm, was meinst Du mit MAC? Ich brauche neben dem uController einen > CAN-Controller und den Transceiver. MAC ist bei mir mit IEE802.3 > interface (OPEN) oder media access control (ISO11898) begrifflich > belegt... MAC ist der Digitalteil, quasi das, was man normal als CAN-Controller bezeichnet. > Wo siehst Du denn die Nachteile der "Notlösung?" Systemlast, Bandbreite, Paketverluste. Das SPI-Protokoll des MCP2517/18 ist relativ ineffizient. Bei einem eingebauten Controller ist das nur ein DMA oder DPRAM-Zugriff. ALso quasi null CPU-Last und damit weniger Stromverbrauch. fchk
Zuerst bedanke ich mich mal bei allen "Einwendern", daß so klar und freundlich kommentiert und geholfen wird! In der Zwischenzeit habe ich noch weitere Datenbätter, boards, chipsätze, github durchforstet. Es kamen mir noch MCP2517 Treiber für STM32 mit Cortex M4 in den Blick, auch hier aber eben für SPI. Begriffen hab ich, daß alles von der Treiber/Bibliotheks-Lage abhängt, um ohne Riesen-Klimmzüge zum Ergebnis zu kommen. Das Thema RTOS war nur ein Seitenblick, hier unnötig. Es gibt Leute, die muckern mit Arduino+MCP2515 - das wollte ich ganz sicher nicht. Mit C, C++ komme ich schon hin, es dauert, es nervt, es geht. Pascal-Hausschuhe diesmal nicht...
Jochen W. schrieb: > Begriffen hab ich, daß alles von der Treiber/Bibliotheks-Lage abhängt, > um ohne Riesen-Klimmzüge zum Ergebnis zu kommen. Naja, CAN und PWM-Input sind recht simpel, das kann man auch selbst machen. Außerdem gibt es für die STM32 die HAL-Bibliotheken die das alles schon erledigen. Du wolltest doch nah an die Hardware...
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.