¡ACID! Neue Software für die x0xb0x (MarOs 1.5+)

Dieses Thema im Forum "Lötkunst" wurde erstellt von Nоrdcore, 5. Mai 2017.

  1. Nоrdcore

    Nоrdcore Spezialist

    Vor einiger Zeit hatte Mario euch hier ja sein MarOS vorgstellt.

    Das ist eine Weiterentwicklung des Sokkos, mit Schwerpunkt auf Performance und Pattern-Variation.

    Da der Platz im Programmspeicher der x0xb0x begrenzt ist, fehlt dem MarOS der Track-Mode.
    Ansonsten sind so gut wie alle Features aus Sokkos 2 vorhanden, nur an einigen Stellen haben Mario und ich die Bedienung etwas verändert. Zum Teil weil mehr Möglichkeiten untergebracht werden wollten, zum Teil, weil es nicht so gelungen schien.

    Ich habe dabei den Code ganz massiv überarbeitet und aufgeräumt, das hat Mario weiteren Platz verschafft, um seine Performance-Modes auszubauen.
    Außerdem habe ich *sehr* viele Fehler raus gemacht, wo die bisherige Firmware einfach immer wieder nicht ganz das machte, was sie sollte - oder was sinnvoll gewesen wäre.

    So gibt es jetzt funktionierenden Swing, der auch per DIN und Midi Clock ausgegeben wird, selbst wenn die x0x selber per Midi "straight" gesynct wird.
    (Den Swing hat Mario gemacht, dass Midi und generelles Timing jetzt kein Zufall mehr sind, kommt von mir...)

    Man kann bei laufendem Sequencer zwischen "Pattern-Play", also dem Performance-Mode und Pattern-Edit umschalten, wo man die Noten/Accents/Slides ediert.
    (Das kann Sokkos 2 auch schon, aber das läuft jetzt deutlich konsistenter in Bezug auf Start/Stop, Midi, welche Pattern verwendet werden... )

    Ich habe die Konfugurations-Einstellungen per User C aus Sokkos übernommen und auf bis zu 5 Gruppen à 8 Bit erweitert, dadurch kann man jetzt einiges an Einstellungen selber machen, ohne dass man sich per Compiler seine eigene Firmware stricken muss.

    Die aktuelle Entwicklung könnt ihr im Adafruit x0xb0x Forum verfolgen, da gibt es auch Downloads.
    Im ersten Posting https://forums.adafruit.com/viewtopic.php?f=13&t=33914 gibt es die Doku, die aktuelle Bugfix-Version gibt es gerade hier: https://forums.adafruit.com/viewtopic.p ... 70#p583356

    Die Version lässt sich übrigens auch für die x0xLarge CPU übersetzen (ich nutze die, weil die zum einen keine Platzprobleme und zum anderen einen freien Debugger-Anschluss hat). Bei Interesse fragen, wenn ich eine Version habe, bei der mir keine Bugs mehr bekannt sind, dann baue und veröffentliche ich die aber auch noch (als Midi-Sys-Ex Datei).

    Das Update selber ist bei der normalen x0xb0x etwas tüddelig. (Also für Musiker, für uns Embedded Controller Nerds ist das ...ähm .., auf der "so wie üblich" Skala eher bei den einfachen Varianten...)
    (Man braucht ein Tool namens c0nb0x, http://antonsavov.net/cms/projects/c0nb0x.html .. man muss wissen (Systemsteuerung=>Gerätemanager auf welchem (virtuellen) COM-Port die x0xb0x gelandet ist (da sitzt ein Standard USX-Com umsetzter Chip for dem Controller, der den Sequencer gibt..))
    Im Zweifel auch dazu gerne fragen.
     
  2. nanotec

    nanotec Tach

    Re: Neue Software für die x0xb0x (MarOs 1.5+)

    Super, tolle Arbeit.
    Damit muss ich mich im Sommer wenn ich mehr Zeit habe mal spielen.

    Derzeit ist auf meiner x0x noch eine Version von Limor/Adafruit drauf.
    Und ich vermute dass auch da Timing Bugs drinnen sind, kann das wer bestätigen?

    Ich habe mir mal den Quellcode runtergeladen.
    Welche Entwicklungsumgebung verwendet ihr?
     
  3. Nоrdcore

    Nоrdcore Spezialist

    Re: Neue Software für die x0xb0x (MarOs 1.5+)

    Wenn ich das recht erinnere, dann haben alle Firmware Versionen seit dem Adafruit Original (alle mir bekannten stammen davon ab) einen Timing Bug, der die x0x einen (Midi-Clock-)Tick zu spät startet.
    Das haben wir im MarOs nicht mehr.

    Ich habe das komplette Timing umgebaut. Ziel (erreicht!) ist es, einen Jitter unter 1ms zu haben. Unbedingt, also auch, wenn die Kiste das Pattern oder das aktuelle Tempo speichert. Letzteres war selbst im aktuellsten Sokkos ein Problem, dreh mal fix am Encoder und das Ding verschluckt sich.

    Weiteres Ziel war es, auch auf einem reichlich beschickten Midi-Datenstrom *keine* Probleme zu bekommen. Mit meiner Version schaffe ich keine hängenden Noten (usw.) mehr, auch nicht, wenn ich die mit einem reichlich vollen polyphonen Datenstrom zurümpel. (Bach bei 300BPM und so.)

    MarOS stammt von Sokkos ab, den genauen Verlauf weiß ich nicht (mehr?). Ich habe mich bei den Features aber weitgehend an Sokkos 2 orientiert, das meiste davon sollte vorhanden sein.
    Wie gesagt, der Track-Mode fehlt aus Platzgründen völlig, das meiste andere, was Mario aufgrund Platznot raus genommen hatte, konnte ich wieder reinbauen, weil durch die Code-Aufräumerei kein doppelter Code mehr vorhanden ist. Was auch einiges an undurchsichtigem Verhalten beseitigt hat, denn es war ja mitnichten so, das die doppelten Teile alle genau gleich waren, da hatte jedes sein eigenes Feature-Set und Bug-Paket.

    Übrigens ist da immer noch etwas Luft nach oben[1], allerdings sicher nicht mehr im MarOS-1.5.x Versionspfad. Diese Version werde ich jetzt nur noch um wenige kleine Features ergänzen (3 Punkte offen, siehe Adafruit-Posting) , die Bugs raus machen, und dann kommt der Deckel drauf.
    Insofern ist das derzeit wirklich Beta-Testphase.
    Dann kann man dafür auch mal ein vernünftiges Handbuch machen.

    Den Quellcode dafür werde ich auch erst dann veröffentlichen, wenn das soweit fertig ist, das ist mir sonst zu nervig.


    Entwicklungsumgebung ist ATMEL Studio 7. Die bekommt man kostenlos von ATMEL und sie ist sehr einfach zu installieren und zu benutzen.
    Wie gesagt, ich entwickle weitgehend auf der x0xLarge CPU, man muss schon sehr masochistisch drauf sein, um mit der Original-CPU ohne Debugger zu entwickeln.

    Was natürlich geht, sind einfachste Anpassungen, oder gar vorgesehene Anpassungen: in einer extra Header-Datei einstellen, was die Firmware machen soll, und sich dann seine eigene Version bauen.
    Das hatte ich auch schon mal überlegt/angefangen, allerdings war es bislang doch eher so, dass es keine Leute gab, die daran Interesse hatten.
    Obwohl das in Anbetracht des knappen Code-Platztes gar nicht so blöde ist. Denn ich kann nur weniges im fertigen Programm "schaltbar" (im Sinne von Konfigurierbar auf die individuellen Bedürfnisse) machen, weil dafür einfach der Platz fehlt.
    Per Compiler-Schalter ginge da sehr viel mehr, denn dann braucht alles abgewählte auch keinen Platz.

    _____________________________
    [1] dabei würde sich das Bedienkonzept merklich ändern.
    Insbesondere der Mode-Schalter braucht dann einen Aufkleber, die Sync-Modes müssen da runter, sonst kommt man einfach nicht sinnvoll weiter.


    Übrigens: eine an die Original 303 angelehnte Bedienung gibt es auch: http://antonsavov.net/cms/projects/n0nx0x2.html
    In die Richtung werde ich *nichts* machen. Das wäre übrigens eine komplette Neuentwicklung, insofern fasse ich jede Diskussion darüber mal als "bitte investiere mal eben kostenlos 5000 Entwicklerstunden, damit ich die 50€ für die große CPU spare" auf, und betrachte den Fragesteller als ignorantes Arschloch und/oder Vollidioten.
     
  4. darsho

    darsho verkanntes Genie

    Re: Neue Software für die x0xb0x (MarOs 1.5+)

    Ich freu mich riesig darauf, das auszuprobieren :supi:

    interessehalber: können das auch diejenigen benutzen, die so eine Mode Machines xoxbox haben ?
     
  5. NickLimegrove

    NickLimegrove bin angekommen

    sehr cool! Ich hatte schon seit längerem ein Auge auf MarOS, aber konnte bislang noch nicht updaten, weil ich meine xoxbox (1. Hand, gebaut im xoxshop ~01/2016) partout nicht mit meinen Rechnern zum Laufen kriege. Alle möglichen Kombis von Betriebssystemen, Treiber, Einstellungen durch... keine USB-Verbindung, nirgends. Sodass ich mittlerweile immer mehr vermute, dass da hardwareseitig irgendein Fehler drin ist (meine, im ada-Forum gelesen zu haben, dass das nicht unüblich ist). Mit dem nochmals gepimpten MarOS ärger ich mich jetzt noch mehr, dass ich mich nicht durchringen kann, die Box einfach mal zum Check in den shop zu bringen, weil mich die Aussicht so frustriert, dann bestimmt ein paar Wochen ohne sein zu müssen...
    :waaas:
     
  6. Nоrdcore

    Nоrdcore Spezialist

    Re: Neue Software für die x0xb0x (MarOs 1.5+)

    Ja.

    Es gab mal das Gerücht, dass die MM-x0xen keinen Bootlader haben, aber das war wohl dumm und/oder boshaft in die Welt gesetzt.
    Die Update-Prozedur ist ja nicht so ganz Plug and Play, da kann auch schon mal User-Error zu solchen Gerüchten führen.
    Dümmstenfalls der Defekt eines einzelnen Gerätes nebst entsprechendem Vorurteil, in der Szene hat MM/TBS/MAM/... ja nicht den besten Ruf.



    Das tritt in der Tat recht häufig auf.
    Die Datenübertragung zwischen Computer und x0x ist allerdings relativ kompliziert, das muss nicht immer an der Hardware scheitern.

    Zunächst mal das Konzept im überblick, es hilft bei der Fehlersuche wenn man die unterschiedlichen "Schichten" im Kopf hat.

    In der x0xb0x sitzt ein kleiner Mikrokontroller vom Typ ATMEGA162. Der gibt den Sequencer, liest die Tasten und steuert die LEDs an. Der hat zwei serielle Schnittstellen. Eine ist für das Midi-Interface, eine für die Computer-Verbindung. Der DIN-Sync ist "primitiver" und wird direkt von der Firmware an ein paar "general purpose in/output" Pins erzeugt.
    Diese serielle Computer-Schnittstelle wird von einem kleinen "Spezialchip" (FTDI FT232BM) auf dem I/O-Board der x0xb0x auf USB konvertiert.
    Von da aus geht es dann über das USB-Kabel in den Computer.
    Im Computer sitzt zunächst mal der USB-Treiber, der sich um die USB-Verbindung zu dem Chip kümmert.
    Auf diesen Treiber setzt der nächste Treiber auf, der der Anwendungssoftware im Computer eine "virtuellen" serielle Schnittstelle (im PC-Jargon "COM-Port" genannt) vorgaukelt.
    Die Anwendungssoftware (bei uns hier heißt die c0nb0x ) spricht jetzt, über den ausdrücklich einzustellenden "richtigen" COM Port (z.B. COM4), mit der x0xb0x.

    Hat man keine Verbindung oder installiert das alles erst, dann *muss* man die Systemsteuerung aufmachen und gucken was dort passiert, wenn man die x0xb0 per USB anschließt bzw. sie einschaltet.
    (Reihenfolge ist egal, im laufenden Betrieb stecken ist zulässig. )

    In der Systemsteuerung müssen nun zwei Punkte auftauchen:


    ein aktuelles, nicht verfummeltes Windows 10 findet die nötigen Treiber von alleine, es fragt auch nicht weiter nach.
    Ansonsten installiert man den VCP-Treiber von der FTDI Webseite: http://www.ftdichip.com/Drivers/VCP.htm ("WHQL Certified. Includes VCP and D2XX. ")
    Der Treiber funktioniert gut, läuft stabil und zickt erfahrungsgemäß bei der Installation auch nicht herum. (Noch nie erlebt, und diese Chips sind recht verbreitet. OT: Allerdings auch die teuersten, weshalb man sehr oft mit 1$ billigeren Chips und deren Nerv-Treibern konfrontiert ist. )

    Fehlt der obere "COM" Eintrag braucht man nicht weitermachen, dann *kann* es nicht klappen.
    Die Nummer die dort angezeigt wird muss man *manuell* in der Anwendungssoftware eintragen.

    Dieser Eintrag taucht übrigen auf wenn man die x0xb0x einschaltet und er verschwindet wieder, wenn man sie ausschaltet/abzieht.
    So kann man auch identifizieren, ob es der richtige Eintrag ist.
    Einträge mit "Blutooth" oder "Nokia" sind übrigens *nie* die x0xb0x, die nutzen nur das gleiche Verfahren für andere Anwendungen. (Heute etwas veraltet, mit den HID-Treibern gibt es da ein für den Anwender weniger nerviges Verfahren. )

    Ok, haben wir da unseren x0xb0x-Treiber, dann können wir c0nb0x ( http://antonsavov.net/cms/projects/c0nb0x.html ) herunterladen und starten.
    (Zip auspacken und .exe anklicken, es ist keine Installation nötig. )

    In c0nb0x dann den COM-Port einstellen. Das nimmt gerne mal COM1, obwohl die Box da nie drauf ist. (... COM 1 ist bei fast allen PCs eine auf dem Mainboard noch vorhandene echte serielle Schnittstelle, die allerdings längst nicht mehr herausgeführt wird. )
     

    Anhänge:

  7. Budel_303

    Budel_303 bin angekommen

    Ich bin beim Os- Update auf ein kleines Problem gestoßen,

    im Gegensatz zu Nick, dem es offenbar garnicht möglich ist, seine Xoxbox per USB zu verbinden, habe ich diesen Teil schonmal überstanden.
    Die Verbindung steht und meine Pattern konnte ich auch exportieren.

    Beim Update-Prozess hakt es allerdings, ModeSelect steht entsprechend der Beschreibung auf Bootload, aber es wird mehr oder weniger direkt nach dem Start des Updates abgebrochen.
    [​IMG]
    Das bekomm ich als Nachricht.

    Die Xoxbox kommt aus dem alten Xoxshop und hatte bisher das SokkOs 1.9 installiert.

    Wäre für Hilfe sehr dankbar.

    :floet:
     
  8. Nоrdcore

    Nоrdcore Spezialist

    Wenn:
    * du Patterns von/zur der x0xb0x laden kannst.
    * das Update aber nicht funktioniert.

    Dann gibt es zwei Fehlermöglichkeiten:

    a) der Schalter steht nicht auf "Bootload" oder die Schalterstellung wird nicht erkannt.

    b) der ATMEGA162 enthält keinen Bootlader. Das kann beim programmieren durchaus passieren und man bekommt es nur per Programmieradapter repariert.
    (Hinweis: Dafür muss man allerdings nicht die ganze x0xb0x durch die Weltgeschichte schippern, die CPU reicht. Die ist i.A. gesockelt, lässt sich also relativ einfach entnehmen. )

    Das kann man einfach überprüfen: x0xb0x Ausschalten. Schalter auf "BOOTLOAD". Einschalten. Jetzt sollte er im Boolader sein, da wird der Schalter nicht weiter ausgewertet. Dreht man den Schalter jetzt auf Play und drück RUN/STOP dann darf nichts passieren. Rennt der Sequencer los, dann fehlt der Bootlader oder die Schalterstellung wurde nicht erkannt.
    Die beiden Fälle kann man hier nicht auseinander halten.
    Allerdings ist der Schalter binär kodiert, wenn die übrigen Schalterstellungen im normalen Betrieb (richtig zugeordnet) funktionieren, dann geht ziemlich sicher auch "BOOTLOAD".
     
  9. Budel_303

    Budel_303 bin angekommen

    Jetzt frag ich mich, wo mein Problem lag.

    Ich habe jetzt noch mehrere Male versucht, das Ganze durchzuführen.

    Conbox neu gestartet, nochmal den ComPort ausgewählt, Bootload aktiviert, Update gestartet....
    und beim dritten oder vierten Mal... klappt es.
    MarOs is drauf, leider keine Zeit es jetzt ausgiebig zu testen, werde aber berichten :)


    PS: ist es eigentlich normal, dass sich Conbox nicht schließen lässt? Klick auf X ohne Erfolg, ebenso klick auf Fenster schließen in der Tastleiste..
    Taskmanager muss her - Windows 10
     
  10. Nоrdcore

    Nоrdcore Spezialist

    PS: ja ist normal, es erwartet die die "ESC" Taste :selfhammer:
     
  11. NickLimegrove

    NickLimegrove bin angekommen

    @Nordcore: vielen Dank für die ausführlichen Infos, weiß es sehr zu schätzen! In meinem konkreten Fall (kannst du natürlich nicht wissen) ist es nun leider so, dass das, was du beschreibst, schon alles so oft durch habe, dass ich selber fast schon Nachhilfe in deiner Kompetenzliga geben könnte ;-)

    Das fasst sehr schön zusammen, was bei mir los ist in Sachen xoxbox vs. USB ...nämlich exakt nichts. Ich kann mittlerweile glaubich guten Gewissens einfach sagen: es ist völlig egal, was ich tue -- niemals habe ich irgendwelche Anzeichen zu sehen bekommen, dass eine erfolgreiche Verbindung zwischen meinem Rechner und der xoxbox zustandekommt. Windows merkt, dass ich was einstöpsel, sagt »USB device not recognized«, und that's it. Weder c0ntrol noch c0nb0x kriegen irgendeine Kommunikation zustande. Den korrekten Treiber (und in meiner Verzweiflung immer wieder auch mal andere) habe ich schon so oft in-, dein- und reinstalliert, dass ich den Bereich Treiber ziemlich sicher ausschließen kann. Egal, was ich in Sachen Treibern mache, ich komme halt nicht mal an den Punkt, an dem Windows sagt (wie in deinem screenshot): »hier ist jetzt ein USB Serial Port«.

    Ich plane aber, meine Box in den nächsten Monaten ohnehin guten wegen eines angedachten Mods beim lieben Andreas vorbeizubringen. Dann nehmen wir das Thema mal gleich mit unter die Lupe...
     
  12. Nоrdcore

    Nоrdcore Spezialist

    In dem Fall ist der Bereich direkt am USB-Chip nicht in Ordnung.
    Das sind nur recht wenige Teile um den Chip herum.
    So als Beispiel: man vertauscht einen der beiden 27Ohm Chips in den Datenleitungen und lötet da 1k5kOhm ein (also R6 und R8 vertauscht). Dann erwarte ich genau das Beschriebene.
    http://wiki.openmusiclabs.com/wiki/x0xb ... board2.png
    (Es gehen auch diverse andere Fehler, das war jetzt echt nur ein Beispiel, von dem ich zufällig gelesen hatte, dass es zu deinem Symptom führt. Denn es gibt natürlich auch diverse Fehler, wo der Computer gar nichts erkennt. Das passiert ja (auch) wenn der Chip keine Spannung hat (absichtlich). )

    Wenn du den Fehler "USB device not recognized" bekommst, dann sollte der Eintrag in der Systemsteuerung (mit dem gelben Ausrufezeichen) bei weiterem drauf rumklicken (Rechtsklick, Eigenschaften...) *keine* UID und PID anzeigen (können), weil er so weit gar nicht gekommen ist.
    Da braucht man dann auch gar nicht mehr mit den Treibern herum zu hantieren, weil die Verbindung schon auf einer Ebene darunter gar nicht zustande kommt.
    *Wenn* er allerdings eine UID und PID anzeigt, dann muss das so aussehen, sonst ist der Chip eine Fälschung:
     

    Anhänge:

  13. NickLimegrove

    NickLimegrove bin angekommen

    okay, das trifft sich in etwa mit meiner bisherigen Diagnose. Zu diesen PIDs/UIDs kommt's halt z.B. gar nicht erst (Hardware ID = ›UNKNOWN‹...), genau wie du sagst. Werde das mit dem Chip und den Bauteilen drumrum weiterverfolgen und berichten, vielen Dank! :adore:

    [man kann ja den Strang hier fast schon aus dem eigentlichen Thema auskoppeln...]
     
  14. Nоrdcore

    Nоrdcore Spezialist

    Kannst du selber löten und wäre es dir möglich einfaches Sachen zu reparieren?
    Dann fotografiere mal den Bereich um den USB herum, evtl. ist der Fehler ja nicht so schwer zu finden...
    Man sollte halt die Widerstände erkennen können, wenn die nicht so schön liegen wie bei mir, dann braucht es da evtl. auch ein paar mehr Fotos von der Seite.
     

    Anhänge:

  15. NickLimegrove

    NickLimegrove bin angekommen

    sagen wir so: nicht so gut, dass ich selber Hand an das gute Stück legen würde. Aber ich kann morgen natürlich echt mal reinschauen und 'n Foto machen.
     
  16. lowcust

    lowcust bin angekommen

    Diesen Fehler habe ich auch und konnte dennoch das Update duechführen.

    1. x0xb0x im Computer Controlled Modus starten und per Usb verbinden.
    2. Treiber Installieren wie Nordcore es beschrieben hat.
    3. x0xb0x wieder auschalten und erneut im Bootload Modus starten.
    4. Nun die c0nb0x Software starten der scant beim Starten die Serialports, dann ohne Umwege direkt die Option Firmware update aufrufen.
    Der rest ist selbsterklärend.

    https://www.instagram.com/p/BTw0fn_Dtxg

    Nur so hat es bei mir geklappt, ansonnsten hab ich immer diesen Id Fehler und das der Bootloader fehlt.

    Viel Erfolg, Grüße
     
  17. Nоrdcore

    Nоrdcore Spezialist

    ...ähm ... das ist so nicht wirklich kausal, bzw. du hast den Fehler nur zufällig umgangen.

    Ich glaube mir ist gerade das *eigentlich* Problem eingefallen:
    Die x0xb0x Hardware hat in der LED-Treiberschaltungen einen blöden Fehler: die sind nach dem Einschalten zufällig an oder aus. Das ist abhängig von den Chips die da drin stecken (Hersteller, Jahrgang, Mondphase als sie diffundiert wurden...).
    Sind nun sehr viele bis fast alle LEDs an, dann bräuchte die Kiste mehr Strom, als das Netzteil liefern kann. Die 5V Spannung bricht dann ein. Der Atmel bootet nun allerdings auch mit 2,7V schon zuverlässig, und schaltet dann 1..2 Sekunden später die LEDs aus. Und dann geht die Spannung auf 5V und alles läuft.
    Außer im Bootlader. Da werden die LEDs nämlich gar nicht initialisiert. Dann bleibt die Spannung niedrig, zu niedrig für den USB-seriell Chip.

    Außerdem kann der USB-seriell Chip mit diesem langsamen und wackeligen Hochfahren der Versorgung Probleme haben. (.. Vermutung, aber recht viele intergrierte Reset-Schaltung sind erstaunlich pisselig, was den Verlauf der Versorgung beim Einschalten angeht... )

    Was tun:
    a) *wenn* ihr das Problem aktuell habt, also in der Windows-Systemsteuerung wird die x0xBox als "kann Gerät nicht identifizieren" angezeigt, dann messt bitte mal die Versorgungsspannung (5V) nach.
    Das verifiziert die Diagnose.

    b) probiert aus die x0xb0x normal in "PATTERN play/sync out) einzuschalten, warten bis nur noch die "normalen" 2LEDs an sind und Tempo blinkt.
    Dann auf BOOTLOAD drehen und x0xb0x kurz aus und gleich wieder einschalten.
    Dann bleiben die LEDs weitgehend in der letzten Stellung, also aus. (Wenn die TEMPO LED allerdings immer noch blinkt, dann war aus/ein zu kurz und die x0x hat nicht neu gebootet... )

    Jetzt mal erneut in der Systemsteuerung nachsehen, ob der FTDI-USB-Seriell-Chip korrekt identifiziert werden konnte.

    c) Hardware so umbauen, das sie vernünftig funktioniert.
    Das habe ich bei meiner x0xb0x natürlich längst gemacht.
    Und zwar alleine schon aus optischen Gründen, das sah vorher einfach zu sehr nach "typischem DIY-gestümper" aus.
    Wobei meine x0x noch nicht mal bei jedem Einschalten auf die Füße gekommen war.

    ===========================================
    Und noch mal zu Klarstellung:

    es ist nicht sinnvoll c0nb0x zu starten oder darauf herum zu klicken, wenn in der Systemsteuerung *nicht* der COM-Port angezeigt wird. Das hat niemals eine Wirkung jenseits von Zeitverschwendung und/oder Placebo.

    Windows lädt die Treiber für den FTDI-Chip automatisch, wenn sie auf dem System sind und der Chip erkannt wurde. Dazu muss der Treiber nur ein einziges mal installiert worden sein, das passiert i.A. sogar automatisch.
    Die Treiberinstallation hat absolut keinen Effekt oder Einfluss, so lang der Chip gar nicht identifiziert werden kann.
    Insbesondere *kann* der Treiber diesen Fehler unter keinen Umständen beseitigen, denn er wird vom Windows erst dann gesucht, wenn es den Chip identifiziert hat und daher den Treiber passend aussuchen kann!
     
  18. Nоrdcore

    Nоrdcore Spezialist

    Bug-Report im Adafruit-Forum: Im Midi-Mode geht NOTE OFF nicht immer.
    Habe ich hier bereits repariert, Update kommt heute noch, da sind dann auch die übrigen drei offenen Punkte abgearbeitet.
     
  19. lowcust

    lowcust bin angekommen


    Danke für die ganze mühe. Am Netzteil kann es denke ich nicht liegen 9~ 1500mA sollte reichen, hab meine x0xb0x als Kit vor ca. 3 Jahren bei x0xboxshop gekauft, wäre intressant zuwissen ob das ein Problem dieser Serie ist.
     
  20. Nоrdcore

    Nоrdcore Spezialist

    Das LED-Problem *ist* ein Serienproblem, das haben alle x0xboxen (außer meine und die von Darsho).
    Ansonsten weiß ich natürlich nicht, ob das ein Serienproblem ist, denn um das zu wissen, müsste ich den Fehler erst mal auf eine kausale Ursache zurückführen[1].

    ==================
    Die Stromversorgung ist nicht nur das Netzteil.

    Für meine x0xb0x kann ich das ja mal vorrechnen:
    am 7805 habe ich rund 12V, macht 7V Spannungsabfall.
    Ich habe relativ dunkle rote LEDs verbaut und dafür sitzen da 330Ohm Vorwiderstände, an denen 2,7V abfallen, wenn die LED an ist, 2V an der LED, 0.3V am CMOS-Ausgang. Macht einen Strom von 8mA pro LED und rund 40Ohm Ausgangswiderstand vom 74HC594.
    8mA mal 40 LEDs sind 320mA. 0,3A*7V sind 2.1W Verlustleistung im Regler. Die macht der ohne Kühlkörper nicht lange mit[2], er würde dann nach einiger Zeit so heiß, das die Ausgangsspannung absinkt. Bei rund 2V [3] würde gar kein Strom mehr durch die LEDs mehr fließen, es gibt also einen stabilen Arbeitspunkt, an dem der Regler seine Temperatur auf dem zulässigen Maximum - und nicht etwa die Ausgangsspannung konstant - hält.

    Dieser Zustand ist von außen prima zu sehen: da müssen halt viele LEDs an sein. Wenn fast alle LEDs aus sind - wie im Normalbetrieb, dann ist das nicht das Problem.
    (.. und so lange mir keiner sagt, wie sich das bei seiner x0xb0x, die sporadisch updated, verhält, kommen wir hier nicht so recht weiter... also: sind die LEDs überwiegend an oder aus, welche Spannung misst man an der 5V Versorgung, und wie heiß wird der Regler? Welche Vorwiderstände haben die LEDs (R237 ist z.B. der für die Step#1 LED), welche LED-Farbe. )



    [1] Nur um mal die Bandbreite zu verdeutlichen, *wo* das alles stecken kann: in der x0xb0x wird der FTDI Chip mit einem Keramikresonator betrieben. Ohne den im Datenblatt empfohlenen 1MOhm Parallelwiderstand. Außerdem geht dort nicht jeder Resonator, sondern er muss genau genug für diese Anwendung sein, was nicht selbstverständlich ist. Ich vermute da eher keine Probleme aber, wie problematisch das nun wirklich ist, weiß ich einfach nicht. ( ... ich entwickle nicht für die 10.000er Stückzahlen, wo es sich lohnen würde, die paar Cent bei Quarz vs. Resonator einzusparen. )

    [2] RTH ist 50°/W, Tj max. 125°, Raum sei 25°, dann haben wir 2W maximal. Free Air, nicht im Gehäuse. Da der Rest der Schaltung auch noch ein paar 10 mA braucht, sind wir also auf jeden Fall in einem Bereich, wo Probleme sehr gut möglich sind. Und die Spannung muss auch gar nicht so viel kleiner werden (was man an dunklen LEDs sehen würde), um den Strom auf verträgliche Werte zu bringen.

    [3] da arbeitet der Rest der Schaltung aber nicht mehr. Atmel und HCMOS ist ab 2.7V spezifiziert, d.h. die laufen hier auch noch, wenn der Regler heiß ist.
    Der FT232 will 4.35V minimale Versorgung.


    P.S.: FTDI-Chip USB Debugging. Das ist recht verständlich geschrieben: http://www.ftdichip.com/Support/Documen ... -06_11.pdf
     
  21. lowcust

    lowcust bin angekommen

    Hab momentan keine Werkstatt und Zuhause nicht die Ruhe um Dir genaue Infos über meine x0xb0x zu liefern, Okay die Vorwiederstände zu checken kann ich die Tage aber nachreichen.
    Bei meiner sind die Led meistens Aus und das Hochstarten holpert hier und da.

    Grüße
     
  22. Nоrdcore

    Nоrdcore Spezialist

    Dann ist meine Vermutung nicht korrekt - denn, die basiert eben darauf, das im Problemfall(!) fast alle LEDs an sein müssten.

    Nachtrag:
    gerade mal etwas herumprobiert: es geht wirklich in einem relativ weiten Bereich, dass der Atmel stabil läuft, der FTDI aber nicht oder sehr wackelig.
    Es ist hilfreich, sich das in USBView anzusehen, das reagiert schneller und weniger flimmerig als die Systemsteuerung, und es zeigt auch eher mal Probleme an, wo die Systemsteuerung schon gar nichts mehr anzeigt.

    Dazu muss die Versorgung einfach nicht ganz OK sein, was man bereits mit dem Multimeter sieht: die Versorgung sollte recht genau 5V sein, vor allem aber konstant.
    Wenn die im Problemfall in Richtung 4V driftet, dann ist man dem Problem auf der Spur.
     
  23. Nоrdcore

    Nоrdcore Spezialist

    Zurück zum eigentlichen Topic:

    bin gerade per PN gefragt worden, wo denn Pattern löschen geblieben ist.
    (Kann mir mal einer erklären, warum solche Fragen per PN geschickt werden? Geheimwissen erwerben? Ist das Forum nur noch für den täglichen Dummschwall ahnungsloser Besserwisser da? )

    Das ist tatsächlich raus gefallen.

    Solche Sachen sind übrigens genau das, worum es jetzt - in der Testphase - geht.

    Der Code-Aufwand dafür ist zwar nicht groß, aber ich vermute mal, das Mario das mal aus Platzgründen raus genommen hat. Die meisten solchen Sachen habe ich wieder rein gebaut - eben weil es sich kaum gelohnt hat - aber da kann mir immer was durch die Lappen gegangen sein. Wie eben das "Pattern löschen" hier.
    Ich bin mir auch nicht sicher, ob man die Funktion wirklich braucht, manchmal kann man so etwas ja sehr einfach anders hintricksen. Hier evtl. Pattern auf den ersten Step kürzen ... (nur so als Idee zum Ausprobieren, ich weiß nicht ob das gut genug funktioniert oder ob es nicht doch zu umständlich ist... )
     
  24. Nоrdcore

    Nоrdcore Spezialist

    Ich habe das mit dem Pattern löschen auch drüben bei Adafruit mal gefragt.

    Dort kam dann der Hinweis auf: zwei mal kurz hintereinander "F" (Undo) im "randomizer" Mode zu drücken. ("Randomizer mode" ist Chain-Taste (Chain LED ist An) im Pattern-Edit Mode. )
    Das setzt alle Noten auf einen Wert, ohne Accent/Slide.


    Nähkästchen: Eine Tastenfunktion die aus Code-Sicht eher blöd ist, weil dieser "Doppelklick" sonst nirgends vorkommt und dafür dann doch relativ viel Code-Space braucht. Allerdings sind im Randomizer Mode schon alle Tasten belegt, daher hatte Mario das wohl so gemacht. Die ist also durchaus ein Kandidat für "kann nicht ewig so bleiben". Denn um den Code effektiver/kleiner zu bekommen, muss er extrem systematisch werden. Also wenige Prinzipien, die immer wieder vorkommen, und nicht an jeder Ecke eine andere Variante.
     
  25. Nоrdcore

    Nоrdcore Spezialist

  26. Lauflicht

    Lauflicht x0x forever

    :supi: Danke für Deine tolle Arbeit.
     
  27. nanotec

    nanotec Tach

    Also genau das was für den Anwender dann eine gute Usability ausmacht :)
    => zwei Fliegen mit einer Klappe.

    Ürbigens danke für deine tolle Arbeit :supi:
     
  28. Nоrdcore

    Nоrdcore Spezialist

    Cool, dann sind das hier ja doch einige, die das noch Verfolgen.

    Wäre fein, wenn der eine oder andere die Software etwas "bespielen" könnte und von Problemen und Auffälligkeiten berichtet.
    Auch falls mir noch was nützliches aus Sokkos 2 durch die Lappen gerutscht ist.

    Das nächste Wochenende ist - dank Brückentag - lang, da würde ich das ganz gerne finalisieren. Also so weit den Deckel drauf machen, dass alle Klingelchen und Glöckchen an der richtigen Stelle sind, ich die Doku machen kann und dann nur noch - hoffentlich sehr wenige - reine Bug-Fixes verbleiben.


    Nähkästchen:
    Offene Punkte sind derzeit noch:
    * Der Takt-Synchrone Start/Stop bei externer Clock. ("Mungo-Sync"-Funktion)
    inklusive "Taktraster raten", derzeit favorisiere ich da allerdings eine schlichte 4/4-Lösung. Allenfalls manuell auf 1/4 umschaltbar, d.h. wer andere Takte verwendet muss dann auch auf 1/4 genau die Taste treffen.
    Was ja schon mal deutlich realistischer ist als 1/16-tel bzw. 1/96-tel (Midi/DIN-Clock-Auflösung).

    * Start-Abspielposition "raten" für Midi-Continue.
    Da weiß ich noch gar nicht so recht, was man da wirklich haben will.
    Ich bekomme von der DAW den SPP (Song Position Pointer). Falls die DAW mitten im Song losrattert kann ich damit die x0x auf die passende Postion im Song setzten.
    Die Idee ist nun folgenden: ich lasse den x0x-Sequencer genau so loslaufen, als wenn man mit "Start" von Anfang, in der derzeitigen Einstellung, bis zur derzeitigen Position laufen würde.
    D.h. die derzeitige Chain (Patternfolge) wird sozusagen von Start an durchlaufen.
    Das klingt erst mal furchtbar sinnvoll - aber gerade wenn man doch eher an der x0x performt und krumme Patternlängen hat, dann wird das nicht unbedingt hinhauen. Hat man aber lauter "gerade" Patternlängen, dann ist das eher viel zu kompliziert. Der Code-Aufwand dafür ist nicht ganz klein, denn ich muss die Pattern-längen dazu verwalten, beim zeitkritischen Startvorgang kann ich (vermutlich) nicht alle Pattern erst mal auszählen, mal davon abgesehen, dass auch das etwas länglicher Code würde.


    * überarbeiten der oben angesprochene Pattern-Fill-Funktion.
    Die Bedienung ist daneben und braucht unangemessen viel Code.
    Klarer Fall von "nicht loslassen können" Featurismus. Es gibt in dem Modus 20 verfügbare Tasten, das macht 20 Funktionen. Da unbedingt 21 haben zu wollen sollte man 4 jährigen Trotzkindern und zahlenden Kunden überlassen. In einem Open-Source-Projekt hat so etwas nichts zu suchen, da will man anständige Lösungen.
    ( Die Chain-Taste schaltet den Modus An und Aus, RUN/STOP ist *immer* Run/Stop und "Done" geht in die "Speichern unter" Funktion. Verbleiben 20 Tasten. <---Punkt)

    -----------------------

    Das MarOs Projekt ist wohl aus Sokkos 1.9 entstanden, deshalb ist da nicht alles "von alleine" drin gewesen. Was z.T. gar nicht so blöde war, denn die Sokkos Erweiterungen, gerade in der 2er Version, sind doch etwas ...ääähm... rustikal programmiert gewesen. Das lief dann nicht immer alles so rund.
    Allerdings ist auch beim MarOS jetzt "schon wieder" Schluss, mehr ist da mit der bisherigen Taktik des Code-Aufräumens einfach nicht drin. Die Bedienung ist ja auch "voll", mehr passt so auf die Oberfläche nicht drauf, das ist eher schon zu voll. All zu barocke Bedienkonzepte vertragen sich auch nicht mit schlankem Code. Für mehr Funktionalität müsste man die Bedienung dann doch noch mal merklich umräumen - und dafür dann *neuen* Code entwerfen. Da ist dann aber der "Mode" Schalter da ein großes Problem, ich würde ihn aus heutiger Sicht als Fehlentscheidung betrachten. Bloß wenn ich den komplett umdefiniere, mithin einen Beschriftungs-Aufkleber für die neue Funktion brauche, sind die ganzen Leute mit "schicken" Gehäusen außen vor, die wollen sich die Optik ja nicht versauen.
    Ebenso dumm gelaufen übrigens die Wahl der CPU - mit anderem Pin-Out gibt es fast die gleiche CPU heute für weniger Geld in vier Speichergrößen bis 128kByte. ("Damals" war das natürlich noch nicht so absehbar ... )
     
  29. nanotec

    nanotec Tach

    Ganz zu schweigen davon dass ein "dummes" 16x2 Display der Kiste nicht geschadet hätte.
    Der Preis wäre nicht unwesentlich höher gewesen und man hätte so viel mehr Möglichkeiten beim Bedienkonzept, vs. derzeitigem Blindflug.
     
  30. bartleby

    bartleby echt reaktiv

    ich lese auch mit grossem interesse mit. leider kann ich im moment mehr nicht beitragen, obwohl ich sonst auch gern als tester aushelfe, aber derzeit fehlt mir dazu leider die zeit :sad:
     

Diese Seite empfehlen