AUDIOINO, eine minimalistischer Arduino mit Programmierung über Line Out

Hallo Uwe, nein das hab ich noch nicht probiert, ich möchte das wirklich erst ausprobieren, wenn auch andere Controller flashbar sind. Ich find das vieleicht noch raus. Ich hab den Artikel in der Elektor gelesen und dachte sofort daran, das mit preiswerten Controllern probieren zu wollen. Das ist dafür fast noch besser als der Weg über VUSB. Spannend ist es natürlich doppelt wenn beliebige Audioquellen (Kassette, mp3-Player, Smartphone, Radio) genommen werden können. Da der zu übertragende Code gerade bei Anfängern nicht sehr umfangreich ist, reichen auch langsamere Übertragungsraten. Hauptsache es läuft stabil, und kein Anfänger kann den Chip verfusen. Dass die Datenreduktion bei mp3-Playern zwangsläufig zu Übertragungsfehlern führen muss glaub ich nicht, weit auseinanderliegende Töne oder Tonfolgen sollten ja erhalten bleiben. Ganz heiß wird die Sache, wenn die Arduino IDE Audioflashen direkt unterstützten würde... Johannes

Aehm, wie kommst Du darauf, dass Audioflashen nicht geht? Avrdude kann doch eh fast alles nutzen. Zur Not muß er eben in eine Pipe statt eine serielle Schnittstelle schreiben. Die Gegenseite der Pipe wäre dann der besagte Audioflasher. Der einzige Schönheitsfehler wäre, dass der Flasher vor der IDE gestartet werden muesste. Könnte man aber durch ein Skript verstecken.

Hallo 25mmHg,

die Register im Atmeg8 sind leider teilweise anders benannt als beim Atmega168. Die Bits sind ebenfalls teilweise anders eingeteilt. Der Bootloader sollte auch auf dem Atmega8 laufen, wenn man die richtigen Register verwendet. Ich habe früher vielfach für meine Experimente den Atmega8 verwendet, aber der Prozessor ist eigentlich abgekündigt, deshalb verwende ich fast nur noch die Atmega88/168/328 Typen. Die Verwendung für das Pong-Spiel wäre natürlich ein Argument. Im Moment habe ich allerdings keine Zeit dafür, den Bootloader anzupassen. Vielleicht kannst Du mal im mikrocontroller-Forum nachfragen, ob Dir jemand bei der Anpassung der Register hilft.

Beste Grüße, chris

Hallo Chris, erstmal Danke für die Antwort. Ich versuche mal, aus den Datenblättern der beiden Controller schlau zu werden. Ich bekomme nur (rote)Fehlermeldungen für ZEILE 319:
TCCR2B= _BV(CS21);
FEHLER:
…/chAudioBoot.c:319: error: ‘TCCR2B’ undeclared (first use in this function)
Also such ich nach TCCR2B (TimerCounterCompareRegister?) Vielleicht ist es garnicht so schwer. Ich finde Deine Lösung mit der Manchestercodierung robuster als die SoundRX-Methode. Und da sie trotz geringem Aufwands keinen Abgleich braucht, ist sie auch wieder attraktiv für alle Anfänger…
Mal sehen ob es mir gelingt, die PingPong-Platine zum “Hören” zu bringen
Viele Grüße Johannes
(Wenn ich was raus hab, schreib ichs hier rein)

Zwischenerfolgsmeldung beim Anpassen Audiobootloader: (Hab die Datenblätter verglichen)
Zeile 319(war für ATmega168):
TCCR2B= _BV(CS21);
Zeile 319(wird für ATmega8):
TCCR2= _BV(CS21);
Ergebnis: Keine rote Fehlermeldung mehr im AVR-Studio4, Build-Prozess abgeschlossen(4 gelbe Warnungen)
Vielleicht wars das schon :slight_smile:

