AURORA - Das Atmolight der nächsten Generation...

hi,

habe nun ein paar controller aufgebaut, sieht eigentlich schon ganz gut aus;

leider hab ich immer noch das flacker problem bei nicht voller helligkeit, und mir ist
aufgefallen, das alle controller auf einmal nicht programmiert werden koennen, dann steigen
die bootldr scheinbar aus und der flash sagt (in diesem fall nur mit 2):

AURORA-Flasher v0.3
Searching for controllers...       done (6.12s)
Found the following controller(s): 1 2
Controller 1: unknown (00 00 00)
Controller 2: ATMega88
Couldn't determain the page size!

danach muss der bootloader neu geflasht werden, damit es wieder klappt. auch wenn der
"kaputter" controller alleine am usb wandler haengt, geht es dann nicht mehr.

schade, taugt wohl doch nicht fuer grosse stueckzahlen

-- randy

Zitat

Original von randy
leider hab ich immer noch das flacker problem bei nicht voller helligkeit

Wie steuerst Du an? Statisch oder ist es über das Plugin bei einem Live-Bild?

Zitat

und mir ist
aufgefallen, das alle controller auf einmal nicht programmiert werden koennen, dann steigen
die bootldr scheinbar aus und der flash sagt (in diesem fall nur mit 2):

Code

AURORA-Flasher v0.3
Searching for controllers...       done (6.12s)
Found the following controller(s): 1 2
Controller 1: unknown (00 00 00)
Controller 2: ATMega88
Couldn't determain the page size!

danach muss der bootloader neu geflasht werden, damit es wieder klappt. auch wenn der
"kaputter" controller alleine am usb wandler haengt, geht es dann nicht mehr.

Alles anzeigen

Meine max. Anzahl gleichzeitig programmierter Controller war bisher 6. Wenn das Flashen so wie oben aussteigt, wurde nichts programmiert. Der Boot-Loader muß intakt bleiben. Möglicherweise muß man die Controller resetieren (stromlos machen).

Hauptproblem in der Kommunikation ist das Einhalten definierter Wartezeiten im Millisekundenbereich. Da stellt sich Windows nicht toll an und bei Linux hängt die Genauigkeit von der Kernversion und -konfiguration ab.

Du könntest probehalber mal in MySleep() pauschal 2..10ms mehr Wartezeit draufschlagen.

Zitat

schade, taugt wohl doch nicht fuer grosse stueckzahlen

Wieviele Controller willst Du eigentlich aneinander hängen? Wenn die Anzahl der Controller bzw. die Länge vom Bus zu groß wird, wird die Kommunikation auch aussetzen. Du könntest mal mit einem Oszi schauen, wie die Signale auf RxD am USB-Serial-Wandler und auf TxD am letzten Controller aussehen.

Gruß
e9hack

ich habe beides probiert, bei statisch/rgb konfig sieht man das flackern am deutlichsten; speziell bei
100-200 in der konfig.

aktuell habe ich 3 led platinen (also "nur" verlaengerung) und 2 controller; mit einem controller hatte ich
das problem noch nicht; stromlos etc.. funktioniert alles nicht, der flasher findet dann den "kaputten"
controller erst wieder, sobald ich den bootldr nochmal ueber isp geflasht habe.

werde aber das mit den mysleeps mal testen.

notfalls kannst du dir es ja am vdr-camp live anschauen.

edit: usleep auf ms*10000, klappt leider auch nicht:

AURORA-Flasher v0.3
Searching for controllers...       done (23.22s)
Found the following controller(s): 1
Controller 1: unknown (00 00 00)
Couldn't determain the page size!

bootldr mit ponyprog drauf, geht wieder...

-- randy

Hi,

ich habe das Flashen auch gerade noch mal probiert:

vdr:/usr/src/aurora/flasher # gcc -o flasher flasher.c
vdr:/usr/src/aurora/flasher # ./flasher /dev/auroraController2
AURORA-Flasher v0.3
Searching for controllers...       done (1.83s)
Found the following controller(s): 20 21 22 23 24
Controller 20: ATMega88
Controller 21: ATMega88
Controller 22: ATMega88
Controller 23: ATMega88
Controller 24: ATMega88
Finished!
vdr:/usr/src/aurora/flasher # ./flasher /dev/auroraController2 aurora-m88
AURORA-Flasher v0.3
Searching for controllers...       done (1.83s)
Found the following controller(s): 20 21 22 23 24
Controller 20: ATMega88
Controller 21: ATMega88
Controller 22: ATMega88
Controller 23: ATMega88
Controller 24: ATMega88
Erasing flash...                   done (0.44s)
Programming flash...               done (3.97s)
Verifing flash...                  done (3.00s)
Erasing eeprom...                  done (0.95s)
Finished!
vdr:/usr/src/aurora/flasher #

In der letzten Zeit habe ich sonst immer ein Netbook mit Windows XP zum Programmiern bzw. Testen verwendet.

Was mir auffällt: Bei mir dauert das Suchen nach Controllern nur 1.83s bei dir dagegen 6.12s.

Welchen Kernel verwendest Du? Bei mir ist es 2.6.31.12. Bei 2.6.31 gab es Änderungen am Timing des FTDI-Treibers. Wenn Du einen älteren Kernel verwendest, liegt es möglicherweise daran.

Das mit dem 'Delay verlängern' hatte ich mir eigentlich so vorgestellt:

ms += 10;

Gruß
e9hack

Hi,

im Flasher gibt es mehrmals die folgende Code-Sequenz:

#ifdef WIN32
	WriteFile(hUart, buffer, size, &Count, NULL);
	FlushFileBuffers(hUart);
#else
        write(fdUart, buffer, size);
	tcdrain(fdUart);
#endif

An zwei Stellen fehlt aber das tcdrain().

Gruß
e9hack

danke, werd ich heute mal testen. erstmal am graphlcd basteln

-- randy

hallo,

hab nun mal die 2 zusaetzlichen tvdrain getestet, hat nicht geholfen;

danach jetzt die controller id auf 20 & 21 gesetzt, jetzt geht schon mehr:

AURORA-Flasher v0.3
Searching for controllers...       done (6.10s)
Found the following controller(s): 20 21
Controller 20: ATMega88
Controller 21: ATMega88
Erasing flash...
Couldn't erase the flash of the following controller(s): 20 21

jeweils einzeln gehen die controller zu flashen:

AURORA-Flasher v0.3
Searching for controllers...       done (6.12s)
Found the following controller(s): 21
Controller 21: ATMega88
Erasing flash...                   done (0.41s)
Programming flash...               done (3.77s)
Verifing flash...                  done (3.00s)
Erasing eeprom...                  done (0.89s)
Finished!

werde bei gelegenheit mal von kernel 2.6.30.1 upgraden.

-- randy

Zitat

Original von randy
danach jetzt die controller id auf 20 & 21 gesetzt, jetzt geht schon mehr:

Prinzipiell sollte es nichts mit den Id's zu tun haben.

Kannst Du vor der Funktion getMulticastResult() mal eine #define _DEBUG und danach #undef _DEBUG einfügen. getMulticastResult() spuckt dann ein paar Infos zu den empfangenen Daten aus.

Zitat

werde bei gelegenheit mal von kernel 2.6.30.1 upgraden.

Hast Du eine Windows-Büchse, mit der Du mal das Flashen testen kannst?

Gruß
e9hack

mhm, koennte das mal auf dem firmenrechner testen, hab daheim nur xp in virtualbox

der kernel aendert uebrigens nichts.

gruss,
-- randy

Hi,

da ich nicht nachvollziehen kann, warum bei Dir das Flashen nicht funktioniert, hätte ich gern zwei Module als zeitweilige Leihgabe.

Gruß
e9hack

hi,

