Hi Leute, ich wollte euch mal fragen, ob ihr schonmal an sowas gearbeitet habt oder einige Grundsatzfragen zu einem Bluetooth AVR ISP Programmer beantworten könntet, da ich möglicherweise gerne soetwas für einen Roboter bauen würde : 1. Wie kann man mit einem AVR via Bluetooth Daten von PC an den MC senden und zurück? Ich habe bisher immer eine RS232 Schnittstelle verwendet, und einen MAX232 der mir das ganze bequem umgewandelt hat. Gibt es soetwas auch für Bluetooth? 2. Ist es sinnvoll, dass man einen Programmer IC hat, der das Programm vom Computer empfängt und in einen Speicher einspeichert, und nach dem Empfangen des Programms einen zweiten IC mit der Software programmiert? (sozusagen einen AVR ISP Programmer) 3. Wie kann man einen AVR programmieren? Ich habe kein Tutorial zum Kommunikationsprotokoll finden können. Gibt es auch einfache Beispielcodes für den Programmer-AVR in C ? 4. Die Bluetoothmodule die ich finden kann sind doch recht teuer, wohingegen es doch für PCs diese kleinen FunkUSB Bausteine gibt (z.B: bei einer Funkmaus) die bis zu 5 € kosten, wäre soetwas sinnvoll zu verwenden, und wenn ja wie ? Ich hoffe ich stelle keine allzu allgemeinen Fragen, und hoffe auf einige produktive Antworten, falls meine Fragen so keinen Sinn machen bitte ich um eine Aufklärung. Danke sehr, m.f.G.: Developer_X
K. R. schrieb: > 1. Wie kann man mit einem AVR via Bluetooth Daten von PC an den MC > senden und zurück? Ich habe bisher immer eine RS232 Schnittstelle > verwendet, und einen MAX232 der mir das ganze bequem umgewandelt hat. > Gibt es soetwas auch für Bluetooth? Ein BTM-222 beispielsweise nimmt und liefert 3.3V CMOS-Signale über UART. Das gibt es auch noch als BTM-112, BTM-180 und BTM-182 und noch einige andere. K. R. schrieb: > 2. Ist es sinnvoll, dass man einen Programmer IC hat, der das Programm > vom Computer empfängt und in einen Speicher einspeichert, und nach dem > Empfangen des Programms einen zweiten IC mit der Software programmiert? > (sozusagen einen AVR ISP Programmer) Ja, ist unter Umständen sinnvoll. Wenn der zu programmierende Controller aber schon über einen Bootloader verfügt, der mit dem BTM-xxx kommunizieren kann, dann braucht es das aufwändigere ISP-Geraffel nicht und man kommt mit 2 Pins (RX/TX) und Masse aus. K. R. schrieb: > 3. Wie kann man einen AVR programmieren? Ich habe kein Tutorial zum > Kommunikationsprotokoll finden können. Gibt es auch einfache > Beispielcodes für den Programmer-AVR in C ? Ein AVR kann sich selbt programmieren. Dazu findest Du den Abschnitt "Self programming..." im Datenblatt. Weiterhin kannst Du natürlich auch die ISP-Schnittstelle verwenden, dann findest Du im Datenblatt "External programming..." die entsprechenden Hinweise. K. R. schrieb: > 4. Die Bluetoothmodule die ich finden kann sind doch recht teuer, > wohingegen es doch für PCs diese kleinen FunkUSB Bausteine gibt (z.B: > bei einer Funkmaus) die bis zu 5 € kosten, wäre soetwas sinnvoll zu > verwenden, und wenn ja wie ? Die herkömmichen Computerbausteine sprechen "USB device". Da Dein AVR kein USB-Host ist, kannste das vergessen. Die BTM-xxx Module gehen bei etwa 7EUR los, je nach Anbieter. Vorteil: sie funktionieren an jeder herkömmlichen UART (aber nur 3.3V kompatibel!).
:
Bearbeitet durch User
Das mit dem BTM hört sich gut an, dazu eine Frage, ich möchte nicht blöd wirken aber: Für das BTM Modul benötigt man ja noch zusätzlich einen Bluetooth sender und empfänger für den PC, einfach so nen bluetooth usb für den PC? Ist der in Ordnung? http://www.csd-electronics.de/200/cgi-bin/shop.dll?AnbieterID=2&bnr=30401&referer=googlebase&gclid=CPDZoJaF3cICFcSWtAodxhsAwA&PKEY=258C&Hauptseite=detail.htm Ich finde nirgendwo im Netz ein Bluetooth Modul BTM 112, jedenfalls nicht von deutschen Lieferanten außer CSD Electronics. http://www.pollin.de/shop/suchergebnis.html?S_TEXT=bluetooth+modul&log=internal Bei Pollin giebt es einen BTM USB und ein Modul, die aber wahrscheinlich nichts mit meinem Problem zu tun haben oder? Danke für die tolle Antwort, m.f.G.: Developer_X
K. R. schrieb: > 3. Wie kann man einen AVR programmieren? Ich habe kein Tutorial zum > Kommunikationsprotokoll finden können. Gibt es auch einfache > Beispielcodes für den Programmer-AVR in C ? Lies das hier. Da ist das Verfahren genau erklärt. http://www.atmel.com/images/doc0943.pdf > 4. Die Bluetoothmodule die ich finden kann sind doch recht teuer, > wohingegen es doch für PCs diese kleinen FunkUSB Bausteine gibt (z.B: > bei einer Funkmaus) die bis zu 5 € kosten, wäre soetwas sinnvoll zu > verwenden, und wenn ja wie ? Bluetooth besteht aus mehreren Protokollschichten. Die PC-USB-Stecker haben nur die unterst Schicht, das HCI eingebaut, den Rest muss der PC machen, was kein Problem ist. Die seriellen Module für Mikrocontroller hingegen müssen ALLE Schichten des Protokolls selber intern verarbeiten. Deswegen muss der Rechner darin größer und leistungsfähiger sein, und das macht die Module teurer. Die Spezifikationen von Bluetooth umfassen mehrere 1000 Seiten. fchk PS: ebay# 271068413249 ist das, was Du brauchst. Für den PC reicht jeder beliebige USB-BT-Stecker aus.
Frank K. schrieb: > PS: ebay# 271068413249 ist das, was Du brauchst. Für den PC reicht jeder > beliebige USB-BT-Stecker aus. Danke sehr, so ein USB BT z.B.? http://www.amazon.de/LogiLink-BT0015-bluetooth-Class1-Micro/dp/B0096Y2HFW/ref=sr_1_2?ie=UTF8&qid=1419370695&sr=8-2&keywords=bt+usb+stick Knut Ballhause schrieb: > Ja, ist unter Umständen sinnvoll. Wenn der zu programmierende Controller > aber schon über einen Bootloader verfügt, der mit dem BTM-xxx > kommunizieren kann, dann braucht es das aufwändigere ISP-Geraffel nicht > und man kommt mit 2 Pins (RX/TX) und Masse aus. Das hört sich gut an, ist ja so machbar wie in diesem Tutorial, nicht? http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung Nur dass man keinen USB Decoder Chip bräuchte, sondern dass einfach mit RXTX wie bei RS232 machen könnte. Danke, m.f.G.: Developer_X
Ich hab den Artikel kurz überflogen und werde ihn noch ganz lesen, aber zur kurzen Verständnisfrage: Ich habe einen Atmega und speichere einmalig mit einer normalen ISP Schnittstelle das Programm ab. Wenn nun der Atmega Stromversorgung hat, würde er das Programm im Flash starten, und nicht den Bootloader. Kann man dann trotzdem "normal" mit dem MC kommunizieren, über die RX TX Schnittstelle (UART) ohne diesen flashen zu wollen, auch wenn man ein Programm im Bootloader stehen hat? Kann man beliebig umschalten, ferngesteuert, zwischen flashen und normaler Kommunikation? Ich fände es gut, wenn man z.B. festlegen könnte, dass wenn über den USART die Sequenz "F-L-A-S-H" hineinkommen würde, dass dann der MC auf den Bootloader Modus überspringt, und dann geflashed wird, nachher aber wieder wie ein ganz normaler MC funktioniert, auch nach Resets. Ich will generell nur wissen was wie mit welchem Aufwand möglich ist, durch aus werde ich mich einarbeiten, ich will nur im Voraus wissen, inwieweit ich den Umfang abschätzen kann. m.f.G.: Developer_X
:
Bearbeitet durch User
K. R. schrieb: > Frank K. schrieb: >> PS: ebay# 271068413249 ist das, was Du brauchst. Für den PC reicht jeder >> beliebige USB-BT-Stecker aus. > > Danke sehr, so ein USB BT z.B.? > http://www.amazon.de/LogiLink-BT0015-bluetooth-Class1-Micro/dp/B0096Y2HFW/ref=sr_1_2?ie=UTF8&qid=1419370695&sr=8-2&keywords=bt+usb+stick ja, genau.
K. R. schrieb: > ch finde nirgendwo im Netz ein Bluetooth Modul BTM 112, jedenfalls > nicht von deutschen Lieferanten außer CSD Electronics. Guck mal hier: http://www.soselectronic.de/?str=371&artnum=103628&name=rayson-btm-182 K. R. schrieb: > Wenn nun der Atmega Stromversorgung hat, würde er das Programm im Flash > starten, und nicht den Bootloader. Nicht unbedingt. Das kann man per Fuse einstellen, in welcher Sektion der ATMEGA startet. Wenn der Bootloader zuerst losläuft, wartet dieser eine Zeit lang auf ein Magic. Wenn dies nicht kommt und sich ein gültiges Programm in der Application Section befindet, wirt dorthin gesprungen. K. R. schrieb: > Kann man dann trotzdem "normal" mit dem MC kommunizieren, über die RX TX > Schnittstelle (UART) ohne diesen flashen zu wollen, auch wenn man ein > Programm im Bootloader stehen hat? Klaro. Das bestimmst Du mit Deinem Bootloader und Deinem Programm selbst. K. R. schrieb: > Ich fände es gut, wenn man z.B. festlegen könnte, dass wenn über den > USART die Sequenz "F-L-A-S-H" hineinkommen würde, dass dann der MC auf > den Bootloader Modus überspringt, und dann geflashed wird, nachher aber > wieder wie ein ganz normaler MC funktioniert, auch nach Resets. Kein Problem. K. R. schrieb: > Ich will generell nur wissen was wie mit welchem Aufwand möglich ist, > durch aus werde ich mich einarbeiten, ich will nur im Voraus wissen, > inwieweit ich den Umfang abschätzen kann. Der einzige Aufwand besteht darin, sowohl Bootloader als auch Programm zu erstellen, und zwar so, dass alles reibungslos funktioniert. Du kannst Dir die Sachen auch fast fertig aus dem Netz laden, musst aber trotzdem verstehen, was genau da vor sich geht, um später Änderungen machen zu können.
Berücksichtige, dass Bluetooth eine Funkverbindung ist. Da werden ab und zu falsche Zeichen übertragen. Manchmal gehen auch welche verloren. Dein Bootloader sollte Prüfsummen benutzen, und fehlerhafte Blöcke erneut anfordern. Außerdem sollte man ihn notfalls auch bei defektem Programm starten können, damit man den Flash-Vorgang bei Bedarf wiederholen kann. Du könntest dich dazu mal in das X-Modem Protokoll einlesen, da wird so eine Fehlerkorrektur gemacht. Alternativ zum BTM-222 kannst du auch HC-05 oder HC-06 Module verwenden. Die sind billiger und im Arduino Umfeld beliebt, daher leichter zu bekommen.
Ok, dann erstmal danke für die zahlreichen und sehr produktiven Beiträge von euch. Zwei letze Frage habe ich da noch: 1)Kann es sein, dass es Probleme gibt, wenn man noch eine Funkmaus hat (die geht ja eigentlich auf über BT oder?) 2) Stefan Us schrieb: > Berücksichtige, dass Bluetooth eine Funkverbindung ist. Da werden ab und > zu falsche Zeichen übertragen. Manchmal gehen auch welche verloren. > > Dein Bootloader sollte Prüfsummen benutzen, und fehlerhafte Blöcke > erneut anfordern. Außerdem sollte man ihn notfalls auch bei defektem > Programm starten können, damit man den Flash-Vorgang bei Bedarf > wiederholen kann. Ich werde mich mal in die Artikel einlesen, denkst du trotzdem, dass dies unmöglich wäre? Was man auch machen könnte wäre, das Programm zu senden, und der Bootloader sendet das Programm am Ende nocheinmal zurück, dann kann man das am PC sehen und gegfalls sagen, an welcher Speicheradresse Änderungen vorgenommen werden sollen, bevor er das Programm startet. Sind solche Fehler die Regel, oder ganz selten, dass man sich eigentlich keine Gedanken darum machen braucht, wenn man das ganze betreibt? Danke, m.f.G.: Developer_X
K. R. schrieb: > Zwei letze Frage habe ich da noch: > 1)Kann es sein, dass es Probleme gibt, wenn man noch eine Funkmaus hat > (die geht ja eigentlich auf über BT oder?) Wenn Du einen Apfelrechner hast, dann hast Du sehr wahrscheinlich eine echte BT-Funkmaus. PCs haben eher selten BT, und die Funkmäuse dort verwenden ein proprietäres Protokoll. Normal gibts keine Probleme, aber ausschließen kann man das nicht. > Sind solche Fehler die Regel, oder ganz selten, dass man sich eigentlich > keine Gedanken darum machen braucht, wenn man das ganze betreibt? Kommt darauf an, was sonst noch in der Nähe ist. Der 2.4 GHz Bereich wird von allem Möglichen Zeugs verwendet: WLAN, BT, Babyfone, Fernsteuerungen für Modellbau, Kameras,... Ganz sicher gehst Du, wenn Du ein serielles SPI-SRAM einbaust (gibt es bis zu 128k), den Code erst einmal dort hinein lädst, und erst dann die Flashroutine startest, wenn der gesamte Code vollständig und richtig im SPI-SRAM steht. SPI-SRAM gibts hier: http://www.microchip.com/pagehandler/en-us/products/memory/serialSRAM/home.html fchk
Stefan Us schrieb: > Berücksichtige, dass Bluetooth eine Funkverbindung ist. Da werden ab und > zu falsche Zeichen übertragen. Manchmal gehen auch welche verloren. Das ist mir noch nie passiert! Bluetooth ist nämlich eine Verbindung, die entweder Daten überträgt oder nicht. Falsche Daten werden nicht übertragen, da das Protokoll CRC-gesichert ist. Kommt es zu Fehlern auf der Luftstrecke, werden die Pakete widerholt, bis eine erfolgreiche Übertragung stattgefunden hat oder bis ein Abbruch (Timeout) erfolgt ist. Im Controller braucht es einen kleinen Ringpuffer für 16 Characters, da auch beim Sperren des Streams auf dem empfangenden BTM-xxx per /CTS noch einige Zeichen des gerade empfangenen Pakets aus dem Modul purzeln können. Stefan Us schrieb: > Dein Bootloader sollte Prüfsummen benutzen, und fehlerhafte Blöcke > erneut anfordern. Nicht nötig. Stefan Us schrieb: > Außerdem sollte man ihn notfalls auch bei defektem > Programm starten können, damit man den Flash-Vorgang bei Bedarf > wiederholen kann. Ja, zum Beispiel über eine Taste oder einen erneuten Power-Up. Stefan Us schrieb: > Du könntest dich dazu mal in das X-Modem Protokoll einlesen, da wird so > eine Fehlerkorrektur gemacht. Unnötig. K. R. schrieb: > 1)Kann es sein, dass es Probleme gibt, wenn man noch eine Funkmaus hat > (die geht ja eigentlich auf über BT oder?) Bluetooth nutzt Frequency Hopping. Somit sind keine Interferenzen mit anderen Bluetooth-Geräten im Raum zu erwarten. Frank K. schrieb: > Kommt darauf an, was sonst noch in der Nähe ist. Der 2.4 GHz Bereich > wird von allem Möglichen Zeugs verwendet: WLAN, BT, Babyfone, > Fernsteuerungen für Modellbau, Kameras,... Kein Problem für Bluetooth, es wird dadurch höchstens etwas langsamer, aber nicht ernsthaft beeinträchtigt. Frank K. schrieb: > Ganz sicher gehst Du, wenn Du ein serielles SPI-SRAM einbaust (gibt es > bis zu 128k), den Code erst einmal dort hinein lädst, und erst dann die > Flashroutine startest, wenn der gesamte Code vollständig und richtig im > SPI-SRAM steht. Nicht nötig.
OK dann erstmal danke für eure Antworten, ich glaube ich werde dann erstmal klein mit einer BT Kommunikation anfagen, mit MC und Terminal Programm, und wenn das alles Funktioniert, wage ich mich an einen Bootloader. Danke für tollen Antworten, m.f.G.: Developer_X
> Sind solche Fehler die Regel, oder ganz selten, dass > man sich eigentlich keine Gedanken darum machen braucht, > wenn man das ganze betreibt? In funktechnisch verseuchter Umgebung (z.B. bei mir zuhause) kommen Übertragungsfehler so häufig vor, dass selbst die eigebauten Korrekturmechanismen mehrmals pro Stunde versagen. Ich beobachte diese Effekte bei allen drahtlosen Verbindungen in meiner Wohnung. Vermutlich hatte Knut bisher das Glück, in einer wenig gestörten Umgebung sein. Kennst du das schöne Sprichwort: Wer Funk kennt, nimmt Kabel?
Stefan Us schrieb: > Kennst du das schöne Sprichwort: Wer Funk kennt, nimmt Kabel? Guter Witz. Lol. Ich denke das muss jeder bei sich zu Hause testen, ich würde aber echt Bedenken haben, wenn ich einer funktechnisch stark verseuchten Umgebung leben würde ;).
K. R. schrieb: > ich wollte euch mal fragen, ob ihr schonmal an sowas gearbeitet habt Ja. Die Ergebnisse davon sind: * ein angepasster Bootloader auf Basis von Optiboot * die Programmer Software (BlueC_ISP) * ein angepasster avrdude (erweitertes STK500 1.x Protokoll) * eine Kalibrierung des Quarz-Oszillators damit die serielle Kommunikation stabil läuft (Calibrate_BlueController_OSCCAL_by_UART) Warum ein angepasster avrdude und ein erweitertes Übertragungsprotokoll? Ganz einfach, weil das Standard Übertragungsprotokoll nicht gut mit großen Latenzzeiten zurechtkommt und das Programmieren ewig dauert, zumindest auf meinem Mac, bei dem die Tastatur und Maus auch über Bluetooth angeschlossen sind. Der Unterschied liegt bei ca. Faktor 20 und mehr. Als Hardware-Basis habe ich den BlueController mit ATMega88P verwendet, da ist das Bluetooth Modul BTM-222 bereits onboard. Viel Platz im Flash bleibt beim ATmega88P aber nicht mehr, daher empfehle ich den ATmega328P. Der Bluecontroller läuft intern mit 3,3V und 8 MHz Takt (interner Oszillator, kein Quartz). Er hat bereits Levelshifter eingebaut und kann so auch 5V Targets programmieren. Man kann natürlich auch jeden anderen Bluetooth Chip nehmen, es wurden ja bereits einige genannt. > 1. Wie kann man mit einem AVR via Bluetooth Daten von PC an den MC > senden und zurück? Ich habe bisher immer eine RS232 Schnittstelle 115200 Baud sind kein Problem, sofern der interne Oszillator entsprechend auf die serielle Baudrate kalibriert wurde (und nicht auf 8 Mhz). Mit einen Quarz bzw. ohne Kalibrierung wird dies nicht stabil laufen, da die tatsächliche Baudrate dann 111111 und nicht 115200 beträgt. Bei einigen Bluetooth Modulen liegt dies außerhalb des Toleranzbereichs. > 2. Ist es sinnvoll, dass man einen Programmer IC hat, der das Programm > vom Computer empfängt und in einen Speicher einspeichert, und nach dem > Empfangen des Programms einen zweiten IC mit der Software programmiert? > (sozusagen einen AVR ISP Programmer) Das hängt von der Performance ab, welche du benötigt. Mit dem angepassten Bootloader kannst du das auch ohne externen Programmer machen. Das ganze Projekt findest Du hier: https://code.google.com/r/michaeldreher42-bluecontroller/ Direkter Download-Link: https://michaeldreher42-bluecontroller.googlecode.com/archive/b293ac6f0053248258cd60541d866cee24baa9f3.zip Michael
:
Bearbeitet durch User
Stefan Us schrieb: > In funktechnisch verseuchter Umgebung (z.B. bei mir zuhause) kommen > Übertragungsfehler so häufig vor, dass selbst die eigebauten > Korrekturmechanismen mehrmals pro Stunde versagen. Ich beobachte diese > Effekte bei allen drahtlosen Verbindungen in meiner Wohnung. Dann taugt Dein BT-Modul nichts. Welches verwendest Du? Ich habe hier WLAN und BT und noch einige RFM70 am Laufen und noch nie ein Datenproblem gehabt. Ich habe eine Eisenbahnplatte, die ich mittels BT konfiguriere und deren Module regelmäßig eine neuere Firmware bekommen. Es gab da noch nie ein Problem, läuft seit 1 Jahr mit einem BTM-182 störungsfrei.
Knut Ballhause schrieb: > Dann taugt Dein BT-Modul nichts. Welches verwendest Du? Ich habe hier > WLAN und BT und noch einige RFM70 am Laufen und noch nie ein > Datenproblem gehabt. Kann ich nicht besttigen. Mit einigen billigen Videosendern/Videobabyphonen im 2,4GHz-Band bekommt man jede Funkverbindung tot.
Knut Ballhause schrieb: > Stefan Us schrieb: >> In funktechnisch verseuchter Umgebung (z.B. bei mir zuhause) kommen >> Übertragungsfehler so häufig vor, dass selbst die eigebauten >> Korrekturmechanismen mehrmals pro Stunde versagen. Ich beobachte diese >> Effekte bei allen drahtlosen Verbindungen in meiner Wohnung. > > Dann taugt Dein BT-Modul nichts. Welches verwendest Du? Ich habe hier > WLAN und BT und noch einige RFM70 am Laufen und noch nie ein > Datenproblem gehabt. Ich habe eine Eisenbahnplatte, die ich mittels BT > konfiguriere und deren Module regelmäßig eine neuere Firmware bekommen. > Es gab da noch nie ein Problem, läuft seit 1 Jahr mit einem BTM-182 > störungsfrei. Eine Stichprobe der Größe 1 hat für allgemeine Aussagen nicht die erforderliche statistische Signifikanz. Wie gesagt, bei Over-The-Air Updates habe ich ein deutlich besseres Gefühl, wenn der komplette Code lokal im RAM (auch einem externen SPI-SRAM) ist, bevor der Flashprozess startet. So kann ich sicher sein, dass das System nachher unter allen Umständen wieder hochkommt, wenn ich den Flashprozess starte. Der einzige Schwachpunkt bleibt die Stromversorgung während des Flashens. Die 90 Cent für einen 23k256 (32k) machen den Kohl nun auch nicht fett, sofern es hier nicht um 100k Stückzahlen geht. fchk
Was mich sowieso etwas verwundert in diesem Zusammenhang, wieso gibt es keinen Programmer der ohne Kabel, also mit BT oder WLan?
F. Fo schrieb: > Was mich sowieso etwas verwundert in diesem Zusammenhang, wieso gibt es > keinen Programmer der ohne Kabel, also mit BT oder WLan? 1. eine Fehlerquelle mehr 2. PCs haben normalerweise kein BT 3. WLAN erfordert in großen Firmen ggf höheren Administrationsaufwand und ist damit eher unbeliebt 4. ein Sicherheitsrisiko mehr (Werksspionage etc, Firmen können da sehr paranoid sein) Für mobile Anwendungen gibts auch schon Lösungen: http://www.halec.de/en/By-Brand-Manufacturer/halec/roloFlash-AVR-Base-Version.html fchk
Frank K. schrieb: > Eine Stichprobe der Größe 1 hat für allgemeine Aussagen nicht die > erforderliche statistische Signifikanz. OK, dann packe ich noch 3 dazu: Ein Datenlogger-Tool, welches ich über BT update. Ebenfalls ein BTM-182 am Start; XMEGA128A3U als Hauptcontroller. Update und Config finden im Wochenturnus statt. Dann ist da noch eine DCF-Wanduhr mit BTM-112, die einen PC synchronisiert, Temperatur- und Feuchtigkeitswerte sendet und ggf. Updates empfängt, Hauptcontroller ist ein Mega324P. Dann haben wir noch 2 aufsteckbare Debug-Tools, welche an einem Netzwerküberwachungssystem hängen und Daten an eine Debug-Software senden, Controller ein Mega168PA. Alle diese Geräte, die wir im Betrieb täglich einsetzen, haben noch nie falsche Daten gesendet. Bei Störungen oder Verlassen der Reichweite stoppt der Stream und läuft weiter, wenn die Störung behoben ist oder man wieder in Reichweite ist, wenn nicht vorher das Timeout zuschlägt. Natürlich muss man die Handshake-Leitungen der Module mit kontrollieren, damit man nicht etwas sendet, wenn der Empfänger nicht bereit ist und dies dann verloren geht. Aber empfangen habe ich bis heute kein einziges falsches Byte. Das sind Erfahrungswerte, seitdem die BTM-xxx Module auf dem Markt sind. Wenn auch bei früheren Firmware-Versionen die UART Schnittstelle etwas krepelig war, der BT-Stack arbeitet einwandfrei. Frank K. schrieb: > Wie gesagt, bei Over-The-Air Updates habe ich ein deutlich besseres > Gefühl, wenn der komplette Code lokal im RAM (auch einem externen > SPI-SRAM) ist, bevor der Flashprozess startet. Gefühle sollte man nicht überbewerten. Da ich immer hex-Dateien nativ übertrage, hat der Bootloader über die Prüfsumme und Längendefinition schon eine gewisse Kontrolle über die Daten, ebenso wenn z.B. das EOF ausbleibt. Ist aber bisher nie aufgetreten und ein frisch geflashter Controller hat noch nie etwas gemacht, was ich aufgrund des Codes nicht erwartet hätte. Über die Vielzahl der inzwischen überspielten Updates kann ich schon sagen, dass die Übertragung äußerst zuverlässig arbeitet. Und wenn mal etwas schiefgeht, bleibt trotzdem immer der Bootloader erhalten und man kann ein neues Update versuchen. Wichtig ist nur, dass nach dem Reset des Controllers immer zuerst in den Bootloader gesprungen wird. Dann hat auch fehlerhafter Programmcode keine Chance. Die Bootsektion selbst kannn vor Überschreiben geschützt werden. Schreiber schrieb: > Mit einigen billigen > Videosendern/Videobabyphonen im 2,4GHz-Band bekommt man jede > Funkverbindung tot. Was niemand bezweifelt. Nur sind diese Teile auch nicht normkonform, was die EMV angeht. Darauf kann man sich bei solchem Ramsch immerhin verlassen.
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.