Announcement: there is an English version of this forum on Hi Leute, Hat jemand Erfahrungen mit verschiedenen Mikrochips und Transceivern in Bezug auf den CAN-Bus und kann deshalb welche empfehlen? Speziell wird er im Auto eingesetzt. Wichtig wäre dabei eine gute Dokumentation, am besten mit einer guten funktionsfähigen library und ein paar Code-Beispielen. Bisher haben wir mit dem PIC18F258 + MCP2551 gearbeitet. Da die Library einige Bugs hat und das Projekt abgeschlossen ist, ist es eine gute Zeit umzuschwenken. Vielen Dank für eure Hilfe!
Ich denke, dass Du die falsche Reihenfolge gewählt hast. Die Initialisierungssequenzen zum CAN-Bus sind extrem Prozessorabhängig. Also wird wohl die erste Rückfrage lauten: Welcher Prozessor? Die zweite wird wohl lauten: Wofür? Kommerziell oder Privat. Im letzteren Falle: Die vielgeschmähte Arduino-Serie hat auch einen CAN-Bus-Shield und einiges an Software im Pool. Ich habe allerdings noch nicht damit gearbeitet.
Also wir dachten an nen 32bit Prozessor, sollte recht günstig sein <3€ und wie schon gesagt, gute Bibliotheken für CAN und genügend Beispiele haben. Es ist für die Forschung und Entwicklung, also wird nicht weiterverkauft. Also eher privat. Arduino klingt interessant. Hat damit schon jemand mehr Erfahrungen? Und kann davon berichten?
Naja, Forschung/Entwicklung und dann soll der µC nichts kosten? Zumal man einzeln ohnehin Mondpreise bezahlt. Wenn Ihr bisher Microchip benutzt habt, die haben auch dickere µC mit integriertem CAN-Controller.
Ja kennt man doch, man will immer das Beste, aber darf nichts kosten... Ja geht vorallem auch darum, dass man brauchbare Bibliotheken und Beispiele hat.
ob Atmel oder Microchip oder andere haben jeweils einen Automotivebereich dort stehen auch entsprechnede Controller bereit mal durchschauen http://www.microchip.com/pagehandler/en_us/technology/automotive www.atmel.com/products/automotive/default.aspx
Hallo Manuel, hat Dich Dein kleines CAN timing Problem so aus der Fassung gebracht das Du jetzt wechseln willst? Rudolph schrieb: > Wenn Ihr bisher Microchip benutzt habt, die haben auch dickere µC mit > integriertem CAN-Controller. Hat er. War vor ein paar Tagen hier im Forum. Steckt da auch schon tief drin und hat die LIB verinnerlicht. Es gab nur ein paar 'Irritationen'. Du tauscht nur Cholera gegen Pest. Die Microchip LIB wird wie fast alle freien LIBs einfach nicht fertig bzw. komplett sein. Ein Funktionsmuster für rudimentäre Funktionen, mehr nicht. Ich glaube nicht das ein freundlicher kleiner AVR + Shield + dieser unperformanten Arduino Einsteiger Software die Lösung Deiner Probleme ist. Hast Du mal ins Datenblatt des PICs geschaut was der alles CAN ? Ich wette die Microchip LIB nutzt das nicht mal zur Hälfte. Z.B. die ganzen RX Nachrichtenfilter die Du gebraucht hättest. Kann die LIB die verwalten ? Du arbeitest Dich nur in die nächste MCU, den nächsten Transceiver und die nächste LIB ein um dann Stück für Stück herauszufinden was nicht da ist oder Fehler verursacht.
Hi Michael, Nein soweit hat dann sogar alles geklappt. Außer die Filter. Und das ist eins der Probleme. Die Lib beinhaltet zwar die Filter und Masken, aber Sie funktionieren nicht... War für dieses Projekt nicht wirklich schlimm, aber für folgende würde ich den Controller doch besser beherrschen wollen. Daraufhin hab ich eine andere LIB gefunden, die zwar für die PIC18c ist, aber durch Anpasssungen auch für die 18F funktionieren soll. Da funktioniert aber leider auch nicht viel. Deshalb kam ich auf die Frage, obs nicht vllt. besser wäre komplett umzuschwenken. Aber dann eben nur, wenn es wirklich auch ausführliche Beispiele und Libs gibt, denn sonst, wie du schon sagtest, steck ich nach ner Weile wieder im selben Dreck wie jetzt =D Versteh auch nicht wirklich, wieso man kaum funktionierende Beispiel-Programme findet. Gibt doch sicherlich genügend Leute die Programme haben die gut funktionieren, da würden ja schon die CAN-Settings reichen..
>Versteh auch nicht wirklich, wieso man kaum funktionierende >Beispiel-Programme findet. Da es mich nicht interessiert, habe ich mir die Adressen nicht gemerkt. Im Netzt gibt es, insbesondere rund ums Auto, X Projekte die sich mit CAN + Automobil (On-Board-Unit) beschäftigen. Meist fallen dabei die Stichworte: OBD, Fehlerdiagnose und Diagnosegerät. Natürlich auch die üblichen Verdächtigen wie: (V)au(W)eh, Audi, Opel u.s.w.
Wie wärs mit einem STM32F103C4 (oder größer); schöne Cortex-M3 32bit-CPU (definitiv schnell genug um einen 1MBit CAN Bus auch ohne Filter zu verwursten), integrierter CAN-Controller, und die ST Standard Peripheral Library erlaubt einen halbwegs highlevel-Zugriff auf die Hardware. Beispiele gibts auch. Im Zweifelsfall kann man auch direkt auf die Register zugreifen, so komplex ist das nicht. Gibt natürlich viele passende Controller; ich würde nur auf jeden Fall einen mit integriertem CAN-Controller nehmen und nur wenn es aus obskuren Gründen gar nicht anders geht einen externen CAN-Controller.
An den STM32 wundert mich ein wenig, dass es keine Automotive Versionen gibt. ST bietet als Automotive nur die angestaubten ST10 sowie als aktuelle Lösung PowerPC.
Dann guck bei NXP. Haben auch kleine Controller mit integriertem CAN-Übertrager. Sind gut dokumentiert und massig funktionierende Beispiele gibt es auch. Aber bei CAN lohnen sich die Beispiele kaum. Da kann man auch selbst was schreiben. Das ist kein Hexenwerk und man sollte eh den Controller kennen, den man einsetzt und wie die Hardware funktioniert, anstatt sich auf obskure Libs zu verlassen
Manuel Bali schrieb: > Hat jemand Erfahrungen mit verschiedenen Mikrochips und Transceivern in > Bezug auf den CAN-Bus und kann deshalb welche empfehlen? Speziell wird > er im Auto eingesetzt. Infineon X167 bzw XC2000'er Serie, Keil Compiler wg MISRA, und nicht zu vergessen irgendwas in Richtung AUTOSAR. Dazu die Tools von Vector, Matlab/Simulink, Doors für die Requirements, und Du hast einen ganz guten Querschnitt von dem, was so üblich ist. Diese Liste ist natürlich alles andere als vollständig. Billig geht jedenfalls anders. Und wenn Ihr an dem PIC gescheitert seid, dann nicht wegen irgendwelcher Fehler im PIC, sondern wegen Eurer Unfähigkeit. PIC18 ist relativ einfach, wenn Ihr das nicht in den Griff bekommt, dann braucht Ihr gar nicht erst weiterzumachen - das andere wird eher komplexer. Sorry, aber das muss einfach mal gesagt werden. fchk
Diesen MCP2551 habe ich auch noch auf keiner Freigabeliste gesehen. Üblich sind Infineon TLE6251, NXP TJA1051 oder TJA1043, und ggf. noch die SBCs von Bosch, Onsemi, IFX oder Elmos. Wenn Du CAN hast, bedeutet das bei fast allen OEMs auch AUTOSAR. AUTOSAR braucht 32 bit und >256kB Flash, damit bist Du bei V850, XC2200 oder MPC5600. Und den Compiler lieber von IAR oder Greenhill Systems...
soul eye schrieb: > Und den Compiler lieber von IAR oder Greenhill Systems... Das sind ja Spaßvögel... Auf der Greenhill Seite ist scheinbar die einzige Information über den Compiler dass er schnellen Code produziert. Bei IAR steht sogar ein bisschen was technisches. Welcher C++ Standard und welche Features davon unterstützt werden braucht ja keinen zu interessieren, hauptsache der Kunde zahlt?!
Da es hier ja wohl nicht um Serie geht wird Autosar und was da sonst noch so alles kam keinen interessieren. Greenhills ist auch nur interessant wenn man es professionell macht. Dann bekommt man auch alle Infos. Basteler sind da nicht die Zielgruppe.
rcc schrieb: > Greenhills ist auch nur interessant wenn man es professionell macht. > Dann bekommt man auch alle Infos. Heißt das man kauft erst und erfährt dann was man eigentlich gekauft hat? Geschickt, so sollte ich das mit meinen leeren Computer-Gehäusen auch machen.
Nein, das heißt wenn man als entsprechende Firma mit Grennhills in Kontakt tritt bekommt man die Infos natürlich alle (bzw. hat sie eh, so viele zertifizierte Compiler für Serie gibt es im automotive-Umfeld nicht).
rcc schrieb: > Nein, das heißt wenn man als entsprechende Firma mit Grennhills in > Kontakt tritt bekommt man die Infos natürlich alle Achso, klassisch mit Anfrage. Das mit (Produkt-)Informationen im Internet ist ja noch nicht bei allen angekommen. rcc schrieb: > (bzw. hat sie eh, so > viele zertifizierte Compiler für Serie gibt es im automotive-Umfeld > nicht). Weißt du denn zufällig welchen C++ Standard die unterstützen? Würde mich mal interessieren, aber leider bin ich keine "entsprechende Firma".
Dr. Sommer schrieb: >> Nein, das heißt wenn man als entsprechende Firma mit Grennhills in >> Kontakt tritt bekommt man die Infos natürlich alle > Achso, klassisch mit Anfrage. Das mit (Produkt-)Informationen im > Internet ist ja noch nicht bei allen angekommen. Doch, im internen Bereich der Seite hat man Zugriff auf alles. Wie gesagt, Bastler und Privatpersonen interessieren da schlicht nicht, geschweige denn dass man die Preise privat bezahlen möchte. C++ macht man automotive eh nicht.
> Doch, im internen Bereich der Seite hat man Zugriff auf alles. Wie > gesagt, Bastler und Privatpersonen interessieren da schlicht nicht, > geschweige denn dass man die Preise privat bezahlen möchte. Nunja, in Firmen arbeiten (oft) Menschen, die haben (hatten) ein (Privat-) Leben, und vielleicht möchten die ja schon ein paar Erkenntnisse über den Markt gewinnen, bevor sie in so einer Firma angestellt sind (z.B. um für solche Firmen interessant zu werden), und dazu wäre es natürlich hilfreich wenn man an diese Informationen kommen könnte, wie das bei vielen anderen großen Software-Herstellern auch ist; naja egal jetzt. > C++ macht man automotive eh nicht. Achja, da wird mehr auf grafische Programmierung (Matlab und so?) gesetzt oder wie war das?
Dr. Sommer schrieb: >> C++ macht man automotive eh nicht. > Achja, da wird mehr auf grafische Programmierung (Matlab und so?) > gesetzt oder wie war das? Genau und Matlab generiert daraus dann doch C-Code kein C++ :-D
Hallo Manuel, das wird nirgends anders sein. Das LIBs nur Basisfunktionen bereitstellen und vieles überhaupt nicht geht oder nicht auf Deinem Chip geht ist der Normalfall. Einfach brachial Rechenpower drauf zu hauen um alles in Software zu lösen ist sicher für einige ein probates Mittel. Die anderen verwenden ganz bestimmte Chips für die es teure Software von Leuten gibt die da mal mehr Zeit rein gesteckt haben in der Hoffnung das das alle Probleme löst. Ist doch toll das die LIB soweit funktioniert hat. Bei der weist Du jetzt wie weit Du Dich darauf verlassen kannst und was nicht geht. Das hat Dich viel Arbeit gekostet so weit zu kommen. Klammer Dich nicht zu sehr an der bestehenden LIB fest, das ist auch nicht mehr als etwas formalisiertes Register beschreiben. Die HW Filter sind kein Hexenwerk und im Prinzip werden die schon gehen wenn die richtig konfiguriert sind. Alle Register zu verstehen wird nur ein paar Stunden Datenblattlektüre brauchen und vielleicht ein wenig allgemeine CAN Informationen. Dann stellst Du über die LIB alles ein, obwohl Du weist das es nicht geht. Wenn die Initialisierung Ihr Werk getan hat gehst Du im Debugger auf Halt, schaust Dir alle Register CAN betreffend an denn Du weiß ja was drin stehen müsste. Stehen die IDs drin die Du beschrieben hast ? Sind die Filter aktiv geschaltet ? Noch irgendwelche Modi oder Spezialitäten umzustellen ? Eine Handvoll Register die Du verstehen musst und nicht mehr dann weiß Du was die LIB falsch macht und das baust Du dann fertig. Wird ja nicht die letzte LIB sein die Dir Sorgen macht. Da kannst Du ja nicht immer gleich den Hersteller wechseln. Gerade die PICs haben immer wieder echte Hardware Absonderlichkeiten die aber für einen Spezialfall Gold wert sind. Für sowas gibt es dann gar nichts außer 20 Seiten im Datenblatt da muss man dann durch.
Hier sind ja wirklich einige Vorschläge zusammen gekommen. Danke! @Michael: Ich denke du hast recht und ich sollte bei dem Chip bleiben. Ich dachte eben, wenn ich die HW Filter benutzen will, muss ich mich voll richtig in den Chip/Register einarbeiten. Das kostet Zeit und ich wollte nicht, danach realisieren, dass dieses Setup eigenltich nichts taugt, und ich für ein anderes Projekt komplett was anderes brauche und mich dort eben wieder neu einarbeiten muss. Aber scheinbar taugt der PIC18F ja schon. Privat bin ich am überlegen ob ich mir das STM32F4-Discoveryboard anschaffe + CAN-Transceiver. Das scheint ziehmlich Power zu haben und ein Freund von mir hat damit schon einige Projekte gemacht und könnte mir diese bereit stellen. Ich glaube, dass ist ganz gut um sich besser in die Materie einzuarbeiten =)
Manuel Bali schrieb: > @Michael: Ich denke du hast recht und ich sollte bei dem Chip bleiben. Microchip sagt zu diesem Chip "Not Recommended for new designs" Der PIC18F26K80 ist die aktuelle Ausgabe, etwas schneller, ECAN Peripherie mit mehr Fähigkeiten, und stromsparender. Und wenn Du mehr Rechenleistung brauchst, nimmst Du den dsPIC33EP512GP502. 70 MHz, 48k RAM, 512k Flash, 16 Bit, aber gleiches Gehäuse, gleiche Tools, gleicher ECAN, d.h. der Umstiegsaufwand hält sich sehr in Grenzen. Du brauchst nur den passenden Compiler von Microchip runterzuladen. fchk
Ob Du beim PIC bleibst oder zum STM32 wechselst ist für die Sache eigentlich egal und Deinen persönlichen Vorlieben überlassen. Beide bieten in entsprechenden Modellen mehr Rechenpower als man zwingend braucht. Ich sehe jetzt Deinen Vorteil nicht zu wechseln, weil Du immer wieder damit konfrontiert sein wirst Deine MCU auf Register Ebene kennen zu lernen. Da sträubst Du Dich zwar noch mit Händen und Füssen, aber das ist nun mal die hardwarenahe Mikrocontroller Programmierung. Auch beim STM32 und Deinem Kumpel werden Situationen auftreten in denen weder STM noch Dein Kumpel bereits Dein Problem gelöst haben. Du muss dann verstehen was STM gemacht hat, was Dein Kumpel gemacht hat, was der Chip kann und was Du machen willst. Ich mir zu kompliziert ich lass die ersten beiden lieber weg. Du verbringst gerade mehr Zeit damit Dich nach dem (nicht vorhandenen) Optimum umzuschauen als Du brauchen würdest die CAN Register zu verstehen.
Sehr gut für den Einstieg in die CAN Thematik ist auch folgendes Board: https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/ Das ist schon komplett alles auf dem Board. Ein CAN-Bootloader, CanOpen und der CAN Treiber selbst sind fest im ROM. Den nackten Chip gibts z.B. hier: http://de.futureelectronics.com/de/technologies/semiconductors/microcontrollers/32-bit/Seiten/5006541-LPC11C24FBD48-301,.aspx?IM=0 für gerade mal 1.73€. Preiswerter gehts mit STM32, AVR und PIC auch nicht. Und eins kannst du glauben. Wenn du mal eine Weile mit den Cortexen gearbeitet hast und über das Fluchen am Anfang hinweg bist, willst du nicht mehr zurück. Ich hatte heute wieder mal was an einem alten AVR-Projekt gemacht. Die Debuggerei über Debugwire geht da zwar, aber man fühlt sich so als wenn man die Bits einzeln in Stein meißelt. Deshalb kommen PIC und AVR für was Neues bei mir nicht mehr in Frage.
Kurze Frage zum LPC-P11C24 auf oben empfohlenen Olimex Board. Wieviel Strom können die GPIO's liefern. Ich habe kurz ins Datenblatt geschaut und verstehe das so das nur Pin PIO0_7 20mA liefern kann, die anderen GPIO's 4mA. Oder habe ich das falsch gelesen? Andre
>Sehr gut für den Einstieg in die CAN Thematik ist auch folgendes Board: >https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/ Sieht aufjedenfall interessant aus, werd ich mir mal genauer anschauen. Ist natürlich sehr nützlich wenn schon alles auf einem Board ist, und ich nicht noch was dazu "bauen" muss. @ Michael: Hast mich vllt nicht ganz verstanden. Ich werd am PIC auf der Arbeit bleiben bzw. im Praktikum. Will mir jetzt aber für den privat Betrieb noch en Entwicklungsboard holen und dort eventuell ein anderes nehmen
Angehängte Dateien:
-
CAN_ESD_Schutz.png
9,3 KB -
CAN_ESD_Schutz2.png
11 KB
die Anbindung an den CAN-Bus ist aber schon etwas sparsam ausgeführt worden. https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/resources/LPC-P11C24_revision_A_sch.pdf ganz unten rechts, das ist eher zum probieren auf dem Schreibtisch mit kurzen Leitungen gedacht. Gerade im Auto würde ich nicht auf die Drossel und auf den ESD Schutz verzichten, also eine erprobte Musterlösung wählen.
Für CAN hatte ich mal die LPC2000, als die erst kurz am Markt waren. Der CAN-Controller war auch völlig verbugt, manche nannten ihn schon mal CAN-not, aber es gab einen Workaround von NXP in Software dazu. Das Ding fluppte auch mit 1 Mbit/s unter 100% Traffic ohne Probleme. Inzwischen sollten sie die Dinger aber bugfrei haben. Aber das steht in Zusatzpapieren zum Datenblatt, ich glaube man sagt heute nicht mehr ERRATA dazu. Von Keil gab es Demo-Beispiele mit diesem Workaround drinne. Diese sind mal gut, um eine kleine Kommunikation zwischen zwei Systemen spielen zu sehen, viel mehr allerdings nicht. Ohne diese, und komplett bei Null angefangen, wäre der Aufwand aber erheblich höher geworden. Aber ich mußte noch eine ganze Menge an der Software selbst stricken, wie eben Softwareentwicklung es so typisch an sich hat, und was man sich noch alles an Features wünscht. Z.B. große Message-FIFOs mit Zeitstempel und Durchnumerierung an den Messages dran, falls das interne Datenaufkommen im µC mal temporär höher wird, als der Bus erlaubt, oder mal ein altes Protokoll darin verwursteln, was früher mal auf RS232 oder RS485 lief, wenn der Kunde es so vorgibt. Sende- und Empfangs-LEDs, die auch eine einzelne Message fürs Auge sichtbar gut anzeigen. Variables Timing, was den Bus-Traffic besser regelt. Die Variationen können vielfältig sein, da gibts nicht immer was universelles. Ansonsten machte es aber Spaß, ein Gerät mal mit einem Bus zu erweitern. Für die LPC2000 lief vieles in einer speziellen Yahoo-Group auf Englisch. Für den LPC2138, der hatte allerdings kein CAN, mußte man sich in der Yahoo-Group registrieren, um ans User Manual zu kommen. NXP hatte es nur dort platziert. Das war ja echt doof. Aber wenn man da schon mal dran war, die LPC2000 waren doch ganz nett, würde sie immer noch mal wählen.
Manuel Bali schrieb: > @ Michael: Hast mich vllt nicht ganz verstanden. Ich werd am PIC auf der > Arbeit bleiben bzw. im Praktikum. Will mir jetzt aber für den privat > Betrieb noch en Entwicklungsboard holen und dort eventuell ein anderes > nehmen Du hast gelesen, was ich geschrieben habe? "Not recommended for new Designs!" Das solltest Du ernst nehmen und den empfohlenen Nachfolger verwenden! fchk
>Du hast gelesen, was ich geschrieben habe? "Not recommended for new >Designs!" Das solltest Du ernst nehmen und den empfohlenen Nachfolger >verwenden! Jop hab ich gelesen, wo hast du den Satz denn gefunden? Hab grad auf der Microchip Seite geschaut, und nichts gefunden. Ansonsten werd ich wohl auf deinen andern genannten zurück greifen
Thomas O. schrieb: > die Anbindung an den CAN-Bus ist aber schon etwas sparsam ausgeführt > worden. > https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/resources/LPC-P11C24_revision_A_sch.pdf > ganz unten rechts, das ist eher zum probieren auf dem Schreibtisch mit > kurzen Leitungen gedacht. > > Gerade im Auto würde ich nicht auf die Drossel und auf den ESD Schutz > verzichten, also eine erprobte Musterlösung wählen. Unfug. Der CAN-Transceiver ist mit +/- 8kV ESD spezifiziert, das kriegt man auch im Auto nicht kaputt. Und auch die Drossel ist für den Betrieb nicht notwendig. Sie hilft beim EMV-Verhalten, wobei das nur bei manchen Transceivern (mit schlechter Bitsymmetrie) wirklich notwendig ist. Max
Manuel Bali schrieb: >>Du hast gelesen, was ich geschrieben habe? "Not recommended for new >>Designs!" Das solltest Du ernst nehmen und den empfohlenen Nachfolger >>verwenden! > > Jop hab ich gelesen, wo hast du den Satz denn gefunden? Hab grad auf der > Microchip Seite geschaut, und nichts gefunden. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en010281 Da steht "Mature Product" und " Please consider this device: PIC18F2580. View Side By Side Comparison" Und hier http://www.microchip.com/wwwproducts/ProductCompare.aspx?product1=PIC18F258&product2=PIC18F2580 findest Du die Umschreibung von "Mature Product" im Klartext. Der PIC18F2580 ist zwar nicht uralt, aber auch schon wieder alt. Der aktuelle ist der PIC18F25K80, bzw der PIC18F26K80 (mehr Speicher). Schau Dir das an, dann weißt Du, warum ich den K-Typ empfehle. Der ist außerdem billiger. http://www.microchip.com/wwwproducts/ProductCompare.aspx?product1=PIC18F258&product2=PIC18F25K80 http://www.microchip.com/wwwproducts/ProductCompare.aspx?product1=PIC18F2580&product2=PIC18F25K80 fchk
Vielleicht eine etwas andere Richtung: Viele Rechnerhersteller vertreiben sogenannte evaluation boards zu ihren CAN-fähigen Prozessoren. Dazu sollte eigentlich auch ein "vorzeigbares" Setup zum CAN-Bus gehören, jede Menge Demos und zumindest ein, wenn auch manchmal etwas "eingeschränkter" Compiler. Was fast immer vorhanden ist, ist eine ausreichende Beschreibung und Dokumentation. Meist mit Schaltbildern.
Max G. schrieb: > Der CAN-Transceiver ist mit +/- 8kV ESD spezifiziert, das kriegt > man auch im Auto nicht kaputt. Und auch die Drossel ist für den Betrieb > nicht notwendig. Ist auch meine Erfahrung. Wenn alles so zuverlässig wäre, wie der PCA82C251, hätten wir nichts zu reparieren. Dieses Drossel und Schutzgedöns habe ich auch nie eingesetzt. In den älteren CAN-Applikationen war es auch nicht drinn. Als CAN-Controller setzten wir früher PCA82C200/SJA1000 ein. Und seit längerem den AT90CAN128, mit 15 MOBs, hat der ausreichend Filter und Puffer.
>Viele Rechnerhersteller vertreiben sogenannte evaluation boards zu ihren >CAN-fähigen Prozessoren. Zufällig hat ein Arbeitskollege heute so ein Board empfangen und morgen startet dafür ein Online gratis kurs. Das Board ist die Tiva C Series TM4C123G und das Launchpad Hat dazu jemand Erfahrungen? Was für ein solches Board spricht: Es hat schon das JTAG dabei, und man kann direkt über USB-zu-MicroUSB flashen und es kostet komplett unter 15€ Denn wenn man kein JTAG hat (Privat hab ich keins) dann kostet dieses ja auch nochmal einiges an Geld.
Ich werde als nächsten CAN Controller den BeagleBoneBlack testen - wenn sie dann in dieser Republik verfügbar werden. Ein CAN-Cape gibt es, und socketCAN läuft auch.
Peter Dannegger schrieb: > Dieses Drossel und Schutzgedöns habe ich auch nie eingesetzt. In den > älteren CAN-Applikationen war es auch nicht drinn. Es gibt wohl spezielle Schutzdioden mit niedriger Kapazität für CAN. Sie halten aber auch nicht ganz so viel aus. Am Anfang hatten wir normale Transildioden im CAN-Bus, bis der oberhalb von 250 kbit/s nicht mehr lief. Zu hohe Kapazität. Allerdings, unterhalb der Bitraten kann man sie durchaus einsetzen, bei z.B. 50kbit/s stören sie gar nicht.
https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/ Ich suche gerade ein JTAG für dieses Board. Ich hab am Laptop aber nur normalen USB2.0 oder USB3.0 und keinen "DruckerUSB" Platz. Kann mir jemand ein Günstiges und für dieses Board funktionsfähiges JTAG für USB2.0 bzw. 3.0 empfehlen?
Manuel Bali schrieb: > https://www.olimex.com/Products/ARM/NXP/LPC-P11C24/ > > Ich suche gerade ein JTAG für dieses Board. Ich hab am Laptop aber nur > normalen USB2.0 oder USB3.0 und keinen "DruckerUSB" Platz. Kann mir > jemand ein Günstiges und für dieses Board funktionsfähiges JTAG für > USB2.0 bzw. 3.0 empfehlen? http://www.segger.com/j-link-edu.html Nicht das billigste, aber das problemloseste. Wenn Du sparen willst, schau hier: ebay #261231213519 :-) fchk
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.