Habe die Änderung auf diesen Quelltext angewandt: forum.hobby-roboter.de • View topic - Audio Bootloader (AudioBoot_V1_1.zip entpacken) Nur hier (und nicht im ElektorQuelltext!!!) stehen oben in der chAudioBoot.c die Verfahrenshinweise zum ATmega8. Folgende Zeile dort verstehe ich noch nicht: 5. BootresetvectorFuseBit enable Bootloader bzw. ich weiß nicht, wo ich diese Einstellung im AVR-Studio vornehmen kann. Und ich weiß ebenso noch nicht, ob die Fuses automatisch richtig gesetzt werden, oder ob ich das selbst machen muss.
Johannes

Und ich weiß ebenso noch nicht, ob die Fuses automatisch richtig gesetzt werden, oder ob ich das selbst machen muss.

Hallo Johannes,

die Fuses muss man in AVR-Studio selber setzen. Siehe die Bilder hier:

http://www.mikrocontroller.net/articles/AVR_Fuses

Danke Chris, hfuse=D8 und lfuse=E4 für den ATmega8 (int.Oszillator=8MHz, slow rising Power, no Brown out, SPI enable, BOOTSZ1=ON, BOOTSZ2=ON, BOOTRST=ON (Bootsize=1kword=2048byte, Resetvector zeigt auf Bootloaderadresse) Der Linker im AVR-Studio (zu finden unter Project/Config.Options/CustomOptions/LinkerOptions) bekommt folgende Zeile übergeben: -Wl,--section-start=.text=0x1800 ging ganz leicht mit http://burn-o-mat.net/avr8_burn_o_mat_avrdude_gui_online.html

Ob die Programmierung statt mit wav auch mit mp3 möglich ist? Im Bild der Spektralverlauf der letzten 4NF-Blöcke vom ElefantentrompetenCode. Das geht über die gesamte Audiobandbreite. Für mp3 sicher eine harte Nuss. Man erkennt eine Symmetrie um 11kHz (Man sieht dort übrigens auch ganz gut den letzten Piepton) Eventuell ist alles eine Frage der Geschwindigkeit. Auf jeden Fall Potential zum Forschen. Gruß Johannes

Ob die Programmierung statt mit wav auch mit mp3 möglich ist?

Vorstellen kann ich es mir nicht. Beim Audiobootloader kommt es auf jede Flanke an. MP3 unterteilt einen Wellenzug in einzelne Pakte und macht eine Spektralanalyse und danach durch die Bewertung mit einem "psychoaktustischen Hörmodell" eine verlustbehaftete Kompression. Für das Ohr hört sich das File gleich an, die Wellenzeuge sehen aber garantiert anders aus. Das einfache Komprimieren mittels "zip" o.ä. dürfte da schon eher zum Erfolg führen, da im wav-File ziemlich viele gleiche Werte vorkommen und eine Redundanzkomprimierung dann einiges bringt.

Hier habe ich noch etwas Lustiges endeckt: http://tadpol.org/projects/AvrianJump.html Da hat einer eine minimalistische graphische Programmiersprache entwickelt, die direkt den Ton für den Audiobootloader erzeugt.

Hallo Chris, danke für den Link, ich werde mir das mal ansehen.
Habe vorhin noch die Frage mit dem BOOTRST beantworten können und es oben korrigiert (Aus D9 bei hfuse wird D8).
Das WAV-file hab ich mir mal in einem AudioEditor angeschaut. Deine Software liefert Rechteckimpulse mit Vollaussteuerung (+1 und -1 kleinste Periode 4Samples=11025Hz), die von der Soundkarte dann verschliffen werden. Dabei kam die Frage auf, wie langsam kann man eigentlich übertragen? (Jaaaa der Anfänger schreibt eher kurze Programme und hat Zeit :slight_smile: wenn ich nun mit einem Audioeditor langsamer abspiele? Was passiert dann)
Im Elektor-Artikel steht, dass 8MHz und 16MHz funktionieren und die Taktfrequenz nicht sehr genau eingehalten werden muss.
Noch eine Frage:

Im HEX-file steht auf der letzten Zeile eine 1FF das macht dezimal 511. Ist das die Größe des Bootloaders in Worten? Dann könnte man beim ATmega8 auch eine Bootloadergröße von 512words=1Kbyte wählen? Im Elektor-Artikel stehen auch die 512Worte…Mit kbyte und kwords kann man ganz schön durcheinanderkommen. Noch dazu, wenn Im Windows-Dateisystem bei der Hex-Datei 2kbyte Größe angezeigt werden, was aber real weniger ist und eine Hex-Datei hat außerdem einen kleinen Verwaltungsdatenüberhang.

Somit gilt für den ATmega8 mit 512words großem Audiobootloader:
Die Fuses werden alle von Hand richtig gesetzt mit hfuse=DA und lfuse=E4
dadurch kommt der Bootloader automatisch auf die Startadresse in words 0xE00 und der Resetvector zeigt auf den Bootloader.
Dem Linker von AVR-Studio4 muß ich allerdings noch folgende Zeile übergeben (u.a. Startadresse für Bootloader in bytes):
-Wl,–section-start=.text=0x1C00
Und im Quellcode schreibe ich in Zeile 319: TCCR2= _BV(CS21);
Aber was weiter oben geschrieben steht ist nicht falsch! Da hat der Bootloader eben nur etwas mehr Platz…
Gruß Johannes (einen Sonnenbrand hab ich heute nicht bekommen aber ein bischen was verstanden)

Halo Johannes,

jaja, das mit den Words und Bytes ist etwas verwirrend. Ich bin gespannt, ob es jetzt bei Dir klappt. Ist der TX-Ausgang am Pongspiel noch frei? Soweit ich mich erinnern kann, habe ich diese Ausgang als Eingang für den Autiobootloader konfiguriert. Falls am Pong Spiel nur ein anderer Anschluss frei ist, müsstest Du das im Programm noch anpassen.

Bester Gruß, chris

Hallo Chris, ich habe mir heute ein PingPongBoard genommen und mit einem AVRISPmkII ist es mir gelungen, den Bootloader zu flashen. Es gab eine Hürde: Die vielen LEDs! Am Anfang unerklärliche Übertragungsfehler und Abbrüche. Nach verzweifeltem Hin- und Herschalten des ISP-Clocks leuchteten auf einmal Streifenweise LEDs auf!!! So bin ich drauf gekommen, das Board nicht alleine mit dem AVRISPmkII zu betreiben, sondern mit einem Labornetzteil 5V. Ohne die LEDs wäre es sicher auch ohne zusätzliche Spannungsquelle gegangen, aber in diesem Falle ist unbedingt eine autonome Versorgung des Boards nötig.

Das PingPongBoard hat nach http://www.produktinfo.conrad.com/datenblaetter/900000-924999/902766-an-01-ml-CONRAD_RETRO_SPIEL_PING_PONG_de_en_fr_nl.pdf die folgenden PortPins frei nach draußen gelegt:
PC4 und PC5 (ATmega8) als C4, C5 (PingPong) und PD0 bis PD3 (Atmega8) als D0, D1, D2, D3 (PingPong)
Außerdem sind ADC6 und ADC7 für die Verwertung analoger Signale als P2 und P3 rausgeführt.
All diese PortPins sind völlig unbeschaltet und damit meiner Meinung nach wahlfrei verwendbar. K1 steht noch als GND und P1 als VCC zur Verfügung.

Ich habe mir überlegt, PC4 und PC5 für LEDs zu nutzen (Status und Test) und D0(RXD) als AUDIOIN zum Flashen. Spricht da irgendwas dagegen? Den Code kann ich sicher umschreiben. Das such ich mir zusammen. Aber eine Sache hat mich noch stutzig gemacht. Muß ich dem Bootloader noch irgendwo mitteilen, wie groß der FlashRom des Atmega8 ist?
Ganz unten in Deinem Code stehen folgende Zeilen (Vom pageweisen Speicheraufbau und vom Verhältnis FlashRom 4kwords (ATmega8) zu 8kwords (ATmega168) weiß ich):

case PROGCOMMAND:
{
// Atmega168 Pagesize=64 Worte=128 Byte
uint16_t k;
k=(((uint16_t)FrameData[PAGEINDEXHIGH])<<8 )+FrameData[PAGEINDEXLOW];
boot_program_page (SPM_PAGESIZE*k, FrameData+DATAPAGESTART); // erase and programm page
}
break;

Viele Grüße Johannes

25mmHg: Ohne die LEDs wäre es sicher auch ohne zusätzliche Spannungsquelle gegangen, aber in diesem Falle ist unbedingt eine autonome Versorgung des Boards nötig.

Die autonome Versorgung des Boards bzw. Prozessors ist bei Verwendung des AVRISP MKII grundsätzlich notwendig. Der AVRISP misst lediglich die von Dir angelegte Spannung, um sich z.B. auf einen 5V oder 3,3V Prozessortyp einstellen zu können. Wie sollte er es sonst auch automatisch erfahren können.

Gruß, mmi

Danke mmi, ich habe einen AVRISP-Clon (cc2AVRprog), und der hatte zumindest die Möglichkeit das VCC-Pin zu versorgen. (sonst hätten nicht 40 LEDs aufgeflackert) aber gereicht hat das eben trotzdem nicht, wahrscheinlich reichte der Speisestrom nicht und es gab Betriebsspannungseinbrüche. Mit Netzteil klappt das Flashen sicher. Ich hab mir eine Adapterplatine auf einen D-SUB15Stecker gebaut. Mit den verfügbaren Leitungen drauf. So kann ich irgendwelche BE gleich auf eine SUB-D15Buchse löten und rumexperimentieren. Einen Resetschalter braucht man beim PingPongBoard nicht, da GND und RESET sich auf dem ISP-Steckverbinder (den man hier selber bestücken muss) gegenüber befinden, so dass ein einfacher Jumper ausreicht. Hier noch ein Link für alle die einen echten AVRISPmkII haben und ihr Target trotzdem speisen wollen: http://www.youtube.com/watch?v=ICQXqVy3Hpc Viele Grüße Johannes

Hallo Chris, jetzt gibt es in Bezug auf Audiobootloader und PingPongBoard folgenden Stand. Der Bootloader lässt sich auf den ATmega8 überspielen, die geänderten Pinbelegungen sind mit eingeflossen. Nach einem RESET blinkt die StatusLED langsam, und auf dem AudioINPUT werden Daten von der Soundkarte empfangen. Allerdings scheint trotzdem etwas nicht zu klappen:

1.) Das Blinken geht ewig, und hört nie nach 6s auf (vielleicht weil kein Code im Flash vorhanden ist, der angesprungen werden kann?) update: Ich habe gerade mein Testprogramm mit dem AVRISPmkII geflasht und danach [u]ohne[/u] Chip-erase den Audiobootloader drauf. Jetzt wird nach 6s pünktlich zum Testprogramm gesprungen 2.) Ich schaffe es, Programmierfehler auszulösen, die durch schnelles Blinken der StatusLED angezeigt werden, wenn ich den Audiopegel voll aufdrehe 3.) Wenn ich den Pegel des Audioausgangs vom Laptop etwas zurückdrehe finde ich einen Bereich, in dem die StatusLED zu einem Dauerleuchten übergeht, aber zur Ausführung meines Testprogramms gelange ich nicht.