werde morgen nochmal 4 controller zusammenbauen und testen; wenn diese auch den
fehler zeigen, muss ich dich damit nerven evtl. ist es ja "nur" der eine controller,
komischerweise musste ich die 2. platine bisher noch nicht "reparieren".

-- randy

kurze frage

wie ist hier der Entwicklungsstand?

also meine 2,8mtr led leisten laufen mittlerweile wie gewuenscht, habe eine testtool
erstellt, mit dem man ohne das auroraplugin die farben steuern kann, da mein alter
linvdr noch nicht so modern ist (da laeuft noch vdr 1.3.x)

aber ansonsten tuts. habe auch leerplatinen uebrig.

werde mal bei gelegenheit bilder/videos ins blog stellen.

-- randy

Zitat

werde mal bei gelegenheit bilder/videos ins blog stellen.

bitte

Zitat

Original von randy
also meine 2,8mtr led leisten laufen mittlerweile wie gewuenscht

Wieviele Controller bzw. RGB-Gruppen sind das? Hat das Flashen der Controller funktioniert? Mit zwei Controllern hattest Du ja irgendwie Probleme.

Gruß
e9hack

ich habs mittlerweile so am laufen (aber nur statisch, nicht dynamisch via plugin, weil im wohnzimmer
steht "nur" linvdr 0.7 mit vdr 1.3.34 :)):

5cm led - 10cm led - 10cm ctrl - 10 cm led - 5+5cm led - 10cm led - 10cm ctrl - 10cm led - 5cm led

d.h. 4 gruppen (jeweils links/rechts vom controller) fuer oben und unten;

10 cm led - 10cm led - 10cm ctrl - 10 cm led - 10 cm led

2 gruppen fuer links/rechts

ergibt 6 controller mit 12 channels

das problem mit den controllern war wohl unzureichende stromversorgung (scheinbar durch
stromspitzen einbrueche?), wobei die signaturen immer noch nicht sauber ausgelesen werden koennen,
aber ansteuern lassen sich die controller trotzdem.

bei mir funktioniert aber ein reboot befehl nicht, die controller setzen die farben nicht zurueck?

gruss,
-- randy

Zitat

Original von randy
das problem mit den controllern war wohl unzureichende stromversorgung (scheinbar durch stromspitzen einbrueche?)

So wie ich das sehe hast Du ja Elkos auf jedem Modul. Da sollte eigentlich nichts einbrechen. Bei mir gibt es auf jedem Modul nur 1x33u (war der größte Tantal-Elko in Bauform D, denn ich hatte) + 4x100n an 12V und 1x100n an 5V.

Zitat

wobei die signaturen immer noch nicht sauber ausgelesen werden koennen, aber ansteuern lassen sich die controller trotzdem.

Wenn sich die Signatur für einzelne Kontroller prinzipiell nicht auslesen läßt, ist das möglicherweise ein Problem vom Bootloader. Ich wollte eigentlich den Befehl boot_signature_byte_get() zum Lesen der Signatur verwenden. Der wird aber scheinbar beim ATMega88 erst ab einer bestimmten Revision unterstützt. Ich habe den dann wieder deaktiviert bzw. teste auf SIGRD. Einige Compiler-Versionen scheinen aber SIGRD für den ATMega88 zu setzen.

Zitat

bei mir funktioniert aber ein reboot befehl nicht, die controller setzen die farben nicht zurueck?

Wenn es irgendwelche Kommunikationsprobleme (außer bei Reboot) gibt, könnte man die Fehlerbits der Antwort auswerten. Für Multicast-Befehle muß man dann den Status bei jedem Controller einzeln abfragen.

Bei Kommunikationsproblemen solltest Du Dir mal die RxD/TxD-Leitung am Strang-Anfang bzw. Ende mit einem Oszi anschauen. Wenn es zum Übersprechen zwischen den beiden Leitungen kommt, geht nichts mehr. Bei meinem Fädelaufbau hatte ich da am Anfang Probleme. Ich habe dann an den Widerständen in den TxD-Leitungen rumoptimiert.

Gruß
e9hack