das ist ja großartig! Danke für das Posting!hamlet hat geschrieben:Charmed Labs hat eine neue PixyMon-SW (2.0.4) samt neuer Pixy-Firmware (2.0.5) herausgebracht.
fein da bin ich gespannt.Ich arbeite gerade an einer Treiberversion, die auch ColorCodes erkennt... kommt in Kürze.
Das würd ich als Bug bezeichnen. Schau ich mir an. Hab leider keinen Logic-Analyzer sondern nur ein billiges China Speicherscope. Aber das müsste zu erkennen sein: Zwei klare Objekte und einfach Wörter zählen, evtl. noch in die Syncs identifizieren. Die Messung ginge auch mit dem TX, der nun wohl doch CSV Daten im Offline Betrieb aufnimmt. Oder ich häng meinem mbed dran und schau über die Serielle rein.denn die beiden Sync-Worte schickt er nach meinen Tests vor jedem Block (in der Dokumentation hatte ich das auch erst anders verstanden, und codierungstechnisch ist es Unfug). Hast Du unterschiedliche Syncs auf dem Bus bei Frames und Blöcken erkannt?
Ahhh! Das ist doch Schweinkram!"Pixy_BlockSync" tatsächlich auch so gemeint: die Pixy beginnt nämlich einfach loszusenden - nicht nur mitten in einem Frame, sondern sogar mitten im Block..
Bislang sind mir noch keine Übertragungsprobleme aufgefallen. Signatur 7 funktioniert, glaub ich, wirklich nicht. Bei mir werden die Farbsignaturen sauber im Pixy's Flash gespeichert. Hoffentlich ist Reis Pixy nicht kaputt.Hast Du mit der neuen Firmware keine Übertragungsprobleme? Im Pixy-Forum klang das an... und die "Signatur 7" funktioniert wohl nicht.
(Aber das wird sicher bald per Update behoben.)
das sehe ich auch so.hamlet hat geschrieben:Das würd ich als Bug bezeichnen.
Super. Ich kann mich irren - vielleicht waren meine Testroutinen zu langsam und ich war schon mit einem Block am Frame-Ende. Ich könnte die Sync-Worte mal zählen und für jedes ein Lämpchen anschalten... alles andere (Online-Mode, TX-Display oder gar I2C-Display) kostet zu viel Laufzeit.hamlet hat geschrieben:Schau ich mir an.
Wenn Du Dich da auf mein gestriges Posting beziehst: das habe ich eben korrigieren müssen... Bei meinem Test des Offline-Mode standen die Daten aus dem Online-Mode-Tests noch im .csv-Speicher... peinlich. Da habe ich mich selbst ausgetrickst.hamlet hat geschrieben:Die Messung ginge auch mit dem TX, der nun wohl doch CSV Daten im Offline Betrieb aufnimmt.
Yep. Die haben alles auf Tempo getrimmt: da kommt einfach ein Daten-Burst. Wenn man den I²C-Bus nicht ständig reserviert hält (ganz hässlich, habe ich in keinem meiner bisherigen Treiber machen müssen), verliert man Daten. Möglicherweise verhält sich Dein Firmware-Update besser - schließlich soll damit ja sogar eine Einstellung von Parametern via seriellem Interface möglich sein. Und dafür muss es einen "Rückkanal" geben.hamlet hat geschrieben:Ahhh! Das ist doch Schweinkram!
Dann werde ich jetzt auch mal "upgraden". Und schauen, was die neue Version noch so alles für die nächste Treiberversion hergibt...hamlet hat geschrieben:Bislang sind mir noch keine Übertragungsprobleme aufgefallen.
Während Du Dein Scope gequält hast, habe ich ein Testprogramm geschrieben, das bei einem bzw. zwei aufeinanderfolgenden Sync-Worten ein Lämpchen einschaltet. Ist bei trägem Glühdraht und langsamem Auge kein toller Test, aber tatsächlich: das "Ein-Sync-Wort"-Lämpchen leuchtet (bei ca. 10 Objekten vor der Pixy-Linse) gefühlt "unterbrechungsfrei" (also mit fast maximaler Helligkeit), das "Zwei-Sync-Worte"-Lämpchen glimmt kaum sichtbar: Also stimmt die Spezifikation offenbar auch bei meiner (älteren) Firmware-Version.hamlet hat geschrieben:Zumindest mit der 2.0.5 läuft der Sync so wie dokumentiert.
Code: Alles auswählen
uint16_t Blobs::getBlock(uint8_t *buf, uint32_t buflen)
{
uint16_t *buf16 = (uint16_t *)buf;
uint16_t temp, width, height;
uint16_t checksum;
uint16_t len = 7; // default
int i = m_blobReadIndex*5;
if (buflen<8*sizeof(uint16_t))
return 0;
// PIXYYYYYYYYYYYYYY erst kommen die normalen ColorObjects und dann die ColorCodes
if (m_blobReadIndex>=m_numBlobs && m_ccMode!=DISABLED)
return getCCBlock(buf, buflen);
// PIXYYYYYYYYYYYYYY Alle ColorObjects abgerufen? Dann einfach mal 2 Nullwörter in die TxQ schreiben.
// PIXYYYYYYYYYYYYYY Naja ... Das sieht nur so aus. Tatsächlich ist es nur ein Null-Wort. Der Rückgabewert 2 (byte) zeigt
// PIXYYYYYYYYYYYYYY der Transmit-Queue nämlich lediglich ein Nullwort an. Vergleiche auch das return am Funktionsende.
// PIXYYYYYYYYYYYYYY Da dieser callback beim Sende-ACK gerufen wird, ist die Wahrscheinlichkeit jedoch hoch,
// PIXYYYYYYYYYYYYYY dass gleich noch ein Nullwort in die Transmit-Queue geschrieben wird.
// PIXYYYYYYYYYYYYYY Das erklärt auch das merkwürdige Nullwort am Anfang des Frames bei meinem Test.
if (m_mutex || m_blobReadIndex>=m_numBlobs) // we're copying, so no blocks for now....
{ // return a couple null words to give us time to copy
// (otherwise we may spend too much time in the ISR)
buf16[0] = 0;
buf16[1] = 0;
return 2;
}
if (m_blobReadIndex==0) // beginning of frame, mark it with empty block
{
buf16[0] = BL_BEGIN_MARKER;
len++;
buf16++;
}
// beginning of block
buf16[0] = BL_BEGIN_MARKER;
// PIXYYYYYYYYYYYYYY Ab hier wird ein kompletter Block in die TxQueue geschrieben
// PIXYYYYYYYYYYYYYY => es werden also immer komplette Blöcke ausgegeben!
// PIXYYYYYYYYYYYYYY Keine New-Frame-Grätsche (FrameSync mitten im Block) mehr in der 2.0.5 FW
// PIXYYYYYYYYYYYYYY getCCBlock schreibt ebenfalls komplette Blöcke
// model
temp = m_blobs[i];
checksum = temp;
buf16[2] = temp;
// width
width = m_blobs[i+2] - m_blobs[i+1];
checksum += width;
buf16[5] = width;
// height
height = m_blobs[i+4] - m_blobs[i+3];
checksum += height;
buf16[6] = height;
// x center
temp = m_blobs[i+1] + width/2;
checksum += temp;
buf16[3] = temp;
// y center
temp = m_blobs[i+3] + height/2;
checksum += temp;
buf16[4] = temp;
buf16[1] = checksum;
// next blob
m_blobReadIndex++;
return len*sizeof(uint16_t);
}
Es ist der Film "Jagd auf roter Oktober" mit Sean Connery nach dem Roman von Tom Clancy.hamlet hat geschrieben:nach x,y,h,w kommt nur 1 Sync Wort 0xaa55 ... in welchem Film war das noch: "Aber nur einen Ping!"?
Code: Alles auswählen
> help cam_setLightMode
cam_setLightMode(INT8 mode)
Set light mode to compensate for low or high lighting conditions
Parameters:
mode: one of the following: CAM_LIGHT_NORMAL (0), CAM_LIGHT_LOW (1), CAM_LIGHT_HIGH (2)
Returns:
0 if success, negative if error
> cam_setLightMode 1
response: 0 (0x0)Code: Alles auswählen
> help cam_setMode
cam_setMode(INT8 mode)
Set camera mode
Parameters:
mode: 0=25 FPS, 1280x800; 1=50 FPS, 640x400
Returns:
0 if success, negative if error