Ich habe auch mal einen 10nF Kondensator in der Audioleitung versucht, ohne Verbesserung. Jetzt will ich erstmal das RESET-Pin mit einem externen Pull-UP versehen Gruß Johannes

Hallo Johannes,

100nF für den Wert des Koppelkondensators sind besser.

Ich vermute, dass das Problem wo anders liegt: Der Atmega8 hat eine Pagesize von 64 Byte und der Atmega168 hat eine Pagesize von 128 Byte. Beim Audiobootloader werden immer 128 Byte an Daten übertragen und dann dem Mikrocontroller etwas Zeit gegeben, eine Page zu "flashen". Eine Umgehungslösung für den Atmega8 könnte sein, auch 128 Bytes zu empfangen und dann einfach 2 aufeinander folgende 64 Byte Pages zu flashen. Sonst müsste man auch das Java Programm ändern und dort die Datengröße auf 64 Byte umstellen und den Bootloader für den Atemga8 ändern, was etwas aufwändig wäre.

Bester Gruß, chris

Hallo Chris, einmal könnt ich es ja mal machen...Ich fange also an, das Audio-file zu zerschneiden...Hoffentlich habe ich ein kurzes Testprogramm. (Schneiden kann ich ja - Aber den Bootloader umstricken sicher nicht) Aber dann wird es jetzt richtig spannend. Viele Grüße Johannes

