No announcement yet.

C Language Support - ISR - TSIC long blocking poll-time

  • Filter
  • Time
  • Show
Clear All
new posts

  • C Language Support - ISR - TSIC long blocking poll-time

    Hi Synapse,

    I want to read TSIC temperature data. Two data-bytes ar comming in every 80-120ms:

    Is the assumption right, that it will lead to problems if I just poll for the start-bit within the 1S_HOOK?

    Documentation quote:
    Time-triggered event handlers must run quickly, finishing well before the next time period occurs. To ensure this, keep your timer handlers concise. There is no guarantee that a timing handler will run precisely on schedule. If a SNAPpy function is running when the time hook would otherwise occur, the running code will not be interrupted to run the timer hook code.

    monitorPin() and GPIN_HOOK are to slow, I think.

    Is it possible to get access to a interrupt-service-routine on INT0 or a timer of Atmega128RF?

    Do you have any suggestions to solve this problem, if it exists?


  • #2
    Oh, great - just what the world needed, yet another incompatible communications protocol...

    Defining your own ISR isn't an option, unfortunately. If you're going to read this device via a GPIO pin, then polling for the start bit is really your only option, and you'll have to live with the consequences of blocking the event loop for extended periods of time - poor wireless performance (not that wireless is 100% reliable even at the best of times), and inaccurate timing (your next HOOK_1S routine invocation will be well over 1 second away).

    However, there is another way - assuming that you have a free UART, you can use that to receive data from this device more or less autonomously. The basic idea is that you'd set the baud rate so that each low-going pulse from the device is seen as a start bit plus some small number of '0' data bits, a distinct number for each of the three pulse widths. If you set the UART buffering parameters correctly, you'd receive the 20 pulses of a single temperature reading as a 20-byte string, via a single call to your HOOK_STDIN routine. Decoding that would be within the capabilities of SNAPpy, no C required.

    A baud rate of 65535 looks like it would be nearly perfect for this. A ZACwire start bit would appear as about four UART '0' bits (start bit + 3 data bits), ZACwire '1' would be about two UART '0's, and ZACwire '0' would be about six UART '0's. These values would be read as (respective, in binary): 11111000, 11111110, and 11100000. However, the exact number of '0's will vary due to timing differences in the device (allowing the device to get by without an accurate clock is the whole point of the ZACwire protocol), so in practice you'd need to accept any value for the start bit, then treat any larger value as a '1' bit, and any smaller value as a '0' bit.

    Or, you could choose a temperature sensor that uses some standard interface such as SPI or I2C, rather than this weird proprietary crap.