RS232 API

Other misc things
Post Reply
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

RS232 API

Post by stefano »

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
User avatar
dom
Well known member
Posts: 2076
Joined: Sun Jul 15, 2007 10:01 pm

Post by dom »

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
alvin
Well known member
Posts: 1872
Joined: Mon Jul 16, 2007 7:39 pm

Post by alvin »

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.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

Well, I'm still at the beginning of my investigations and at the moment I'm a little more oriented on the hardware side of the problem, so I think things can match.
As always I must admit that Dom chose a very good skeleton, by the way.
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

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..
stefano
Well known member
Posts: 2137
Joined: Mon Jul 16, 2007 7:39 pm

Post by stefano »

More news: Tim Riemann just sent me the drivers to run the CPC Booster+ with z88dk.
He says he's been able to run the test program at 115200 bps.
Post Reply