No announcement yet.

Parallax Propeller - Command Timing for WRITE_OBJ

  • Filter
  • Time
  • Show
Clear All
new posts

  • Parallax Propeller - Command Timing for WRITE_OBJ

    I've extracted the following from another thread to continue the discussion here"
    When you sent a command you should wait for the ACK before sending another command as per the documentation, the duration of each command varies and has practically nothing to do with the number of objects present. It is not possible to document how long each command takes as it is influenced by many things:-1. Size of the object to be displayed (single biggest influence)2. Latency in sending system and hardware (Windows and CE5s especially)3. Comms Speed4. uSD Speed (note the uSD uses SPI mode and manufacturers speeds are specified for SD mode, there is no relationship. uSD Speeds will only vary by about 10% in SPI mode)5. What the display is doing (eg, playing video / sound)6. What the user is doing (eg touching or moving touch)
    Regarding the WRITE_OBJ delay times, I wasn't clear enough... the sequence I was testing was send WRITE_OBJ#1, receive ACK/NAK, send WRITE_OBJ#2, receive ACK/NAK with a delay required before attempting to receive the ACK from the display. (Propeller spin code snippets below) What I observed was that if I only had a single Gauge on the screen and switched with no delay (ok 4 about clocks at 80MHz really) between the last byte sent and waiting for the ACK the system would time out and never see the ACK or NAK. Adding a 10ms delay between the last byte sent and waiting for the ACK resulted in good performance. Adding another object (the LedDigits) caused time outs again. Increasing the delay from 10mS to 100mS resulted in good performance again. Keep in mind that the Parallax Full Duplex Serial, Tx and RxTime functions are running in one Propeller COG whilst their driver code is running in parallel in another COG. The Tx and RxTime functions are merely dealing with buffered data. Tx waits (blocks) until it gets its byte into the queue. RxTime waits until it receives a byte or times out. I am a bit baffled as to why the delay is required and why it increased with increasing object count. PUB Main | value VG.Start(0,2) ' Start VisiGenie object using pin 0 for Rx and pin 2 for Tx repeat 5 ' times value := 0 repeat 10 ' times VG.vgWriteObject(VG#Gauge,0,value) ' colourful bar graph VG.vgWriteObject(VG#Leddigits,0,value) ' green 7 segment LED simulation value += 10 waitcnt(800_000+cnt) ' 100 ms, more or less just to slow things down a bit PUB vgWriteObject(id,index,wValue) checksum := 0 ' reset checksum bcsSend(WRITE_OBJ) 'send the command with checksum accumulation bcsSend(id) 'send the object id with checksum accumulation bcsSend(index) 'send the object indexwith checksum accumulation wcsSend(wValue) 'send the 2 byte value MSB first with checksum accumulation FDS.Tx(checksum) ' send the checksum itself waitcnt(800_000+cnt) ' 100mS if (result := receive) == ACK return SUCCESS return FAILURE PRI receive repeat MAX_RECEIVE_TIMEOUT_ATTEMPTS result := FDS.RxTime(500) ' await a byte in the input buffer for up to 500 mS if result -1 quit ' the repeat loop ' will return -1 after MAX_RECEIVE_TIMEOUT_ATTEMPTS (4 in this case, or 2 seconds) successive timeouts ' otherwise returns the byte received

  • #2

    I did do a test using GTX of a LedDigits / Gauge Combo before writing before.

    Time to update Gauge ~30ms, LedDigits ~30ms (obviously both influenced heavily by windows)

    I'm not all that familiar with Propeller, but I'm wondering if it is using a different cog for each of the VG.vgWriteObject statements, that would help explain what you are seeing.


    • #3

      The only COGs running are one for the spin code and one containing the Full Duplex Serial driver's assembly code (buffer handling, io, etc). I'm not going to worry about it too much at this point since I can adjust for it as necessary and perhaps will stumble over the answer with time (often the case). If so, I'll post it here, whatever it is. Thanks for the prompt assistance though.