cserial

Dave Hein

I developed an enhanced version of FullDuplexSerial I call cserial.· It is part of CLIB, which is a C function·library written in spin.· I am trying to get some feedback on it before I post it to the OBEX.· cserial contains the following enhancements:

· - Multiple serial ports may be started from any object or cog
· - Any serial port is accessable from any object or cog using a device handle
· - Transmit and receiver buffers can be different sizes
· - Buffer sizes are defined by calling parameters
· - Mode bit 4 enables the use of a lock to make the transmit multi-cog safe

I included all of the old routines of FullDuplexSerial for compatibility, and I added new versions that require a device handle.· The new versions use the same name, but with a 1 added.· As an example, the new version of str is str1.

I have attached cserial.spin and·cserial_test.spin below.· Try it out and give me your suggestions.

Dave

pullmoll

Dave Hein said...
I developed an enhanced version of FullDuplexSerial I call cserial. It is part of CLIB, which is a C function library written in spin. I am trying to get some feedback on it before I post it to the OBEX.

Neat! It works for me! Changed the baudrate to 115k2 and all seems well. Being able to access the functions from any cog greatly simplifies debugging through it, or even applications. I'd like to try to use your code in yaz80's io handler instead of the default FDS object.

What escapes me is how you would handle several objects using different speeds or communication parameters over one serial line. I guess that's out of scope use [noparse]:)[/noparse]

Can I pretty please have an accessor function to the default handle for PASM use?

PUB get_handle1
return @data_struct

Juergen

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.

Post Edited (pullmoll) : 3/27/2010 4:25:42 AM GMT

Dave Hein

pullmoll said...

Neat! It works for me! Changed the baudrate to 115k2 and all seems well. Being able to access the functions from any cog greatly simplifies debugging through it, or even applications. I'd like to try to use your code in yaz80's io handler instead of the default FDS object.

What escapes me is how you would handle several objects using different speeds or communication parameters over one serial line. I guess that's out of scope use [noparse]:)[/noparse]

Can I pretty please have an accessor function to the default handle for PASM use?

PUB get_handle1
return @data_struct

Juergen,
I don't understand your comment about several objects using different speeds or communications parameters.· Do you want to change the baudrate without stopping and starting?· I thought about adding that feature.· What other parameters would you want to change?
There is a function called gethandle that returns the value of handle1.· However, handle1 is not set to @data_struct until the default serial port is opened.· And if start1 is used to start the first port, then handle1 will contain the addressed passed by start1.· Does that work for you, or would you rather have the address of data_struct before the port is opened?
Another question I have for everyone is about the address space.· cserial currently accomodates 16-bit addresses.· However, the Prop II will have a larger address space, so I am think of making the address pointers 32-bits instead.· The maximum size of the buffer is 64K each.· Would anybody ever need buffers larger than that on Prop II?
Dave

pullmoll

Dave Hein said...

Juergen,
I don't understand your comment about several objects using different speeds or communications parameters. Do you want to change the baudrate without stopping and starting? I thought about adding that feature. What other parameters would you want to change?

No, you got me wrong. That should be a joke, thus the smiley. Though you would need to specify communications parameters in every "file handle", you can't have two with different parameters in different cogs both using your cserial.

Dave Hein said...

There is a function called gethandle that returns the value of handle1. However, handle1 is not set to @data_struct until the default serial port is opened. And if start1 is used to start the first port, then handle1 will contain the addressed passed by start1. Does that work for you, or would you rather have the address of data_struct before the port is opened?

That is sufficient. I didn't realize that handle was the pointer to the struct.

Dave Hein said...

Another question I have for everyone is about the address space. cserial currently accomodates 16-bit addresses. However, the Prop II will have a larger address space, so I am think of making the address pointers 32-bits instead. The maximum size of the buffer is 64K each. Would anybody ever need buffers larger than that on Prop II?

When the PropII comes with larger address space, many objects will have to be rewritten as I see it. Some (or many) use a limited 16 bits field to address something in hub RAM. They could still get away with it if they ensure to be loaded first, i.e. stay in the first 64K of addressable memory. I don't think a buffer larger than a few hundred bytes is useful for serial I/O. What would you want to do with it? There has to be some foreground process actually handling the data and that should not be away for longer than perhaps a few seconds at most. At 115k2 baud this might overrun your buffers, but if your main is so slow, you have a problem anyway.

Juergen

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.

pullmoll

Okay, I'll be using cserial.spin from now on. I tested it in yaz80 CP/M and it works just fine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.