Nested TRAP #3 I/O calls in SMSQ/E...

Anything QL Software or Programming Related.
Post Reply
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Nested TRAP #3 I/O calls in SMSQ/E...

Post by martyn_hill »

Hi everyone

Further to the on-going development of the QLAN to USB Bridge adapter (for emulators such as QPC), I am in the thick of researching how best to implement the calls to the Serial driver in SMSQ/E from _inside_ the (physical) NET IO driver. (and onwards to the microcontroller's USB/virtual COM Port.)

In principal, the design requires that prepared packets that were destined for the NET port, triggered by a NET I/O Trap #3 Access-layer call, jumping to what was the physical NET driver, but are now to be redirected to the SER driver for queuing to the SER/COM port.

I've read elsewhere about challenges in this area - whereby one Trap #3 call inside another upsets the OS - and have studied Martin Head's approach with his excellent IPNet suite (he calls the actual I/O vectors for the IP driver as extracted from the driver def/linkage block in place of Trap #3) and wonder what approach to adopt for this use-case.

I see two options and would welcome comment or alternatives, thus:
1. Adopt the approach of IPNet - extract the SER driver I/O vectors (test/fetch/putbyte) and call these directly, or
2. Stack the (NET) Channel ID, load A0 with the ID of an open STX Channel and Trap #3 with zero Timeout in D3 (to avoid the IOSS Retry getting tied in a knot upon ERR.NC)

Input most welcome!


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Nested TRAP #3 I/O calls in SMSQ/E...

Post by tofro »

Go with Martin Head's approach or

Go with your second approach and find it doesn't work, then go on as above ;)

Entering a device driver by a TRAP through another device driver access layer function from a TRAP simply doesn't seem to work for me at all in QDOS. In my experience, somehow the system manages to confuse the channel IDs and you end up sending something to the wrong channel. (I have tried something similar by calling a directory device driver from within another one)

The zero timeout you mention might work around the re-entrancy problem as such because it seems to be guaranteed to be atomic, but is most probably going to create other problems - What are you going to do on an err.nc from the inner driver?)

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Nested TRAP #3 I/O calls in SMSQ/E...

Post by martyn_hill »

Hi Tobias - and thanks very much for that!

As for handling ERR.NC from the SER driver Trap - I have designed the 'Message Queue' handling (that will sit alongside the SER driver as a scheduler-loop task to manage asynchronous replies from the uC - maintaining state of each open connection) to capture how many bytes are still to be sent from a 'client' (in this case, the NET Chan driver), block any other message/packets being initiated from other 'clients' to the STX queue and re-commence putting bytes in the queue upon the next IOSS retry from the (modified) NET driver Access layer. Its a bit complicated to explain :-)

I had also originally considered a third option; to simply store the STX queue header address and to use simple queue manipulation routines to put bytes in the queue directly - but after researching the SMSQ/E SER/PAR driver implementation - with its dynamic, linked Buffers - can't figure out how or whether this would work like it might have under the plain QDOS SER driver and its static 81-byte queues...

Part of the trouble with this important aspect of the project is that, the moment I resort to assembler routines (needed to interface with the NET driver), I leave my comfort-zone of easy fault-finding that my earlier testing in SBasic afforded me... So, I'm trying to get the design right from first-principals (generating lots of 'what-if?' questions and lots and lots of SMSQ/E source code analysis!)

I am not put-off, however and, one way or another, I'll get this beast fit for release!


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: Nested TRAP #3 I/O calls in SMSQ/E...

Post by Martin_Head »

Calling a TRAP#3 while in a TRAP#3 is a bit hit and miss.

I used that technique in the MDI/FDI drivers, and it seems to work fine.

I tried the same technique in the IPNet driver, and it did not work. I can't quite remember what happened... I think it worked OK in one direction, but not the other, getting a lot of corrupted/missing data. That is why I resorted to the technique of calling the I/O routines directly and bypassing the operating system.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: Nested TRAP #3 I/O calls in SMSQ/E...

Post by martyn_hill »

Thanks, Martin!

Time to try... I'll report back here at the other end of the weekend.

:-)


Post Reply