The uart.flush() method is helpful but waiting can be a drag when my device has other things to attend to. When using RS485 (as a master) it’s necessary to use an output for a TX Enable driver, hence I need to know when transmission is complete so I can drop the TX Enable and wait for a response. Has the Imp team considered a callback for when the transmit queue is empty?
Has been talked about as a lot of people are doing RS485. Will add a request.
One issue with a nonblocking approach is that if the imp gets stuck in a “slow” function somewhere you won’t get the transceiver back into receive mode and will miss any responses to the message.
Yes good point, it would be nice to know the worst case scenario for getting control back to squirrel when the transmit-buffer-empty interrupt is triggered. I know it was mentioned somewhere what priority squirrel code had over other services (but those pearls of wisedom are never handy when you want to refer to them). From what I can gather, imp.scanwifinetworks() is one of the chunkiest methods in the api, taking around 150ms!
Yes, scanning for wifi networks currently is foreground. It obviously will interrupt communication, as the radio has to visit every channel and listen for beacons…
This is a forum post I made a couple of years ago that I’m revisiting.
I’m still doing a hellava lot of 2wire RS485 comms (master and slave). Precise timing of the transmit driver is critical. At the moment, I’m setting the TX-enable high before a transmission, loading the tx buffer, and waiting until uart.flush() completes.
As my imps get busier, this waiting for uart.flush() results in a lot of idle time. Even though there’s a asynchronous mechanism to detect the end of transmission, I’ve found it’s not viable doe to the slow nature of squirrel execution. If I’m doing something involved, it could be many ms before I can set TX-enable low. I’m thinking of trying the PTPG feature to effect a more precise response.
- I would connect my UART TX (tx) to a digital input on the imp (txin)
- I would connect a PTPG output to the RS485 tx-enable driver (ptpg)
- I’d gate transmission like so: ptpg.configure(PTPG_OUT_ACTIVE_HIGH,txin,0,duration) where duration=width of serial frame (eg 1.05ms at 9600,8,N,1)
Is this feasible?
The beginning of the start-bit on tx (falling edge) must immediately trigger a rising edge on ptpg. Would subsequent states-changes on tx retrigger ptpg? Or not until duration has expired?
I want to avoid the following:
tx-enable goes low in the middle of a serial frame transmission.
tx-enable is held high for too long after a sequence of bytes is transmitted.
I could consider changing duration to equal the time to clock out all of the frames in sequence, but I’d have to be confident that the imp sends each frame back-to-back and I don’t know if it’s guaranteed to work that way.