26 July 2024, 23:27 | #1 |
Registered User
Join Date: May 2022
Location: Canada
Posts: 143
|
Serial communication reliability
Hi coders, I am having some trouble trying to identify a rare random occurrence of a lost byte during serial communication, and I would like your lights and guidance.
Question 1) I often see code with a double-write to INTREQ to clear the relevant interrupt flag, for example in my serial receive buffer full interrupt routine, at the end: move.w #$0800, CHIP_BASE+INTREQ move.w #$0800, CHIP_BASE+INTREQ This appears to be apparently for "68040 compatibility": is that a fact or a myth? Question 2) The reason I am asking is to validate the tiny possibility that in between these two writes to INTREQ, would it be possible that another byte could have been received on the serial port, with this second write potentially clearing out the flag too soon. Since the interrupt code here didn't reach RTE yet, would the interrupt be ignored and lost? Question 3) Might be directly for Toni / WinUAE, but any insights would be appreciated: On WinUAE when testing two Amiga with a serial link connection (using the option -s win32.serial_port=INTERNAL_SERIAL), I saw in WinUAE code that when using this internal serial emulation, winUAE runs in "safe_receive" mode, which we can see it the function: static bool canreceive(void) { // don't replace data in SERDATR until interrupt is cleared in safe receive mode if (safe_receive) { if (intreq & (1 << 11)) { return false; } ... My question is, based on that behavior, if I understand properly, it should be "impossible" to lose a byte since WinUAE politely waits until INTREQ is cleared before injecting a new byte. I cannot explain would I seen to be losing a byte occasionnally. Perhaps it is on writing instead of receiving. But in order to diagnose better I would need to have a WinUAE compiled with SERIALDEBUG=2 probably :| Thanks! |
Yesterday, 13:06 | #2 |
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,652
|
1) yes, this is normally required if you clear intreq just before rte (see 2).. also add a nop after the intreq writes to make sure instructions execute in-order on 060 (otherwise it could 'rte' before the writes are commited to the bus.
2) I would try clearing intreq at the start of the isr in order not to miss interrupt requests that arrive while you process the interrupt.. so the very first thing to do in your isr is to read the received byte, then clear the intreq bit.. then probably also check if the irf is set again before exiting your isr, and process the byte there instead of having to fire the isr again immediately.. If your isr takes a bit of time, the double write to intreq is probably not needed then (as paula will have processed it before your isr reaches rte).. How much of an effect this change effectively has depends on the size/runtime of your isr, of course.. Edit: you can check for overrun using bit 15 in SERDATR, btw.. Last edited by hooverphonique; Yesterday at 21:48. |
Yesterday, 20:37 | #3 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,281
|
Quote:
I don't know exactly which models require the "double ack" (and can't find the thread right now unfortunately), but I'm pretty sure it's sufficient to EITHER ack int + nop OR ack int + do other custom reg access. I.e. it's not that first ack is lost, but rather RTE could exit too quickly and still see old (non-acked) IPL value. nop fully guaranteeing bus transfer is done or another custom access providing extra delay should both be fine. On my B1260/50 single ack + RTE works 100% of the time. @OP: One thing to note is that despite WinUAE generally working very well, I found that it didn't behave similar enough to a real machine when debugging corner cases of "high speed" serial transfer (maybe things have improved or my setup was wrong) Also you mentioning interrupt routines and lost bytes makes me a bit suspicious. Are you sure the routine is called and completes in time? hooverphonique suggestion of monitoring of OVRUN is good. |
|
Yesterday, 21:21 | #4 | ||
ex. demoscener "Bigmama"
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,652
|
Quote:
Quote:
I know the ack isn't lost, I was just playing along with the OP's suggested way of overcoming this problem - I'm not sure just adding a nop between clearing the irf and rte is enough on the A4000 though.. |
||
Yesterday, 21:35 | #5 | |
Registered User
Join Date: Feb 2017
Location: Denmark
Posts: 1,281
|
Quote:
Probably whole NOP thing is cargo cult. I've just seen it a lot, and assumed it would fix it. 100% sure way should be to ack interrupt early, and ensure >2CCKs have passed before RTE - usually "free" by other work but double ack would work if interrupt routine isn't doing anything else. |
|
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Serial communication? | MickGyver | Coders. Blitz Basic | 4 | 10 April 2020 16:40 |
serial communication between Amiga and PC | TCH | support.Amiga Forever | 6 | 24 March 2020 00:00 |
CD32 Accelerator reliability .. | leonk | support.Hardware | 4 | 30 April 2019 19:35 |
Serial Port <--> Tablet: no communication | ral-clan | support.WinUAE | 0 | 02 February 2011 19:51 |
Supercars 2 communication screens | jotd | Retrogaming General Discussion | 11 | 04 December 2006 18:06 |
|
|