Hallo Chris, einmal könnt ich es ja mal machen…Ich fange also an, das Audio-file zu zerschneiden…Hoffentlich habe ich ein kurzes Testprogramm.

Schneiden? Ich glaube, das dürfte nichts bringen. Ausser Dein Programm ist 64 Byte lang.

Du könntest für die Pages verantwortliche Stelle im Programm modifizieren. Das hier schreibe ich jetzt einfach mal hin, ohne es getestet zu haben:

relativ weit oben im Programm

// fuer Atmega8
#define PAGESIZE 64 // Pagesize for Atmega8
#define FRAMESIZE       (PAGESIZE*2+DATAPAGESTART)// framsize still 128 byte

Weiter unten:

case PROGCOMMAND:
        {
            // Atmega168 Pagesize=64 Worte=128 Byte
            // Atmega8 Pagesize=32 Worte=64 Byte

         uint16_t k;
         k=(((uint16_t)FrameData[PAGEINDEXHIGH])<<8 )+FrameData[PAGEINDEXLOW];
         boot_program_page (SPM_PAGESIZE*k*2, FrameData+DATAPAGESTART);   // erste 64 byte des Datenframes
         boot_program_page (SPM_PAGESIZE*k*2+1, FrameData+SPM_PAGESIZE+DATAPAGESTART);   // zweite 64 Byte des Datenframes

         }
        break;

