Ny användare av tellsticken här. Sitter och leker lite med rfcmd på Freebsd 7.2, lite patchning för o få igång (skall bidra med lite vettiga patchar samt försöka få igång det till libtellduscore med, inte provat men vad jag ser och läst verkar det inte funka på FreeBSD, om den som linuxen bara jobbar med vanlig comport funkar det inte, då tellsticken inte verkar bli nån ucom på FreeBSD utan ugen som får accessas genom libftdi).
Anyway, I mitt petande i rfcmd så ville jag försöka få ner delayen mellan kommandona lite, i trunk begränsas detta rätt hårt med en simpel sleep(1). I core väntar man istället på svarskoden från enheten. Portade lite snabbt över detta, och med lite bench så ser det ut att ta runt ~575ms från att ftdi_write_data anropats tills dess att jag får en hel response (0x0A; + kommer in efter 123ms, S efter ytterligare 2ms).
Enl mina beräkningar skickade jag i detta testet med en proove-mottagare ut 52 bytes, ett basic S-kommando (ingen repeat eller så).
Enl protokollet bör varje byte som skickas generera en 10us*bytevärdet lång puls, vilket med de teststrängar jag körde ut skulle bli ca 33.55ms. Lägg till uart-speed på 4400 så blir det ca 10.8ms på transmit till enheten.. Totalt strax under 35ms mao.
Frågan är, har jag räknat fel nånstans, eller är det så mckt arbete för enhetens CPU (lr vad det nu kan va) att 500ms extra går åt nånstans, eller är det nått man kan optimera tro? Tänk tex scenariot att ställa in en "scene" (ett gäng presets för säg 5-6 mottagare), så går det ju åt ett par sekunder innan alla fått sin signal, inte helt optimalt.
Anyway, absolut inget akut, bara lite nördiga funderingar
Ang core i freebsd, om nån vet om det funkar/inte funkar så kanske ni kan säga till Annars ger jag mig nog på att porta det! Såg nån annan tråd om att slippa dependency på QT, nån timeframe för det?Och ännu en fråga när jag ändå håller på, ticket 48 nämner xPL-stöd, finns det några planer för detta? Annars blir det kanske ett litet projekt för mig
En liten tanke när jag läste koden som ni säkerligen redan är medvetna om, de bytes som skickas är i många fall specialtecken, om nån får för sig att råka ändra teckenuppsättning i sourcefilen kan det om man har otur bli väldigt fel... hex/int-koder känns som det är att föredra? Fast ni kanske har nån bra anledning
Finally, tack för en nice produkt, och mckt bra intiativ att köra opensource, annars hade jag nog aldrig köpt den
Mvh