AUDIOINO, eine minimalistischer Arduino mit Programmierung über Line Out

[ChrisMicro]

Vielen Dank für die Information, das Projekt scheint ja die Leute doch sehr zu interessieren.
Mich würde es freuen, wenn die Leute es ausprobieren und die Erfahrungen damit posten.

[25mmHg]

Hallo Chris, ich finde die Idee mit dem Audiobootloader genial, zum peiswerten Flashen von AVRs unübertroffen. Leider ist es mir bisher nicht gelungen, den Code des Bootloaders mit AVR-Studio4 für einen ATmega8L zu compilieren (ATmega168 geht). Es gibt es 3Fehlermeldungen. Beim ursprünglich im September veröffentlichten Code taucht der ATmega8 noch als compilierbare Option auf, bei dem über den Elektor-Link publizierte Code ist nur noch der ATmega 168 vorgesehen. Leider ist beim überaus preisweren Conrad-PingPongSpiel mit 120LEDs onboard ein ATmega8L drauf. Diese preiswerte Hardware verbunden mit dem Audiobootloader wäre eine grandiose Sache. Zumal auch kein Quartz bestückt ist. Vielleicht schauen Sie oder jemand anderes mit einer Idee hier wieder vorbei und können mir einen Hinweis geben, wie ich den Code für die PinPong-Platine compilieren kann.
Falls die PingPongPlatine noch nicht bekannt ist hier mal ein Link zu einer (nicht von mir) geposteten Anwendung. Bei Conrad gibt es diese Platinen manchmal für weniger al 7€: http://www.elo-web.de/elo/mikrocontroller-und-programmierung/ping-pong/ping-pong-einparkhilfe-fuer-pkw-mit-distanz-sensor
Ansonsten wäre es natürlich super, wenn der Bootloader auf alle möglichen AVRs anpassbar wäre. Insofern könnte man so noch einige Leute mit dieser tollen Idee beglücken.
Gruß Johannes

[uwefed]

Vieleicht hat der ATmega8 zuwenig RAM/ROM um ihn sinvoll in diesem Projekt einzusetzen. Darum ist er nicht mehr in der Liste.
Grüße Uwe

[25mmHg]

Hallo Uwe, danke für die schnelle Antwort. Ich glaube das aber doch nicht, da ja z.B. beim Arduino NG mit ATmega8 auch ein 1k Bootloader zum Einsatz kam. http://arduino.cc/hu/Hacking/Bootloader : "The ATmega8 bootloader only takes up 1 KB of flash. It does not timeout when it receives invalid data, you need to make sure that no data is sent to the board during the 6-8 seconds when the bootloader is running. " Aber vielleicht ist der von Chris gebaute Bootloader wieder ein paar Byte größer geworden und überschreitet die 1k-Grenze des ATmega8?
Gruß Johannes
P.S. ich habe nämlich einen "Klassensatz" PingPongs und fände die AudioFlashMethode gut geeignet, um Beginnern ohne teuertolle Hardware einen Einstieg in C zu ermöglichen. So könnten sie nach Flashen des Bootloaders selber eigenen Code brennen. Gerade für kleine billige AVRs ist das attraktiv. Da gerade in der Mai-Elektor der Artikel von Chris erschienen ist, tut sich vielleicht noch was....hier der Link zum Artikel: http://www.elektor.de/jahrgang/2012/mai/audio-bootloader.2139052.lynkx
Gruß Johannes

[udoklein]

Am coolsten finde ich, dass es damit ja möglich sein sollte aus ein HEX eine WAV Datei zu generieren und dann von einem MP3 Player aus zu flashen. Hast Du schon mal ausprobiert ob das tatsächlich funktioniert?

[25mmHg]

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

[udoklein]

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.

[ChrisMicro]

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

[25mmHg]

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)

[25mmHg]

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 :-)

Habe die Änderung auf diesen Quelltext angewandt: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=127 (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

[ChrisMicro]

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

[25mmHg]

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

[ChrisMicro]

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.

[25mmHg]

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 :-) 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)

[ChrisMicro]

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