Hallo Zusammen, da ich relativ neu hier bin, möchte ich mir erst einmal vorstellen. Ich bin 29 Jahre und mache gerade meinen Master in Automobil- und Nutzfahrzeugtechnik (Maschinenbau). Als MA habe ich mir ein komplett fachfremdes Thema gesucht: Ich möchte einen LIN-Master Knoten mit Bluetooth Funktionalität entwickeln. Dieser soll die Informationen von einem Slave über Bluetooth zur Verfügung stellen. Da das ganze so wenig wie möglich Strom brauchen soll, würde ich gerne einen SoC mit integrierter UART benutzen um über einen Transreciever mit dem Bus kommunizieren zu können. Ich bin jetzt ein wenig erschlagen von der Vielzahl an BLE Chips auf dem Markt. Gibt es da irgendwelche Empfehlungen? Erfahrung habe ich bisher (leider) nur mit der Arduino IDE. Danke und viele Grüße Maximilian
Na dann überleg dir doch, den ESP32 zu nutzen - ist per Arduino ansprechbar, hat 3x Uart und WLAN / Bluetooth on board. Wird auch mit Stromsparmöglichkeiten beworben...
Ich schrieb: > Na dann überleg dir doch, den ESP32 zu nutzen Problem ist nur, dass die UARTs vom ESP32 nicht besonders gut für LIN geeignet sind, weil ihnen die Möglichkeit fehlt, Line BREAKs, wie sie speziell bei LIN verwendet werden, zu erzeugen und sauber zu detektieren, ohne zu irgendwelchen Tricks zu greifen. Ein TI CC2640 erscheint mir da geeigneter. Der kann es nämlich. fchk
Wenn Du wirklich das haben willst was auch wirklich Strom spart, schau dir mal den btlc1000 an, hier ein interessanter Benchmark einer Schweizer Uni. Auch die Art wie der Vergleich gemacht wird (in Joule um die niedrigste Stromaufnahme für Energy Harvesting zu finden) ist interessant. http://pd.zhaw.ch/publikation/upload/210180.pdf Da schneidet der BTLC1000 sehr gut ab, eigentlich sogar am besten wenn man die Schlüsselpunkte wie Provisioning current anschaut. Achtung der BTLC1000 braucht noch eine MCU, da du LIN brauchst wird die Auswahl schonmal sehr eng. Der SAML21 ist low power, hat LIN und wird von Microchip von Haus aus für BT unterstützt.
Stefan schrieb: > Wenn Du wirklich das haben willst was auch wirklich Strom spart, schau > dir mal den btlc1000 an, hier ein interessanter Benchmark einer > Schweizer Uni. Interessantes Paper. Danke. Hier aber wohl weniger interessant. Wenn der Fragesteller ein System mit LIN-Bus plant (LIN braucht V+ (Dauerplus), GND und die Datenleitung), wird er höchstwahrscheinlich eine ziemlich direkte Verbindung zum 12V-Netz des Fahrzeuges haben, denn LIN ist ein 12V-Bus. Oder 24V bei Fahrzeugen mit 24V-Bordnetz. Da kommen so viele Amperes raus, dass er sich keine besonders großen Sorgen um den Stromverbrauch im Betrieb machen muss. Wichtiger ist der Ruhestromverbrauch, d.h. das System sollte sich bei einem abgeschalteten Fahrzeug spätenstens nach einer halben Stunde runterfahren, damit der gesamte Ruhestrom im KFZ nicht mehr als 50mA beträgt. Viel spannender ist die Frage der Schutzbeschaltung. Bei einem 12V Bordnetz können schon mal 60V auf V+ oder der Datenleitung auftreten, und zwar +60V und -60V gegen GND. Ohne geeignete Schutzbeschaltung ist sein Gerät ganz schnell ganz kaputt. fchk
:
Bearbeitet durch User
Hallo Zusammen, Vielen Dank für eure Antworten. Ich schrieb: > Na dann überleg dir doch, den ESP32 zu nutzen - ist per Arduino > ansprechbar, hat 3x Uart und WLAN / Bluetooth on board. Wird auch mit > Stromsparmöglichkeiten beworben... Den habe ich auch schon daheim liegen :-) Problem an dem ESP32 ist nur, dass noch nicht alles funktioniert und dass er mir für meine Anwendung fast ein wenig zu überdimensioniert erscheint. Wie siehst du das? Im Prinzip muss der Master nur zyklisch den LIN-Header senden und die Antworten vom Slave drahtlos zur Verfügung stellen... Frank K. schrieb: > Problem ist nur, dass die UARTs vom ESP32 nicht besonders gut für LIN > geeignet sind, weil ihnen die Möglichkeit fehlt, Line BREAKs, wie sie > speziell bei LIN verwendet werden, zu erzeugen und sauber zu > detektieren, ohne zu irgendwelchen Tricks zu greifen. Du meinst damit die Präembel vom LIN-Frame zum Aufwecken der Slaves? Darüber hatte ich mir auch schon den Kopf zerbrochen und hätte es entweder via Baudratenumschaltung oder I/O Pin gemacht der den Bus für die 13 Bit auf null zieht. @Stefan: Vielen Dank! So einen Artikel habe ich seit längerem gesucht. Zwar würde ich es gerne vermeiden einen zusätzlichen MCU zu nutzen, aber wenn es sich nicht vermeiden lässt... Gruß Maximilian
Frank K. schrieb: > Da kommen so viele Amperes raus, dass er > sich keine besonders großen Sorgen um den Stromverbrauch im Betrieb > machen muss. Bei dem Stromverbrauch würde ich gerne unter der Selbstentladung von Bleiakkus bleiben. Bei 3 % pro Monat ergäbe das bei einem 90 Ah Akku circa 4 mA Ruhestrombedarf. Frank K. schrieb: > Viel spannender ist die Frage der Schutzbeschaltung. Bei einem 12V > Bordnetz können schon mal 60V auf V+ oder der Datenleitung auftreten, > und zwar +60V und -60V gegen GND. Ohne geeignete Schutzbeschaltung ist > sein Gerät ganz schnell ganz kaputt. Bitte korrigiere mich, wenn ich das zu naiv sehe, aber erledigt das nicht der Transceiver für mich? Dachte dran z.B. den hier einzusetzen: http://www.nxp.com/documents/data_sheet/TJA1020.pdf Gruß Maximilian
Maximilian R. schrieb: > Frank K. schrieb: >> Da kommen so viele Amperes raus, dass er >> sich keine besonders großen Sorgen um den Stromverbrauch im Betrieb >> machen muss. > > Bei dem Stromverbrauch würde ich gerne unter der Selbstentladung von > Bleiakkus bleiben. Bei 3 % pro Monat ergäbe das bei einem 90 Ah Akku > circa 4 mA Ruhestrombedarf. Das ist jetzt aber keine harte Anforderung, d.h. 6mA wären auch kein Problem, denke ich. > Frank K. schrieb: >> Viel spannender ist die Frage der Schutzbeschaltung. Bei einem 12V >> Bordnetz können schon mal 60V auf V+ oder der Datenleitung auftreten, >> und zwar +60V und -60V gegen GND. Ohne geeignete Schutzbeschaltung ist >> sein Gerät ganz schnell ganz kaputt. > > Bitte korrigiere mich, wenn ich das zu naiv sehe, aber erledigt das > nicht der Transceiver für mich? Dachte dran z.B. den hier einzusetzen: > > http://www.nxp.com/documents/data_sheet/TJA1020.pdf Der ist erstens eine alte Kamelle und zweitens reicht der alleine bei weitem nicht aus. Lies das hier: http://www.st.com/content/ccc/resource/technical/document/application_note/1f/d7/fc/6d/2e/27/48/98/CD00181783.pdf/files/CD00181783.pdf/jcr:content/translations/en.CD00181783.pdf Sowas gehört dann natürlich auch in die schriftliche Ausarbeitung, die Du anfertigen wirst. Als Transceiver würde ich eher den hier nehmen: http://www.ti.com/product/sn65hvda195-q1 Der ginge auch mit 24V Bordnetz, wenn es mal notwendig sein sollte. fchk
Maximilian R. schrieb: > Frank K. schrieb: >> Problem ist nur, dass die UARTs vom ESP32 nicht besonders gut für LIN >> geeignet sind, weil ihnen die Möglichkeit fehlt, Line BREAKs, wie sie >> speziell bei LIN verwendet werden, zu erzeugen und sauber zu >> detektieren, ohne zu irgendwelchen Tricks zu greifen. > > Du meinst damit die Präembel vom LIN-Frame zum Aufwecken der Slaves? > Darüber hatte ich mir auch schon den Kopf zerbrochen und hätte es > entweder via Baudratenumschaltung oder I/O Pin gemacht der den Bus für > die 13 Bit auf null zieht. Ja, das ist die Notlösung, wenn man einen schechten UART hat. Vom ESP32 rate ich Dir aber aus einem ganz anderen Grund ab: Es gibt davon keine Automotive Version, und es wird davon von den Chinesen auch nie eine geben. Das ist nämlich gar nicht deren Markt. Für Dein konkretes Projekt ist das jetzt nicht unbedingt wichtig, aber in der Master-Arbeit wird erwartet, dass Du auch so etwas im Kopf hast. Dein Design soll am Ende zumindest im Prinzip automotive-tauglich sein. Wenn Du jetzt für Deine Prototypen aus Kostengründen keine Automotive-Typen einsetzt, ist das völlig ok, aber Du solltest darauf achten, dass die Schlüsselkomponenten auch in Automotive Varianten verfügbar oder zumindest angekündigt sind. Siehe zB: Automotive http://www.ti.com/product/cc2640r2f-q1/description Standardversion: http://www.ti.com/product/cc2640r2f/description Das war nämlich mein Hintergedanke dabei. Dir wird vielleicht auffallen, dass es die Standardversion in DSBGA und QFN gibt, die Automotive-Version aber nur in QFN. Heißt natürlich für Dich, dass Du QFN nimmst, auch wenn Du der besseren Verfügbarkeit zur Standardversion greifst. Du kannst ja auch mal Deinen Betreuer oder Deinen Professor fragen, warum es die Automotive-Version nur in diesem Package gibt, wenn Du was lernen willst. Hat nämlich auch Gründe. Du willst Deinem zukünftigen Arbeitgeber in der Automobilindustrie zeigen, dass Du auch auf sowas achtest. Ist ja schließlich Deine Eintrittskarte. fchk
:
Bearbeitet durch User
Maximilian R. schrieb: > Problem an dem ESP32 ist nur, > dass noch nicht alles funktioniert und dass er mir für meine Anwendung > fast ein wenig zu überdimensioniert erscheint. Das größte Problem am ESP32 ist meiner Meinung nach die mangelnde Dokumentation, in Kombination mit Binary-Blobs an jeder Ecke. Habe selber in letzter Zeit ein bisschen damit rumgespielt und kann nur sagen, dass das ESP-IDF insgesamt schon um Welten besser als die SDKs vom ESP8266 sind aber für ernsthafte Anwendungen wäre mir das noch zu sehr im Beta-Stadium (auch wenn jetzt Version 2.0 erschienen ist). Die Zeit während meiner Master-Arbeit wöllte ich jedenfalls nicht damit verbringen wollen, mich durch dieses SDK zu wursteln. Arduino-Unterstützung ist auch allenfalls Beta, gerade im Hinblick auf BLE, was ja ein zentrales Element deiner Arbeit ist. Als Alternative würde ich mal die NRF-Serie von Nordic einwerfen. Die sind hervorragend dokumentiert und auch nicht erst seit gestern auf dem Markt. Ein NRF-52 DK Entwicklungsboard gibt es zwar nicht geschenkt aber mit ~50€ auf jeden Fall bezahlbar. Da ist dann auch schon gleich ein J-Link OB mit an Board und im Gegensatz zum ESP32 ist es relativ einfach eine funktionierende Debugging-Lösung aufzusetzen. Mit den NRF52 hast du auch gleich Support für Bluetooth 5 mit dabei, was eventuell interessant sein könnte in Bezug auf die "long range" Funktionalität, je nachdem was du mit BLE vorhast.
@Frank Danke für deine Beiträge, ich glaube das hätte ne Weile gedauert bis ich auf das alles selbst gekommen wäre ? Ich hatte auch schon einen TI Chip auf dem Schirm. Aber ist nicht das "Problem" an den TI Chips dass man fast die IDE dazu braucht und die ist ja nicht billig? @Christopher Die nrf52 Reihe gefällt mir auch. Zumal es die IDE dazu gibt. Was hältst du davon z. B.: http://redbearlab.com/nrf51822/ Wobei mir natürlich die automotive Auslegung vom TI besser gefällt. Gruß Maximilian
Maximilian H. schrieb: > @Frank > Danke für deine Beiträge, ich glaube das hätte ne Weile gedauert bis ich > auf das alles selbst gekommen wäre ? > > Ich hatte auch schon einen TI Chip auf dem Schirm. Aber ist nicht das > "Problem" an den TI Chips dass man fast die IDE dazu braucht und die ist > ja nicht billig? Für die 8051-Teile (2540/41) brauchst Du IAR, und der ist teuer. Nordic und NXP haben/hatten auch 8051-SOCs, und für die brauchtest Du auch entweder Keil oder IAR. Die 26xx haben ARM-Kerne, und dafür kannst Du entweder IAR verwenden oder den TI CCS. Letzteres ist - meine ich - inzwischen frei, und zumindest für die 6'er (und ältere) Version kannst Du Dir jetzt ein Lizenzfile einfach so runterladen. Aktuell ist die 7'er, und die habe ich noch nicht getestet. http://processors.wiki.ti.com/index.php/Download_CCS Und dann gibts noch: http://www.ti.com/lit/an/swra446/swra446.pdf Als Debugger empfiehlt sich ein XDS100v3. V3 dahinter ist wichtig. http://processors.wiki.ti.com/index.php/XDS100 Das Original ist von Spectrum Digital, die auch viele Entwicklungsboards für TI machen. http://www.spectrumdigital.com/xds100v3-usb-cjtag-jtag-emulator/ Nachbau von Olimex (hat 0.1" JTAG Anschlüsse statt 0.05" wie bei TI/SDS): https://www.olimex.com/Products/DSP/Emulators/TMS320-XDS100-V3/ Antennendesign: Das ist das wirklich schwierige, wenn Du es selber machen willst. Da schaust Du hier http://www.ti.com/lit/an/swra496/swra496.pdf http://www.ti.com/tool/cc-antenna-dk2 suchst Dir eines für 2.4 GHz aus, nimmst Dir die Gerber-Daten und übernimmst die in Dein Design. Oder nimm ein Demoboard und pinn den entsprechenden Teil einfach ab. Dafür sind die da. Die Gerberdateien gibts alle zum Runterladen. > http://redbearlab.com/nrf51822/ Davon gibts keine Automotive-Version, und die UARTs haben keinen LIN-Support. Also Daumen runter. Gilt auch für die nrf52*. fchk
Frank K. schrieb: > Davon gibts keine Automotive-Version, und die UARTs haben keinen > LIN-Support. Also Daumen runter. Gilt auch für die nrf52*. Ja, stimmt beides. Das mit der Automotive-Version habe ich auch erst bedacht als ich deinen Post gelesen hatte. Für das Vorhaben des TO sind die CC2640 von TI mit Sicherheit besser geeignet. Maximilian H. schrieb: > @Christopher > Die nrf52 Reihe gefällt mir auch. Zumal es die IDE dazu gibt. Was hältst > du davon z. B.: > http://redbearlab.com/nrf51822/ Ich habe selber in letzter Zeit quasi ausschließlich QT-Creator in Kombination mit Makefiles genutzt, weil ich das von der Portierbarkeit und von der Geschwindigkeit her jeglichen anderen IDEs vorziehe. Das ist allerdings mit etwas Aufwand bei der Einrichtung verbunden und es gibt keine Projektwizards wo man sich durchhangeln kann. Wenn du einen Chip von TI einsetzt würde ich an deiner Stelle mit Sicherheit zu CCS greifen. Am Ende sind ohnehin so gut wie alle IDEs der Hersteller Eclipse-basiert und wenn du weißt wie die Dinge zusammenhängen kannst du dir auch ein "normales" Eclipse nehmen und damit entwickeln. Das geht dann aber auf Kosten des Komforts, weil du z.B. nicht einfach so ein Projekt mit Beispielcode des Herstellers öffnen kannst. Für NRF wäre in diesem Sinne vermutlich Keil die komfortabelste Lösung aber das MDK gibt es leider nicht für lau und mit der 32kB limitierten Lite-Version wird das sicher nix mit Bluetooth. TI CC2640 mit CCS ist für dich vermutlich die beste Wahl.
Hallo, Frank K. schrieb: > Und dann gibts noch: > http://www.ti.com/lit/an/swra446/swra446.pdf > > Als Debugger empfiehlt sich ein XDS100v3. V3 dahinter ist wichtig. > > http://processors.wiki.ti.com/index.php/XDS100 > > Das Original ist von Spectrum Digital, die auch viele Entwicklungsboards > für TI machen. > http://www.spectrumdigital.com/xds100v3-usb-cjtag-jtag-emulator/ > Nachbau von Olimex (hat 0.1" JTAG Anschlüsse statt 0.05" wie bei > TI/SDS): > https://www.olimex.com/Products/DSP/Emulators/TMS320-XDS100-V3/ Jetzt ist es wieder soweit - ich bin ausgestiegen :-) So wie ich das verstehe, brauche ich das TMS320-XDS100-V3 um mein Board dann zu evaluieren? Da für mich aber auch das Programmieren zu größten Teilen Neuland ist, würde ich vorerst versuchen, meinen Code zu entwickeln um Probleme mit der Hardware ausschließen zu können. Kann ich da nicht mit dem hier beginnen? http://www.ti.com/tool/LAUNCHXL-CC2640R2#1 Frank K. schrieb: > Antennendesign: > Das ist das wirklich schwierige, wenn Du es selber machen willst. Ja, dass das eine Herausforderung nach meinen bisherigen Recherchen. Ich hatte gehofft, ich kann das "umschiffen" in dem ich so etwas verwenden: http://ecksteinimg.de/Photo/CP06059/pin.png Natürlich nicht auf Basis des ESP32, ich denke der ist für mein Vorhaben raus. Reinlesen kann man sich in fast alles, aber ich muss auch bis zum 10. August fix und fertig sein. Für den TI wird es aber sowas nicht geben und ich denke es ist weiterhin nicht Automotive kompatibel. Verzeiht mit bitte die einfachen Fragen, ich muss noch viel lernen... ;-) Gruß Maximilian
Maximilian H. schrieb: > Hallo, > > Frank K. schrieb: >> Und dann gibts noch: >> http://www.ti.com/lit/an/swra446/swra446.pdf >> >> Als Debugger empfiehlt sich ein XDS100v3. V3 dahinter ist wichtig. >> >> http://processors.wiki.ti.com/index.php/XDS100 >> >> Das Original ist von Spectrum Digital, die auch viele Entwicklungsboards >> für TI machen. >> http://www.spectrumdigital.com/xds100v3-usb-cjtag-jtag-emulator/ >> Nachbau von Olimex (hat 0.1" JTAG Anschlüsse statt 0.05" wie bei >> TI/SDS): >> https://www.olimex.com/Products/DSP/Emulators/TMS320-XDS100-V3/ > > Jetzt ist es wieder soweit - ich bin ausgestiegen :-) So wie ich das > verstehe, brauche ich das TMS320-XDS100-V3 um mein Board dann zu > evaluieren? > > Da für mich aber auch das Programmieren zu größten Teilen Neuland ist, > würde ich vorerst versuchen, meinen Code zu entwickeln um Probleme mit > der Hardware ausschließen zu können. Kann ich da nicht mit dem hier > beginnen? > > http://www.ti.com/tool/LAUNCHXL-CC2640R2#1 Ja. Da ist ein XDS100V3 bereits drauf und eine Antenne dran. > Frank K. schrieb: >> Antennendesign: >> Das ist das wirklich schwierige, wenn Du es selber machen willst. > > Ja, dass das eine Herausforderung nach meinen bisherigen Recherchen. Ich > hatte gehofft, ich kann das "umschiffen" in dem ich so etwas verwenden: > http://ecksteinimg.de/Photo/CP06059/pin.png > Natürlich nicht auf Basis des ESP32, ich denke der ist für mein Vorhaben > raus. > Reinlesen kann man sich in fast alles, aber ich muss auch bis zum 10. > August fix und fertig sein. oh, das ist knapp. Zu knapp. Dann bleib beim Launchpad als Basis. fchk
Frank K. schrieb: > oh, das ist knapp. Zu knapp. Dann bleib beim Launchpad als Basis. Wie meinst du das? Es sollte schon eine Platine rauskommen, die ich in ein eigenes Gehäuse bauen kann um das Modul möglichst direkt am Slave zu positionieren. Gruß Maximilian
Maximilian H. schrieb: > Frank K. schrieb: >> oh, das ist knapp. Zu knapp. Dann bleib beim Launchpad als Basis. > > Wie meinst du das? Es sollte schon eine Platine rauskommen, die ich in > ein eigenes Gehäuse bauen kann um das Modul möglichst direkt am Slave zu > positionieren. Dann hoffe ich, dass Du Dich nicht noch in das Layoutprogramm einarbeiten musst. Drei Monate sind schneller um als Du denkst. Die Beschaltung an sich ist kein Problem. Fürs Launchpad gibts die kompletten Unterlagen, das kannst Du 1:1 schaltungstechnisch übernehmen. Beim Layout ist etwas Erfahrung hilfreich. fchk
Frank K. schrieb: > Maximilian H. schrieb: >> Frank K. schrieb: >>> oh, das ist knapp. Zu knapp. Dann bleib beim Launchpad als Basis. >> >> Wie meinst du das? Es sollte schon eine Platine rauskommen, die ich in >> ein eigenes Gehäuse bauen kann um das Modul möglichst direkt am Slave zu >> positionieren. > > Dann hoffe ich, dass Du Dich nicht noch in das Layoutprogramm > einarbeiten musst. Drei Monate sind schneller um als Du denkst. > > Die Beschaltung an sich ist kein Problem. Fürs Launchpad gibts die > kompletten Unterlagen, das kannst Du 1:1 schaltungstechnisch übernehmen. > Beim Layout ist etwas Erfahrung hilfreich. > > fchk Deine Einschätzungen helfen mir wirklich sehr! Mit Eagle hatte ich schon mal gearbeitet und mein Nachbar ist ehemaliger Inhaber von Cadsoft (der damaligen Firma von Eagle). Daher hoffe ich mal das Beste. Schwierig ist es für mich allemal, weil ich aus einem ganz anderem Bereich komme. Aber das weiß mein Prof. natürlich auch und er meinte auch, er würde es angepasst bewerten. Rein beruflich ist es nicht relevant, da steht mein Weg und auch die Anstellung. Deswegen muss ich bis zum 10. August fertig werden. An sich werde ich mich mit dem Projekt bestimmt noch länger beschäftigen. Gruß Maximilian
Hier gibt es das für den CAN-Bus bereits fertig zu kaufen. Kann man vielleicht einmal anschauen um schneller arbeiten zu können. Gesteuert wird nur 1 Slave (Ladedrucksensor) mit Spannungsteilern (meines Erachtens). https://www.racechip.de/shop/vw/golf-vii-ab-2012/2-0-tsi-r-1984ccm-300ps-221kw-380nm.html
Christopher J. schrieb: > Als Alternative würde ich mal die NRF-Serie von Nordic einwerfen. Da geht IMHO das mit dem LIN Bus nicht ohne weiteres - der UART hat praktisch nur Basis Funktionalität. Ich würde hier mal Silicon Labs EFR32 Serie einwerfen. Die haben bessere UARTs (für LIN) und es gibt sie fertich z.B. als BGM113 Module - da braucht man nicht den 2,4 GHz HF Kram beim Layouten zu beachten. Die Software Entwicklung würde ich mit einem Starter Kit (z.B. SLWSTK6101C) anfangen - da hat man dann gleich einen Programmer und Debugger dabei. Neuerdings kann man auch GCC für den Bluetooth Krams verwenden. Silabs stellt für die Software Entwicklung das Simplicity Studio zur Verfügung, das basiert auf Eclipse.
:
Bearbeitet durch User
John schrieb: > Hier gibt es das für den CAN-Bus bereits fertig zu kaufen. Kann man > vielleicht einmal anschauen um schneller arbeiten zu können. > Gesteuert wird nur 1 Slave (Ladedrucksensor) mit Spannungsteilern > (meines Erachtens). > > https://www.racechip.de/shop/vw/golf-vii-ab-2012/2-0-tsi-r-1984ccm-300ps-221kw-380nm.html Da ist wohl ein CC2540 "unter der Haube": http://www.blueradios.com/nBlue%20BR-LE4.0-S2%20Summary%20Datasheet.pdf Kann man da ganz gut erkennen: https://www.racechip.com/media/wysiwyg/product_page_gallery/2_EN.jpg Eingesetzt wird aber der bestimmt nur zur Kommunikation. Der CC2540 wäre nicht schlecht, aber ohne die IAR... @Frank Ich hab mir das Datenblatt vom CC2640 angesehen: Wo kann ich rauslesen, dass er über die UARTs den LIN-Break erzeugen kann? Jim M. schrieb: > Ich würde hier mal Silicon Labs EFR32 Serie einwerfen. Die haben bessere > UARTs (für LIN) und es gibt sie fertich z.B. als BGM113 Module - da > braucht man nicht den 2,4 GHz HF Kram beim Layouten zu beachten. Hatte ich auch schon in meiner engeren Auswahl und dachte auch, so den Antennenkram zu "umschiffen". Btw: Weiß jemand eine gute Quelle, wo es die Entwicklerboards nicht mit 6 Wochen Lieferzeit gibt? Gruß Maximilian
Da ist wohl ein CC2540 "unter der Haube" Ich glaube nicht, hier ist das richtige Foto: http://www.bmwfanatics.co.za/uploads/user/208/20151219_150121_4284814293.jpg Aber ich kann nichts erkennen?
John schrieb: > Ich glaube nicht, hier ist das richtige Foto: > > http://www.bmwfanatics.co.za/uploads/user/208/20151219_150121_4284814293.jpg > > Aber ich kann nichts erkennen? Sieht aber genauso aus wie das hier: http://www.blueradios.com/nBlue%20BR-LE4.0-S2%20Summary%20Datasheet.pdf
Maximilian H. schrieb: > Ich hab mir das Datenblatt vom CC2640 angesehen: Wo kann ich rauslesen, > dass er über die UARTs den LIN-Break erzeugen kann? http://www.ti.com/lit/pdf/swcu117 Seite 1445 "line-break generation and detection" Seite 1454 BE Bit Seite 1463 Die CC25xx haben das nicht, wieder die 8051 noch die ARM-SOCs. > Btw: Weiß jemand eine gute Quelle, wo es die Entwicklerboards nicht mit > 6 Wochen Lieferzeit gibt? Mouser hat vom LAUNCHXL-CC2640R2 35 Stück auf Lager. fchk
:
Bearbeitet durch User
Frank K. schrieb: > Mouser hat vom LAUNCHXL-CC2640R2 35 Stück auf Lager. Wer lesen kann ist klar im Vorteil... Ich hatte nur die 6 Wochen gelesen. :-/ -> Ist bestellt Frank K. schrieb: > http://www.ti.com/lit/pdf/swcu117 > Seite 1445 "line-break generation and detection" > Seite 1454 BE Bit > Seite 1463 Ganz klar ist mir das aber immer noch nicht: Kann der das BREAK-Signal auch über die geforderte 13 Bit erzeugen? Alle Beiträge die ich hier im Forum finde, machen es über Baudratenumschaltung. Gruß Maximilian
:
Bearbeitet durch User
Maximilian H. schrieb: > Frank K. schrieb: >> Mouser hat vom LAUNCHXL-CC2640R2 35 Stück auf Lager. > > Wer lesen kann ist klar im Vorteil... Ich hatte nur die 6 Wochen > gelesen. :-/ > > -> Ist bestellt > > Frank K. schrieb: >> http://www.ti.com/lit/pdf/swcu117 >> Seite 1445 "line-break generation and detection" >> Seite 1454 BE Bit >> Seite 1463 > > Ganz klar ist mir das aber immer noch nicht: Kann der das BREAK-Signal > auch über die geforderte 13 Bit erzeugen? Das sollte über das Bit auf Seite 1463 gehen. Eventuell musst Du das Timing selber machen. Dann einfach Bit setzen, zwei beliebige Bytes ausgeben und warten, bis die aus dem Transmit Buffer raus sind, und dann Bit wieder löschen. Das sind dann zwar 20 Bitzeiten, aber das ist egal. 13 Bitzeiten sind ja nur der Minimalwert. fchk
Ich habe hier mal das CCS 7.1.0 gezogen und installiert, und es hat nicht nach irgendwelchen Lizenzfiles oder gefragt. fchk
Frank K. schrieb: > Ich habe hier mal das CCS 7.1.0 gezogen und installiert, und es hat > nicht nach irgendwelchen Lizenzfiles oder gefragt. Hatte ich auch installiert. Ebenfalls ohne Lizenzierung. Gruß Maximilian
Das muss sein, wegen Training und Workshop mit CC1310 usw.. Die Files werden wohl später abgefragt (angeschlossenes Board). http://processors.wiki.ti.com/index.php/Category:CCSv7_Training
So, nachdem das Launchpad jetzt da ist und ich auch schon ein paar Examples durch habe, stelle ich mir die Frage: Gleich auf TI-RTOS beginnen oder ohne? Weiß wer ein gutes Tutorial was die UART Kommunikation angeht? Danke und viele Grüße
Thread beobachten
Seitenaufteilung abschalten
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.