All,
I'm willing to sort out a bit the RS232 libraries to answer to some direct question I got about using the RS232 on the Amstrad CPC, intergrate code portions I have, and perhaps set up an 'official' link to uIP (some of the informations I got for the TRS80 come from a uIP implementations made with SDCC).
I noticed that the current libraries are quite at a beginning stage (my code for the Interface 1 seems to be buggy, in example), so I'm trying to write a simple test program.
I'm not sure I'll go far with this because I have little time to test the real hardware (and it is probably a must), anyway.. is anybody needing particular features ?
misc points:
- Is the current API model good enough for all the target ports ? What about stop bits, mark/space, etc ?
- 75 baud speed is excluded from the baud options (probably we won't miss this one)
- The TRS80 related code should be easily recyclable from the uIP implementation
- Is ZSock relying on such functions ?
- I have an almost finished skeleton to support the CPC RS232 STI board, but they must be saparete libs to support the different HW standars.
- I think someone in this list has something interesting for the ZX81
- The ZX Inteface 1 code looks broken
- Is the parity/speed set up function working on Z88 ?
- very vew targets are supported so far
RS232 API
The rs232 model was inspired by that in cc65 - the idea being that it will make porting software easier. I think it should support most of the features that are needed for serial ports - certainly there's constants defined for stop bits etc.
ZSock doesn't use the rs232 API - I wrote zsock before importing rs232, I'm not sure if the speed stuff is working at all - normally on the z88 you set the serial settings from the config menu and apps use whatever settings are in place that way, so that might explain why everything is commented out
ZSock doesn't use the rs232 API - I wrote zsock before importing rs232, I'm not sure if the speed stuff is working at all - normally on the z88 you set the serial settings from the config menu and apps use whatever settings are in place that way, so that might explain why everything is commented out
I'd like to swallow up all these stream i/o devices into the low level file i/o model. If you are looking at changing things, maybe give some thought as well to how a low level file i/o system could handle serial, parallel, etc devices. Eg, data sources are opened with open or fopen and options set by ioctl or somesuch thing. I am just beginning to look at this myself and how the high level FILE model should interact with the low level model. Code to manage circular byte buffers will be added shortly and can be used to, eg, store data from an asynchronous source for retrieval by the low level file i/o, so it's also possible to look at nonblocking / blocking io from interrupt driven peripherals. This (interrupt vs polled) is something that should certainly be added to the rs232 model.
Little update: I put in the wiki section the test program I used to fix the Interface 1 libraries.
Searching on the net for informations I got plenty of drivers for different machines, noticing there are different techniques, including Interrupt driven code, buffered input and/or output, etc..
I'm thinking at making a generic driver for the Z80 SIO..
Searching on the net for informations I got plenty of drivers for different machines, noticing there are different techniques, including Interrupt driven code, buffered input and/or output, etc..
I'm thinking at making a generic driver for the Z80 SIO..