Druckbare Version
Hallo,
ich möchte meinen Bot gerne per Funk Programmieren können.
Mit Bootloader + Funk RS232 würde es irgendwie gehen, aber das
wäre zimlich Zeitintensiv und ich bin zimlich unter Zeitdruck.
Ich suche eine möglichst einfache Lösung.
Es gibt ja diese Funk USB Adapter.
Habt ihr damit schon mal was gemacht?
Hallo Turbine,
ich habe zwar keine Lösung für dein "dringendes" Problem. Aber die Idee mit der Funk-Programmierung finde ich faszinierend. Ich bin gerade hier im Forum auf der Suche gewesen nach einer möglichkeit die ISP-Programmierung galvanisch getrennt durchzuführen und wollte das über Optokoppler lösen. Eine Funk-Verbindung löst dieses Problem auch und ist quasi die Luxus-Version.
Falls du also so eine Lösung umsetzten möchtest, kann ich dir gerne zur Seite stehen. Mit Funk habe ich zwar noch nie etwas gemacht, dafür habe ich schon einen AVR programmiert, der über die ISP-Schnittstelle einen anderen AVR flashen kann.
Viele Grüße
Andreas
Zeitdruck? Du kannst nicht schnell genug flashen? Dann wäre die erste Hilfe eine saubere Programmierarbeit die viele (vergebliche) Flashdurchgänge spart, weil man eben saubereren Code in den Compiler schickt. Aber ich glaub nicht, dass das Dein Problem ist, denn bei mir jedenfalls ist die Programmierarbeit erheblich zeitintensiver als das Flashen.Zitat:
Zitat von Turbine
Flashen per Funk über Bootloader sehe ich als gut möglich an. Schau mal auf den asuro , der macht das auch drahtlos - per Infrarot. Und das ist ein sehr bewährtes Verfahren, allerdings wirklich etwas langsam wegen der geringen Datenrate, die wegen des gewählten Kommunikationsverfahrens eingehalten werden muss. Über Funk sollte das aber deutlich schneller gehen. Beim Flashen über Funk dürften aber Durchsatzraten wie über Draht per ISP vermutlich nicht erreichbar sein.
Zu guter Letzt: ich weiß nicht, wie die rechtlichen Vorschriften zu einer Datenfunkstrecke aussehen - aber ich fürchte Schlimmes.
Wie wärs wenn du einfach einen gängigen UART-Bootloader auf den Controller schreibst und dann einfach ein Funkmodul dran hängst dass sich wie ein Uart verhält. Sowas sollte man auf 1-2 Tage locker schaffen.
mfg
Mein Robo hier wiegt 200kg.
Den kann man nicht mal eben auf dem Schreibtisch neben den Computer stellen und anstopseln,
geschweige denn, mit ins Haus nehmen.
Glaubs mir, da wird jedes einzelne mal flashen zur Qual.
Und dein Code kann noch so sauber sein, theoretisch gehts, aber praktisch siehts ganz anders aus...
Ich denke ich habe dir bereits die "einfachste und schnellste" Lösung gesagt, aber du wärst nicht der erste der meine Ratschläge ingnoriert um dann 3 Seiten später festzustellen, dass es doch so funktioniert.
mfg
Hallo,
ich habe mir ein paar mehr Gedanken zur ursprünglichen Idee gemacht. Funk scheidet eigentlich tatsächlich wegen der Datenübertragungsrate aus. Gerade wenn größere Controller geflasht werden sollen können da ja schnell mal Minuten aus dem Flash-Vorgang werden. Das würde mich auch nerven.
Aber eine einfache Lösung wäre doch Bluetooth. An den PC einfach einen handelsüblichen BT-Stick und auf der Programmer-Seite ein Bluetooth-Modul, dass sich über den Stick im PC einen virtuellen Com-Port erzeugt. Ich habe jetzt noch nicht die maximalen Datenübertragungsraten der verfügbaren Module recherchiert, aber da sollte doch deutlich mehr gehen wie über die üblichen Funkmodule, die wir Bastler hier zur Auswahl haben.
Auf der Atmel-Webseite gibt es auch den Source, wie er auf dem STK500 ist um die AVRs von dort zu flashen. Da das STK500 auch über Com angeschlossen wird ist die Lösung somit relativ einfach. Man könnte sich also mit wenig Aufwand einfach seinen eigenen Bluetooth-STK500-Programmer erstellen.
Warum gibt es sowas eigentlich nicht schon fertig zu kaufen?
Viele Grüße
Andreas
Hallo!
Ich denke, dass die heutige "echte" Entwickler kaum basteln, was früher üblich war. ;)Zitat:
Zitat von Bumbum
Hallo,
ich habe mich heute morgen mal in die Grundlagen des Bluetooth eingelesen. Theoretisch sind da ja mit aktueller Technik über 2MBit/Sek. drin. Das ist ja schon fast mehr, wie ein normaler AVR handeln kann, wenn er sich gleichzeitig ums flashen und um den Bluetooth-Empfang kümmern muss.
Eine Lösung des flashens via Bluetooth zwischen 115kBaud und 500kBaud sehe ich also als durchaus möglich und ist eigentlich ein recht schnelles Projekt, da ja der Source zum flashen bereits von Atmel zur Verfügung gestellt wird. Man muss ihn lediglich um die Bluetooth-Routinen erweitern. Das sollte sich auch nicht so kompliziert gestalten. Die handelsüblichen Module werden über die UART angesprochen und haben einen simplen AT-Befehlssatz.
Viele Grüße
Andreas
Es gibt Funk-USB-Hubs von verschiedenen Herstellern.
An den kannst Du deinen normalen Programmer (und evtl. Seriell-Wandler zum debuggen) anschließen.
Ich benutze einen älteren von Belkin der nur eine begrenzte Reichweite hat (ein paar Meter).
@Wsk8. Ich habe dich nicht ignoriert, sondern du hast deinen Beitrag schon gepostet,
als meiner noch nicht fertig war ;)
Werd jetzt nochmal wegen den Funk USB schauen, ansonsten muss ich halt darauf zurückgreifen.
Bei diesen Funk USB Dingern muss man aber aufpassen, das die auch für einen echtzeit Datenstrom übertragen können.
Ich weiß halt nicht welches Modell da geeignet ist...
Hallo,
ich halte mal an meiner Idee zum Bluetooth-Progammer fest. Da ich gerade eh einen galvanisch getrennten Programmer benötige (habe ich vor kurzem erst in einem anderen Thread hier beschrieben) fand ich die Lösung über Funk zu programmieren die perfekte Lösung für das Problem mit der "galvanik".
Ich habe mir in den letzten Tagen Gedanken dazu gemacht und einen Schaltplan und ein Lochraster-Layout erstellt. Ich möchte einen Tiny4313@4MHz verwenden. Als Bluetooth-Modul nehme ich ein Blue RSI+ von Stollmann. Damit habe ich schon gearbeitet, und es liegt auch noch eines hier rum. Dazu kommt noch ein kleines I2C LCD-Display, dass mir bei der Erstellung der Software hilft und Status-Informationen anzeigt, und später beim verheiraten der Bluetooth-Partner helfen soll. Geplant sind auch noch zwei Tasten für die "Verheiratung" und zwei LEDs als Status-Anzeige.
Hier mal meine Arbeit bis jetzt:
Anhang 26550
Anhang 26551
Bevor ich anfange zu löten wollte ich mir noch mal den Beispiel-Source von AVR anschauen, in dem die Firmware zum Flashen wie mit STK500 enthalten ist. Dummerweise finde ich den nicht mehr. Ich weiß, dass er hier vor ein paar Wochen in einem Thread verlinkt wurde, in dem jemand einen AVR mit einem AVR flashen wollte. Aber ich finde diesen Beitrag leider nicht mehr. Auch Google konnte mir nicht weiterhelfen. Das einzige, was ich gefunden habe war die Beschreibung des STK500-Prokolls in der Note086 von AVR:
http://www.atmel.com/Images/doc2591.pdf
Ich möchte aber nicht alles neu programmieren, wenn es das schon fertig gibt. Hat vielleicht jemand den Link zum Source auch parat? Ich würde mir den gerne vor dem löten anschauen, nicht dass ich was wichtiges in der Hardware vergessen habe.
Viele Grüße
Andreas
Mit dem Quellcode kann ich dir leider nicht helfen.
Zum Layout: Ich habe mich jetzt nicht so sehr damit befasst und einen Hardwarefehler zu finden,
Aber am Layout an sich könnte man noch schrauben.
Da sind verdamt viele Verbindungen auf dem Top Layer, die über irgendwelche Bauteile drüber gehen.
Also Stiftleisten und ICs. Das ließe sich bestimmt noch besser machen.
Die Pads solltest du auch noch etwas vergrößern.
Und Vielleicht Masefläche.
Hallo Turbine,
dass soll auf Lochraster aufgebaut werden. ;-)
Hallo!
@ Bumbum
Falls ich mich nicht irre Programmer mus duplex sein, weil die Daten in beiden Richtungen Programmer <---> AVR zu übertragen sind, was ich an deinem Schaltplan nicht sehe. :confused:
ISP ist doch Duplex! Oder was meinst du? Das Bluetooth-Modul ist auch Duplex. Und die Transistorschaltung dazwischen ist nur ein Pegelshifter, weil das Modul mit 3,3V versorgt wird.
Ich habe die Funkstrecke gemeint. Dann müsste es passen. :D
Die Funkstrecke ist bei Bluetooth ja gerade das geniale. Die registriert sich am PC als virtueller Com-Port. Man kann dann ganz bequem aus dem AVR-Studio programmieren und angeben, dass ein STK500 angeschlossen ist.
Hallo,
ich konnte es doch nicht erwarten, und das Wetter war zu schlecht, und die langeweile zu groß, und die Bauteile lagen eh rum. Also habe ich den Lötkolben geschwungen und das Ding mal aufgebaut:
Anhang 26553
Anhang 26554
Anhang 26555
Sorry für die Überbelichtung. Aber man erkennt alles. @Turbino: Ich hoffe jetzt hat alles Hand und "Bein" ;-). Das ganze war vorher durchdacht und hat ist beim Aufbau perfekt ausgegangen.
Jetzt fehlt nur noch die Software. Ich hoffe dadurch ergibt sich keine Hardware-Änderung mehr. Und für die Software bräuchte ich den Link zum Source von Atmel.
Ich werde mich zwar zunächst um das LCD, die LED's und die Taster kümmern. Aber da das eigentlich alles schon in Bibliotheken bereit steht beschränkt sich die Aufgabe auf das verlinken und konfigurieren von IO Pins. Das Bluetooth-Modul wird etwas mehr arbeit machen, aber ich glaube einen virtuellen COM-Port kann ich mit simplen AT-Kommandos öffnen.
Und dann ist es ja quasi schon fast soweit. Dann muss ich "nur" noch den Source von Atmel dazu fügen und die UART-Funktionen auf das Bluetooth-Modul umbiegen. Mal schauen, wann ich wieder Zeit habe am Projekt weiter zu arbeiten.
Viele Grüße
Andreas
Hallo,
ich habe wieder etwas Zeit in dieses Projekt investiert und bin ein gutes Stück weiter gekommen. Die LED's, Tasten und das LCD haben recht schnell funktioniert. Dummerweise war der Flash des Tiny4313 mit den I2C LCD-Routinen schon über 50% gefüllt. Aber ich habe erst mal weiter gemacht.
Als nächstes habe ich festgestellt, dass das Bluetooth-Modul doch mit 5V läuft und nicht mit 3,3V. Grml! Ich hatte das Modul schon mal im Einsatz und die Pegelwandler noch in Erinngerung und dachte deshalb es läuft mit 3,3V. Ein Blick in den alten Schaltplan hat ergeben, dass der Atmel mit 3,3V gelaufen ist und das Bluetooth-Modul mit 5V. Also Spannungsregler raus und ich konnte mit dem Bluetooth-Modul kommunizieren.
Ich habe zunächst einen Kopplungs-Prozess implementiert. Wenn man eine Taste beim einschalten gedrückt hält geht der BT_STK500 (so nenne ich das ganze Teil) in den Kopplungsmodus und sucht alle verfügbaren Bluetooth-Geräte. Diese können dann auf dem LCD durchgesehen werden. Mit einer Taste springt man zum nächsten Gerät, mit der zweiten Taste bestätigt man die Auswahl und die Kopplung wird vorgenommen und im EEPROM vermerkt.
Jetzt war der Flash des Tiny4313 aber bereits zu 97% gefüllt. Das wird so nichts habe ich mir gedacht. In der Schublade lag noch ein ATmega162 rum. Also habe ich schnell einen Adapter mit einem 20poligen und einem 40poligen Sockel und etwas Flachband erstellt. Die IO-Pings konnte ich 1:1 übernehmen. ISP und sogar USART-Schnittstelle lagen auf den gleichen IO-Ports. Es musste deshalb auch erstaunlich wenig Code angepasst werden. Lediglich die Register und Bits der EEPROM-Verwaltung und des USART mussten leicht umbenannt werden.
Ich habe noch festgestellt, dass ich den falschen Quarz gewählt habe. Das Bluetooth-Modul kann eine maximale Datenübertragung über Bluetooth von 230400 Baud. Mit meinem 8MHz-Quarz bedeutet das einen UBR-Wert von 34,7 was wohl zu weit von 35 und zu weit von 34 weg ist. Zumindest ist die Kommunikation mit dieser Baud-Rate nur mit vielen Fehlern möglich. Auf meiner Bestellliste steht also ein 14.745.600 Hz Quarz, damit ich endlich auf die volle Geschwindikgeit umstellen kann. Der ATmega verträgt laut Datenblatt maximal 16MHz, also bin ich mit den 14 MHz bestens bedient.
In der Software ging es trotzdem weiter: Wenn keine Taste beim starten gedrückt wird und eine Kopplung im EEPROM vermerkt ist geht der BT_STK500 in den READY-Modus und wartet auf eine eingehende Verbindung über die COM-Schnittstelle. Diese wird dann angenommen. Die Trennung von der Gegenstelle und die Trennung mittels Tastendruck am BT_STK500 sind bereits auch implementiert.
Das ist jetzt der Stand der Dinge. Ich habe auch mal kurz mein AVR-Studio auf STK500 umkonfiguriert und als COM-Port den gekoppelten Bluetooth-Port angegeben. Die Verbindung wird aufgebaut und es werden vom BT_STK500 auch Daten empfangen. Natürlich gehts hier nicht mehr weiter, weil ich noch nicht weiß, was ich antworten muss.
Jetzt fehlt mir nur noch den Quellcode für den AVR1200 auf dem STK500. Die Protokoll-Beschreibung des STK500 hätte ich zwar, aber die Umsetzung würde ich mir gerne mit Hilfe des Quellcodes etwas vereinfachen. Da hier leider noch kein Tipp gekommen ist werde ich dafür mal einen extra Thread aufmachen.
Zum Abschluss noch ein Foto vom aktuellen Aufbau:
Anhang 26647
Viele Grüße
Andreas
das hört sich mal richtig kompliziert an! viel glück! hat alles gepasst so wie du es dir vorgestellt hast?