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


    Code
    1. AURORA-Flasher v0.3
    2. Searching for controllers... done (6.12s)
    3. Found the following controller(s): 1 2
    4. Controller 1: unknown (00 00 00)
    5. Controller 2: ATMega88
    6. 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

  • Quote

    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?



    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.


    Quote


    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:


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


    bootldr mit ponyprog drauf, geht wieder...


    -- randy

  • Hi,


    ich habe das Flashen auch gerade noch mal probiert:


    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:

    Code
    1. ms += 10;


    Gruß
    e9hack

  • Hi,


    im Flasher gibt es mehrmals die folgende Code-Sequenz:

    Code
    1. #ifdef WIN32
    2. WriteFile(hUart, buffer, size, &Count, NULL);
    3. FlushFileBuffers(hUart);
    4. #else
    5. write(fdUart, buffer, size);
    6. tcdrain(fdUart);
    7. #endif


    An zwei Stellen fehlt aber das tcdrain().


    Gruß
    e9hack

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


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


    jeweils einzeln gehen die controller zu flashen:


    Code
    1. AURORA-Flasher v0.3
    2. Searching for controllers... done (6.12s)
    3. Found the following controller(s): 21
    4. Controller 21: ATMega88
    5. Erasing flash... done (0.41s)
    6. Programming flash... done (3.77s)
    7. Verifing flash... done (3.00s)
    8. Erasing eeprom... done (0.89s)
    9. Finished!



    werde bei gelegenheit mal von kernel 2.6.30.1 upgraden.


    -- randy

  • Quote

    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.


    Quote


    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

  • 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

  • Quote

    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

  • Quote

    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.


    Quote

    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.


    Quote

    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