Danke Chris für diesen Vorschlag. Erfolg hatte ich noch nicht. (Irgendwas scheint noch nicht aufzugehen) Bin gerade dabei, mich durch den Audiobootloader und die boot.h zu wühlen. Eine mail an elo bzw. B. Kainka hab ich geschrieben, weil die ja das PingPongBoard entwickelt haben. Auch dort stieß der Audiobootloader auf großes Interesse. Wenns was neues gibt, melde ich mich wieder. (6Schreibmaschinenseiten++ zu verstehen dauert sicher eine Weile...und Zeit hab ich nur spät abends) Viele Grüße Johannes

Hallo Johannes,

jetzt habe ich doch ein wenig Zeit investiert und den Audiobootloader für das PingPong Game zum laufen gebracht: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=127&p=542#p542 Als Eingang habe PD1 verwendet. Die Widerstände muss man bei meinem Ping Pong Game auf 1.4V Mittelspannung bei 5V Versorgung anpassen. Eventuell wäre es hier am besten ein Poti zu verwenden.

Da die Sourcen im Moment noch etwas Spaghetti Code sind, habe ich erst mal nur die HEX-Files gepostet.

Bester Gruß, chris

Gerade eben habe ich noch einen Fehler gefunden: bei manchen Rechnern ist das Audiosignal invertiert. Da scheint es wohl keine eindeutige Norm zu geben oder die Hersteller halten sich nicht daran. Im Moment funktioniert der Audiobootloader nur mit einer Polarität.
Ich überlege noch, wie ich das Problem lösen könnte:

  1. Java Programm mit Polaritätsknopf versehen ( unschön, weil man dann den Knopf richtig betätigen muss )
  2. MC-Programm auf automatische Polaritätserkennung anpassen ( ziemlich aufwendig )

Im Anhang noch ein kleines Demoprogramm für’s Ping Pong.

dieMatrix.hex (12.6 KB)