Here is demo version v0.30 for the multiport serial driver. Two full duplex serial ports are configured.
As usual, please report bugs here.
[b]mpx_demo2.spin2[/b]
This is the top level (demo) program. It shows running two full duplex serial ports.
[b]mpx_fullduplexserial.spin2[/b]
This is the spin object that has the methods to drive one full duplex port (ie one transmitter and one receiver). However, it may be configured to only have a transmitter or a receiver, without wasting a port of the 16 total ports.
It supports transmit methods such as txChr, txStr, txDump, jonnymac's string handling methods, etc, and receive methods such as rxChr, rxStr, rxCheck, rxPeek, etc.
Multiple copies of this object may be used to support multiple serial ports.
[b]mpx_multiportserialdriver.spin2[/b]
This is the pasm driver that resides in its' own cog and supports a total of up to 16 single direction ports (ie transmit or recieve). Thus any combination of transmitters and receivers are possible with a maximum of 16 total.
[b]jm_nstr.spin2[/b]
JonnyMac's support object for converting numbers to strings. Called by mpx_fullduplexserial.spin2.
I be pleased if you could give this a look over when you get a chance.
My aim is to be able to utilise the general spin interface here and substitute the pasm driver cog for another (or in addition to) to support VGA, LCD, Keyboard, etc.
This code can also be used for the standard fullduplexserialserial supporting just a single tx/rx pair, as well as supporting multiple ports. It would be nice to be able to standardise on a single driver for P2.
Now contains demos for one, two and 8 full duplex ports (ie 2, 4 and 16 port/pins).
[b]mpx_demo2.spin2[/b]
One full duplex port demo
[b]mpx_demo4.spin2[/b]
Two full duplex ports demo
Demo requires pins 0 to 47 to be linked via a jumper wire (or change the code CON).
[b]mpx_demo16.spin2[/b]
Two full duplex ports demo
Demo requires pins 0 to 47, 1 to 46, thru to 6 to 41 to be linked via jumper wires (or change the code CON).
The demos receive characters received via pin 63 (rx) (ie the PC terminal program) and echoes them via any intervening configured ports if configured, and then back to pin 62 (tx) (ie the PC terminal program).
The demo for the 16x pin/ports now use the daisy chain, with characters received from serial pin 63 and send-receive via pins 3-2-5-4-7-6-9-8-11-10-13-12-15-14 and finally back to pin 63.
Thanks to Ken, we now have a Quick Bytes for this here...
On a slightly different note, I wonder if it still makes sense in Spin2 to include all the formatting routines (str, hex, decimal, etc.) in the serial port object. With the SEND function it's easy to use a seperate formatting object and then the same code can be re-used by multiple I/O objects (serial, hdmi, vga, and whatever). I suspect @JonnyMac has such a formatting object, but if not there's one I wrote called ers_fmt.
This was one of the P1 bug-bears. Multiple objects to basically do the same thing. Add to that, the methods had different names (eg tx(), txchar(), txout(), etc) for the same purpose.
Actually in my code, all the formatting routines are totally separate from the serial driver, which is in its' own pasm. The only portion that resides in the spin (formatting) object is the actual serial configuration setup, which is miniscule.
This is so I can replace the serial with VGA, LCD, Keyboard, or whatever. It only wastes 4 hub longs to do it this way. As it can handle multiple ports, it is possible to utilise the same object multiple times to cater for multiple I/O objects. So, it's only that I haven't released the other drivers yet.
So, yes, that is precisely my intention.
I don't quite follow how the SEND function can actually help? I don't need to replace any of the calls when changing the physical I/O. I just need to switch the ultimate driver(s) which only operate on the buffer(s).
@Cluso99 I didn't checked your driver code as yet, but now I have. So far it looks nice. I have some suggestions which would help to improve the driver and make the usage much easier.
1. Locate the port_control and port_params structure into mpx_fullduplexserial. So, one don't need to provide the pointer to the port_control on the start and openport method. There is no need to have these structures in the main program as these are the control structures of the serial driver.
Add a method getPortControl to get the pointer of this structure to hand over to the pasm driver in main program.
2. Provide method openTxPort and openRxPort and make the method openport private. This would avoid to have to use the parameter xdirn by the user and would show clearly in the main code what type of port will be opened.
3. It would be nice if the method openport would be figure out a free slot in the port_control structure by itself and return the index of the slot. It should return -1 if no slot is free.
This would avoid mistakes in the usage of the driver.
4. Refactor the method start (mpx_fullduplexserial) to simplify the usage of two consecutive pins for a duplex communication, so that only the even pin (for tx) must be provided and only one baud rate. Maybe the method should be renamed to openDuplexPort. This method would return two values for the index of slots which were occupied.
5. I would suggest to provide the buffer size instead of the pointer to the buffer end, which is in fact end + 1, in the start and openport method. Hence, you would have the calculation of the buffer end only in the driver instead of in the main program on each method call. This would also make look the method call as simple.
6. Do general refactor of start and openport method (would also apply to openTxPort and openRxPort). Do reorder the parameters of each method, so that the optional parameter feature can be used in the near future.
Currently you can check this feature only with FlexProp, e.g. with provided SmartSerial.spin located in directory include/spin. You can use the file samples/smartpin.spin to play with it or create your own. Please have also a look how this feature works at the printf method in std_text_routines.spinh which will be included in SmartSerial.
7. I would suggest to name a method the same if it performs mostly in the same manner like the widely known printf function in C instead of to name it fstr. I'm aware that this was the code from Jon. But it would be make the usage by a user much easier if one would see a widely known method in a Spin object.
Maybe that needs anyway some rework as Eric already suggested to have a universal formatting object which can be used with whatever driver.
Thanks for your comments. However, I think you miss a number of things that were done specifically to separate some parts from the driver, and the tx & rx methods, and the buffers. I'll try to give reasons for each comment.
1. Locate the port_control and port_params structure into mpx_fullduplexserial. So, one don't need to provide the pointer to the port_control on the start and openport method. There is no need to have these structures in the main program as these are the control structures of the serial driver.
Add a method getPortControl to get the pointer of this structure to hand over to the pasm driver in main program.
port_control and port_params structure have deliberately been placed into the calling program. The size of port_params need not be all 16 longs, and the caller needs to know this. If you look at the outputting-to-the-same-serial-port-from-different-objects thread you will see that I can insert the mpx_fullduplexserial object into a lower object and still use it fully. The only issue is that I don't have a method to set the port_param without setting up the serial port. I'm thinking about this.
I intend to use this as a common object that can be dynamically loaded without shutting down the serial driver, or killing the buffers. This will form part of my P2 OS.
2. Provide method openTxPort and openRxPort and make the method openport private. This would avoid to have to use the parameter xdirn by the user and would show clearly in the main code what type of port will be opened.
I'll take this on board.
3. It would be nice if the method openport would be figure out a free slot in the port_control structure by itself and return the index of the slot. It should return -1 if no slot is free.
This would avoid mistakes in the usage of the driver.
Not sure about this. Currently I'm of the opinion that the user should select the port (slot). It would require closeXxPort methods to be implemented.
4. Refactor the method start (mpx_fullduplexserial) to simplify the usage of two consecutive pins for a duplex communication, so that only the even pin (for tx) must be provided and only one baud rate. Maybe the method should be renamed to openDuplexPort. This method would return two values for the index of slots which were occupied.
Yes and no. Both pins must be specified. You cannot assume the rx pin is the next higher than the tx pin. Because the baud can be different, although unusual, both IMHO should be specified. I'm not really happy with the open/close method naming so open to suggestions. As I said, currently I'm requiring the ports to be specified.
5. I would suggest to provide the buffer size instead of the pointer to the buffer end, which is in fact end + 1, in the start and openport method. Hence, you would have the calculation of the buffer end only in the driver instead of in the main program on each method call. This would also make look the method call as simple.
I though long and hard about those 4 pointers. But they make the most sense to be the way they are because it makes it easy (and faster) to use them in the both the mpx_fullduplexserial "interface" object and the driver object which is much more important.
6. Do general refactor of start and openport method (would also apply to openTxPort and openRxPort). Do reorder the parameters of each method, so that the optional parameter feature can be used in the near future.
I'm sorry, but I don't believe in optional parameters. Period. I'm also unsure if Eric intends to implement this either.
7. I would suggest to name a method the same if it performs mostly in the same manner like the widely known printf function in C instead of to name it fstr. I'm aware that this was the code from Jon. But it would be make the usage by a user much easier if one would see a widely known method in a Spin object.
Maybe that needs anyway some rework as Eric already suggested to have a universal formatting object which can be used with whatever driver.
I'm not a C programmer and neither is Jon. Some of the naming is the same as P1, and some is partially reigned in to be more consistent. I've changed a number of them to have the tx and rx prefix. But I do want to remain as consistent as possible with Jon's driver as I hope he might choose to use this one so we can have a truly standard spin driver for P2. This is one of the reasons I want it to be multiport. I want to utilise the same interface no matter whether the driver is a serial driver of a VGA, HDMI, LCD, Keyboard, etc. It should be a matter of just substituting the pasm driver while keeping the interface driver the same. This is where I've been thinking of removing the actual open setup of the serial port_control to another object.
Remember where I'm coming from. I want to be able to keep the driver running, and the buffers in hub, while loading new programs. And, to be able to substitute on the fly the drivers to swap serial to vga to hdmi etc. My aim is an OS where the OS commands such as DIR, COPY, etc are actually separate binaries that load and execute while keeping the drivers (including SD) running in other cogs. I sort of achieved this, although no where near as far as I wanted, on my P1 OS.
1. Locate the port_control and port_params structure into mpx_fullduplexserial...
Cluso99 did respond:
port_control and port_params structure have deliberately been placed into the calling program. The size of port_params need not be all 16 longs, and the caller needs to know this. If you look at the outputting-to-the-same-serial-port-from-different-objects thread you will see that I can insert the mpx_fullduplexserial object into a lower object and still use it fully. The only issue is that I don't have a method to set the port_param without setting up the serial port. I'm thinking about this.
I intend to use this as a common object that can be dynamically loaded without shutting down the serial driver, or killing the buffers. This will form part of my P2 OS.
Kaio did respond:
I think the caller don't need to know the internal structures of the serial driver. It is not necessary for the caller to set or manipulate anything in these structures quite in contrary it could be result in trouble.
Only a buffer needs to be provided beside usual pin and baud rate per half duplex channel (I have omitted the pointers for buffer and mode here for simpleness).
How many slots/channels the driver has to support could be configured as well with an init method if you don't want to use a fix count as currently. But the pasm driver code is currently always fix.
Kaio suggested:
3. It would be nice if the method openport would be figure out a free slot in the port_control structure by itself and return the index of the slot. It should return -1 if no slot is free...
Cluso99 did respond:
Not sure about this. Currently I'm of the opinion that the user should select the port (slot). It would require closeXxPort methods to be implemented.
Kaio did respond:
There's no need for a special closeXxPort method as you have already a closeport method, which could be simplified too, and it would nevertheless know the slot as the variables are per instance of mpx_fullduplexserial. If this wouldn't be the case the whole driver would not work.
Kaio suggested:
4. Refactor the method start (mpx_fullduplexserial) to simplify the usage of two consecutive pins for a duplex communication, so that only the even pin (for tx) must be provided and only one baud rate...
Cluso99 did respond:
Yes and no. Both pins must be specified. You cannot assume the rx pin is the next higher than the tx pin. Because the baud can be different, although unusual, both IMHO should be specified. I'm not really happy with the open/close method naming so open to suggestions. As I said, currently I'm requiring the ports to be specified.
Kaio did respond:
Mostly a full-duplex serial driver was used in the past in this way as the order of the default tx and rx pin is the same on P1 and P2. Usually the baud rate is equal for a full-duplex communication as you agree.
If one want a reverse order of pins or different baud rates for tx and rx one can use two openport methods instead.
I'm fine with the names of openport and closeport method. That's a good way for half-duplex use.
Kaio suggested:
5. I would suggest to provide the buffer size instead of the pointer to the buffer end, which is in fact end + 1, in the start and openport method. ... This would also make look the method call as simple.
Cluso99 did respond:
I though long and hard about those 4 pointers. But they make the most sense to be the way they are because it makes it easy (and faster) to use them in the both the mpx_fullduplexserial "interface" object and the driver object which is much more important.
Kaio did respond:
I'm not against the 4 pointers at all. I suggested only to simplify the provided parameters on the start and openport method. If you would use the buffer size instead of the buffer end as parameter the method call will look much simple in the calling program. One could also use a default buffer size which is reasonable for most cases.
This would also reduce the code size in the calling program (which is mostly not an issue on the P2) as the calculation for buffer end is moved into the driver.
Kaio suggested:
6. ...Do reorder the parameters of each method, so that the optional parameter feature can be used in the near future.
I'm sorry, but I don't believe in optional parameters. Period. I'm also unsure if Eric intends to implement this either.
Kaio did respond:
You must not believe in optional parameters, they are reality. This feature is already supported by FlexProp as I was mention and probably will be supported by PropTool in some weeks. The same is realness for method pointers which are supported by both dev tools.
Kaio suggested:
7. I would suggest to name a method the same if it performs mostly in the same manner like the widely known printf function in C instead of to name it fstr...
Maybe that needs anyway some rework as Eric already suggested to have a universal formatting object which can be used with whatever driver.
Cluso99 did respond:
I'm not a C programmer and neither is Jon. Some of the naming is the same as P1, and some is partially reigned in to be more consistent. I've changed a number of them to have the tx and rx prefix. But I do want to remain as consistent as possible with Jon's driver as I hope he might choose to use this one so we can have a truly standard spin driver for P2.
...
Remember where I'm coming from. I want to be able to keep the driver running, and the buffers in hub, while loading new programs. And, to be able to substitute on the fly the drivers to swap serial to vga to hdmi etc. My aim is an OS where the OS commands such as DIR, COPY, etc are actually separate binaries that load and execute while keeping the drivers (including SD) running in other cogs. I sort of achieved this, although no where near as far as I wanted, on my P1 OS.
Kaio did respond:
I understand that you don't want change Jon's code interface too much and I appreciate your work you have done so far for this driver. But it looks like that we will end with a version which will fit perfectly with your Prop OS and not in a better solution for use cases of all users as "a truly standard spin driver for P2".
It's not a problem for me if you would admit that you think that my suggestions are not suitable for you. I promise you I will not go the same way as you was going and will not initiate the next multiport serial driver thread. But maybe I will go a better way.
@Cluso99 : SEND is a very nice feature. For example, to use your serial port driver and some hypothetical VGA driver together with my formatting object you'd do something like:
obj
ser: "mpx_fullduplexserial"
vga: "some_vga_object"
fmt: "ers_fmt"
pub main()
' ... skip the usual setup stuff
' send the info out the serial port
send := @ser.txChr
send("Serial weather report", 13, 10)
send("The temperature is ", fmt.dec(degrees), " and the humidity is ", fmt.dec(humidvar), 13, 10)
' now do the same thing on VGA
send := @vga.putChar
send("VGA weather report, in hex", 13, 10)
send("The temperature is $", fmt.hex(degrees), 13, 10)
send("Probably you wanted decimal:", fmt.dec(degrees))
The nice thing about this is that you don't need to wrap literal strings in string("stuff"). You can mix strings with decimal, hex, and other kinds of output formats. The whole thing is driven by the SEND method pointer which just takes one character in and outputs it. And we only need one copy of the formatting functions: the VGA and serial routines don't need to send strings, numbers, or anything else, just one single character. So they all benefit from improvements or additions to the format object, and we only have one copy of that object in memory.
thats more complex than it needs to be. In my use, just the pasm driver program changes. This can be achieved without the binary knowing by merely loading a new driver binary into a cog. That’s how I do it on P1, well it was the intention because I didn’t actually complete it fully. You just change the pasm object from serial to vga etc. it’s not there yet but that’s the idea.
My P1 OS has all I/O (character, not files) go via a hub mailbox. This allows total redirection without recompiling.
SEND only operates per object. AFAIK it’s not possible to have every object that outputs to the same port# to have that changed by just substituting the pasm cog driver. Essentially it’s the pasm cog that uses the port_params (which will ultimately be in a known fixed hub location) and uses this info to get/put characters from/to the buffer and output/input those to the serial/screen/etc.
perhaps another object level needs to be introduced. But it will take a lot of convincing to put it into the existing object. But you’re welcome to fork it and modify.
X
Agree to disagree for now. It’s early days.
P1 always gave both tx pin and rx pin.
Ok. Will do for next iteration.
IMHO optional parameters are the source of bugs unless you use xxxx = yyyyy which defeats the purpose. Agree to disagree.
Can you list the methods and alternative names with parameters? Unfortunately without knowing C I don’t know their methods.
In general, I’m trying to remain as backward compatible as possible to the P1 and to Jon’s code. This is spin, not C. There’s also python which is gaining a lot of traction and I use this every day at work although my focus isn’t using string formatting so I’m not even sure what’s available in the language.
I really liked Jon’s formatting methods. I would have preferred to use txfstrn() to be consistent but thought that was too much of a change to Jon’s interface. I do like the ‘n’ to indicate the number of parameters (substitutions). I guess here the optional number of parameters could be useful (sort of goes against my views).
I think going forward, a wrapper object to make a simple standard fdx interface might be in order.
@Cluso99 : How is SEND complicated? To switch output streams you just say
SEND = @tx_method
Easy peasy. I think that's a lot simpler than replacing a PASM driver :). But perhaps we're talking past one another. My understanding is that in order to use your framework with both VGA and serial simultaneously, you would end up with two copies of the format binary -- one for the serial, one for the VGA. The source code is the same, and that's a nice feature, but it still has to be loaded into memory.
What I gather from looking at your posts and code is that you're looking for a way to easily redirect one single output stream at run time; that is, depending on some run time configuration you load either the serial port PASM, or the VGA code PASM. That is a nice feature (it's cool that you can load the code at run time). But it's kind of orthogonal to the question of where the format code goes. It doesn't have to go in the output driver at all. We can have one generic formatter that works with any driver, even multiple ones at the same time.
Also, of course, SEND is the "offical" Spin2 way to do this kind of redirection, so if we want to be compatible with what Chip's doing it probably makes sense to use it.
No. Only one object is loaded. The pasm driver could be replaced via a different binary running on a different cog. The whole idea is that the one formatting object is loaded, even when used as multiple objects. I don’t think I’m missing anything here.
yes, redirecting at runtime, even during runtime. It he formatting code is not in the output driver object at all. The formatting object only puts/takes characters from a hub buffer. The driver(s) then take/put characters from the buffer autonomously. Neither really know anything about the other. This is where indirection takes place.
SEND cannot help here - this just confuses things. IMHO It’s a solution to a misunderstanding of the actual problem because the formatting object hasn’t been disconnected from the driver.
"No. Only one object is loaded. The pasm driver could be replaced via a different binary running on a different cog. The whole idea is that the one formatting object is loaded, even when used as multiple objects. I don’t think I’m missing anything here."
My apologies, I was looking at the wrong object. No, you're not missing anything here (that I know of) -- it does look like a different COG could control some of the ports, although you'd have to set up some kind of standard for which cog controls which port.
My point about SEND still stands though -- you don't need any of the formatting code in your multi-port object, you just need tx() and rx(). Spin2 already has a standard way to hook these functions up to anything you want. I think disconnecting the formatting object from the driver is a good idea, it makes things more modular and allows interesting drivers that don't even use a COG and have completely different internals to yours. There's an awful lot of wheel re-invention that goes on here (and there always has been :( ).
Different drivers only need to know about the relevant set(s) of 4 longs for the buffer pointers. There may be extra bytes/longs if the driver needs something additional. For instance, my multi port serial driver uses an extra 16 bytes that each contain a flag bit to indicate if the driver needs to service that tx/rx port. By reading the whole 16 bytes as 4 longs with setq it’s really fast to read the config from hub. The 64 port driver uses 64 bytes and reads them as 16 longs with setq. Each 4 bytes can be tested in one mov ... wz instruction which is also fast. I believe this can be improved but it’s good enough. I also expect I’ll do a single port fdx version too.
You’re absolutely right there is a lot of reinvention going on. I don’t really know how to avoid it. I’ve already had to dump the ROM monitor/debugger and SD driver because spin2 decided to use the register block I had used. Then Chip’s debugger overwrote it. Same with TAQOZ. You have the same problem rehanging the compiler to remain compatible with pnut/PropTool.
i tried to be as compatible as possible with Jonnymac’s serial driver in the hope that it might replace Jon’s driver because it’s a superset with minimal call changes (some method names add the tx prefix in attempt to be more consistent).
FWIW for my use, the port_control, port_params and buffers will be in a fixed hub location in upper hub ram perhaps just below the 16KB debug stuff (ie <496KB).
I’m going to post this before I lose it! Just had the forum lockup my iPad for more than 5 minutes!
I’m interested to know what formatting is present in fastspin. I guess it’s specific to fastspin tho ie not in spin?
OT I’m interested in what you have for SD file access? I have Kye’s FAT32 working with my raw SD pasm driver (again decoupled to initialise and read and write a sector). Even tho it’s done, I’m still curious to know if it might be a better alternative??? Could we make it work in pnut/PropTool?
@Cluso99: Yes, I like how you've set up the drivers to use generic buffers, and to use a different driver they just need to know the buffer. But not all drivers will even need buffers in HUB memory, and not all drivers will need another COG (some might want to just run in the current COG). Anyway, it's not a big deal, your code isn't incompatible with SEND, it's just that the formatting may be redundant.
"I'm interested to know what formatting is present in fastspin"
Nothing specific in Spin2, just a subset of Chip's DEBUG stuff. In C and BASIC there are some built in formatting methods (printf and print using, respectively). I suppose I could make those visible to Spin2, but I think it's better to just stick with objects for that.
As for SD file access, again there's nothing built in for Spin2, but C and BASIC have standard I/O routines that work with either the host file system on the PC or with the SD card. You use the "mount" system call to give a name to a file system and then use the appropriate standard library routines for the language e.g. in C you can do:
mount("/sd", _vfs_open_sdcard()); // give the name "/sd" to the SD card
f = fopen("/sd/myfile.txt", "w"); // open a file on the SD card for writing
I haven't looked at the library code, but couldn't a mountpins function be defined that allows specifying the SD pins? I understand that you added command-line parameters to do this, but a run-time function would be useful also.
For SD access in C, could this be compiled into a binary object that could be callable from spin with some defined jump table or anything else? Might not be worth the trouble, but I just have no idea if it’s possible, or the work involved.
I’m not sure what reference Kye used for his FAT32. I added a couple of missing methods eg find the sector start of a file.
What would be really nice to work out some way to mix spin, pasm and C. Perhaps C could run in a different cog. Or even use RISCV to get there???
I am mindful that introducing C into the mix uses a lot of hub memory, even for anything simple.
I've been working on my next driver, an LCD Driver that can be substituted for the multiportserial driver.
Of course this has thrown up a couple of problems that I hadn't quite considered and hence catered for, while still using the fullduplexserial ("fdx") object (the one that does the formatting). The updated routines will work for both so that's the good part.
First, the fdx object needs an open method (or modified open method) that optionally does not configure the port_control and the smart pins. The port_control is specific to serial ports. The port-params block can and will still be utilised, and remains unchanged.
Second, the lcd driver probably needs some additional configuration parameters such as foreground and background colors, screen size in pixels as it would be good to support multiple sizes that utilise the same driver chips.
@ersmith
For SD access in C, could this be compiled into a binary object that could be callable from spin with some defined jump table or anything else? Might not be worth the trouble, but I just have no idea if it’s possible, or the work involved.
I assume by "spin" you mean "Chip's interpreter" (since calling it from spin in a FlexProp context is trivial). I suppose you could make a binary blob with a jump table. flexspin lets you compile to any fixed address, so you'd just have to pick an address outside of anything the spin2 interpreter is using.
What would be really nice to work out some way to mix spin, pasm and C.
Comments
Hope to have a multi port demo in the next few days
The driver section works, so just need to split the caller into better easier to use objects.
By using this interface concept, it is now relatively easy to substitute the driver with a VGA + Keyboard driver, or HDMI, or LCD, etc.
Here is demo version v0.30 for the multiport serial driver. Two full duplex serial ports are configured.
As usual, please report bugs here.
[b]mpx_demo2.spin2[/b]
This is the top level (demo) program. It shows running two full duplex serial ports.
[b]mpx_fullduplexserial.spin2[/b]
This is the spin object that has the methods to drive one full duplex port (ie one transmitter and one receiver). However, it may be configured to only have a transmitter or a receiver, without wasting a port of the 16 total ports.
It supports transmit methods such as txChr, txStr, txDump, jonnymac's string handling methods, etc, and receive methods such as rxChr, rxStr, rxCheck, rxPeek, etc.
Multiple copies of this object may be used to support multiple serial ports.
[b]mpx_multiportserialdriver.spin2[/b]
This is the pasm driver that resides in its' own cog and supports a total of up to 16 single direction ports (ie transmit or recieve). Thus any combination of transmitters and receivers are possible with a maximum of 16 total.
[b]jm_nstr.spin2[/b]
JonnyMac's support object for converting numbers to strings. Called by mpx_fullduplexserial.spin2.
@JonnyMac
I be pleased if you could give this a look over when you get a chance.
My aim is to be able to utilise the general spin interface here and substitute the pasm driver cog for another (or in addition to) to support VGA, LCD, Keyboard, etc.
This code can also be used for the standard fullduplexserialserial supporting just a single tx/rx pair, as well as supporting multiple ports. It would be nice to be able to standardise on a single driver for P2.
Here is v031 - now works with flexspin and pnut
Now contains demos for one, two and 8 full duplex ports (ie 2, 4 and 16 port/pins).
[b]mpx_demo2.spin2[/b]
One full duplex port demo
[b]mpx_demo4.spin2[/b]
Two full duplex ports demo
Demo requires pins 0 to 47 to be linked via a jumper wire (or change the code CON).
[b]mpx_demo16.spin2[/b]
Two full duplex ports demo
Demo requires pins 0 to 47, 1 to 46, thru to 6 to 41 to be linked via jumper wires (or change the code CON).
The demos receive characters received via pin 63 (rx) (ie the PC terminal program) and echoes them via any intervening configured ports if configured, and then back to pin 62 (tx) (ie the PC terminal program).
Here is V0.40 :)
Minor tweeks to the code.
The demo for the 16x pin/ports now use the daisy chain, with characters received from serial pin 63 and send-receive via pins 3-2-5-4-7-6-9-8-11-10-13-12-15-14 and finally back to pin 63.
Thanks to Ken, we now have a Quick Bytes for this here...
Post any bugs here please.
Enjoy :)
I have posted another version that allows multiple objects within the same cog to output to the same serial port concurrently here
@Cluso99 : This looks very nice.
On a slightly different note, I wonder if it still makes sense in Spin2 to include all the formatting routines (str, hex, decimal, etc.) in the serial port object. With the SEND function it's easy to use a seperate formatting object and then the same code can be re-used by multiple I/O objects (serial, hdmi, vga, and whatever). I suspect @JonnyMac has such a formatting object, but if not there's one I wrote called ers_fmt.
Thanks Eric.
This was one of the P1 bug-bears. Multiple objects to basically do the same thing. Add to that, the methods had different names (eg tx(), txchar(), txout(), etc) for the same purpose.
Actually in my code, all the formatting routines are totally separate from the serial driver, which is in its' own pasm. The only portion that resides in the spin (formatting) object is the actual serial configuration setup, which is miniscule.
This is so I can replace the serial with VGA, LCD, Keyboard, or whatever. It only wastes 4 hub longs to do it this way. As it can handle multiple ports, it is possible to utilise the same object multiple times to cater for multiple I/O objects. So, it's only that I haven't released the other drivers yet.
So, yes, that is precisely my intention.
I don't quite follow how the SEND function can actually help? I don't need to replace any of the calls when changing the physical I/O. I just need to switch the ultimate driver(s) which only operate on the buffer(s).
@Cluso99 I didn't checked your driver code as yet, but now I have. So far it looks nice. I have some suggestions which would help to improve the driver and make the usage much easier.
1. Locate the port_control and port_params structure into mpx_fullduplexserial. So, one don't need to provide the pointer to the port_control on the start and openport method. There is no need to have these structures in the main program as these are the control structures of the serial driver.
Add a method getPortControl to get the pointer of this structure to hand over to the pasm driver in main program.
2. Provide method openTxPort and openRxPort and make the method openport private. This would avoid to have to use the parameter xdirn by the user and would show clearly in the main code what type of port will be opened.
3. It would be nice if the method openport would be figure out a free slot in the port_control structure by itself and return the index of the slot. It should return -1 if no slot is free.
This would avoid mistakes in the usage of the driver.
4. Refactor the method start (mpx_fullduplexserial) to simplify the usage of two consecutive pins for a duplex communication, so that only the even pin (for tx) must be provided and only one baud rate. Maybe the method should be renamed to openDuplexPort. This method would return two values for the index of slots which were occupied.
5. I would suggest to provide the buffer size instead of the pointer to the buffer end, which is in fact end + 1, in the start and openport method. Hence, you would have the calculation of the buffer end only in the driver instead of in the main program on each method call. This would also make look the method call as simple.
6. Do general refactor of start and openport method (would also apply to openTxPort and openRxPort). Do reorder the parameters of each method, so that the optional parameter feature can be used in the near future.
https://forums.parallax.com/discussion/172715/request-vote-for-optional-parameters-on-methods-in-spin
Currently you can check this feature only with FlexProp, e.g. with provided SmartSerial.spin located in directory include/spin. You can use the file samples/smartpin.spin to play with it or create your own. Please have also a look how this feature works at the printf method in std_text_routines.spinh which will be included in SmartSerial.
7. I would suggest to name a method the same if it performs mostly in the same manner like the widely known printf function in C instead of to name it fstr. I'm aware that this was the code from Jon. But it would be make the usage by a user much easier if one would see a widely known method in a Spin object.
Maybe that needs anyway some rework as Eric already suggested to have a universal formatting object which can be used with whatever driver.
What do you think about that?
@Kaio
Thanks for your comments. However, I think you miss a number of things that were done specifically to separate some parts from the driver, and the tx & rx methods, and the buffers. I'll try to give reasons for each comment.
1. Locate the port_control and port_params structure into mpx_fullduplexserial. So, one don't need to provide the pointer to the port_control on the start and openport method. There is no need to have these structures in the main program as these are the control structures of the serial driver.
Add a method getPortControl to get the pointer of this structure to hand over to the pasm driver in main program.
port_control and port_params structure have deliberately been placed into the calling program. The size of port_params need not be all 16 longs, and the caller needs to know this. If you look at the outputting-to-the-same-serial-port-from-different-objects thread you will see that I can insert the mpx_fullduplexserial object into a lower object and still use it fully. The only issue is that I don't have a method to set the port_param without setting up the serial port. I'm thinking about this.
I intend to use this as a common object that can be dynamically loaded without shutting down the serial driver, or killing the buffers. This will form part of my P2 OS.
2. Provide method openTxPort and openRxPort and make the method openport private. This would avoid to have to use the parameter xdirn by the user and would show clearly in the main code what type of port will be opened.
I'll take this on board.
3. It would be nice if the method openport would be figure out a free slot in the port_control structure by itself and return the index of the slot. It should return -1 if no slot is free.
This would avoid mistakes in the usage of the driver.
Not sure about this. Currently I'm of the opinion that the user should select the port (slot). It would require closeXxPort methods to be implemented.
4. Refactor the method start (mpx_fullduplexserial) to simplify the usage of two consecutive pins for a duplex communication, so that only the even pin (for tx) must be provided and only one baud rate. Maybe the method should be renamed to openDuplexPort. This method would return two values for the index of slots which were occupied.
Yes and no. Both pins must be specified. You cannot assume the rx pin is the next higher than the tx pin. Because the baud can be different, although unusual, both IMHO should be specified. I'm not really happy with the open/close method naming so open to suggestions. As I said, currently I'm requiring the ports to be specified.
5. I would suggest to provide the buffer size instead of the pointer to the buffer end, which is in fact end + 1, in the start and openport method. Hence, you would have the calculation of the buffer end only in the driver instead of in the main program on each method call. This would also make look the method call as simple.
I though long and hard about those 4 pointers. But they make the most sense to be the way they are because it makes it easy (and faster) to use them in the both the mpx_fullduplexserial "interface" object and the driver object which is much more important.
6. Do general refactor of start and openport method (would also apply to openTxPort and openRxPort). Do reorder the parameters of each method, so that the optional parameter feature can be used in the near future.
https://forums.parallax.com/discussion/172715/request-vote-for-optional-parameters-on-methods-in-spin
I'm sorry, but I don't believe in optional parameters. Period. I'm also unsure if Eric intends to implement this either.
7. I would suggest to name a method the same if it performs mostly in the same manner like the widely known printf function in C instead of to name it fstr. I'm aware that this was the code from Jon. But it would be make the usage by a user much easier if one would see a widely known method in a Spin object.
Maybe that needs anyway some rework as Eric already suggested to have a universal formatting object which can be used with whatever driver.
I'm not a C programmer and neither is Jon. Some of the naming is the same as P1, and some is partially reigned in to be more consistent. I've changed a number of them to have the tx and rx prefix. But I do want to remain as consistent as possible with Jon's driver as I hope he might choose to use this one so we can have a truly standard spin driver for P2. This is one of the reasons I want it to be multiport. I want to utilise the same interface no matter whether the driver is a serial driver of a VGA, HDMI, LCD, Keyboard, etc. It should be a matter of just substituting the pasm driver while keeping the interface driver the same. This is where I've been thinking of removing the actual open setup of the serial port_control to another object.
Remember where I'm coming from. I want to be able to keep the driver running, and the buffers in hub, while loading new programs. And, to be able to substitute on the fly the drivers to swap serial to vga to hdmi etc. My aim is an OS where the OS commands such as DIR, COPY, etc are actually separate binaries that load and execute while keeping the drivers (including SD) running in other cogs. I sort of achieved this, although no where near as far as I wanted, on my P1 OS.
Your thoughts?
@Cluso99
Kaio suggested:
1. Locate the port_control and port_params structure into mpx_fullduplexserial...
Cluso99 did respond:
port_control and port_params structure have deliberately been placed into the calling program. The size of port_params need not be all 16 longs, and the caller needs to know this. If you look at the outputting-to-the-same-serial-port-from-different-objects thread you will see that I can insert the mpx_fullduplexserial object into a lower object and still use it fully. The only issue is that I don't have a method to set the port_param without setting up the serial port. I'm thinking about this.
I intend to use this as a common object that can be dynamically loaded without shutting down the serial driver, or killing the buffers. This will form part of my P2 OS.
Kaio did respond:
I think the caller don't need to know the internal structures of the serial driver. It is not necessary for the caller to set or manipulate anything in these structures quite in contrary it could be result in trouble.
Only a buffer needs to be provided beside usual pin and baud rate per half duplex channel (I have omitted the pointers for buffer and mode here for simpleness).
How many slots/channels the driver has to support could be configured as well with an init method if you don't want to use a fix count as currently. But the pasm driver code is currently always fix.
Kaio suggested:
3. It would be nice if the method openport would be figure out a free slot in the port_control structure by itself and return the index of the slot. It should return -1 if no slot is free...
Cluso99 did respond:
Not sure about this. Currently I'm of the opinion that the user should select the port (slot). It would require closeXxPort methods to be implemented.
Kaio did respond:
There's no need for a special closeXxPort method as you have already a closeport method, which could be simplified too, and it would nevertheless know the slot as the variables are per instance of mpx_fullduplexserial. If this wouldn't be the case the whole driver would not work.
Kaio suggested:
4. Refactor the method start (mpx_fullduplexserial) to simplify the usage of two consecutive pins for a duplex communication, so that only the even pin (for tx) must be provided and only one baud rate...
Cluso99 did respond:
Yes and no. Both pins must be specified. You cannot assume the rx pin is the next higher than the tx pin. Because the baud can be different, although unusual, both IMHO should be specified. I'm not really happy with the open/close method naming so open to suggestions. As I said, currently I'm requiring the ports to be specified.
Kaio did respond:
Mostly a full-duplex serial driver was used in the past in this way as the order of the default tx and rx pin is the same on P1 and P2. Usually the baud rate is equal for a full-duplex communication as you agree.
If one want a reverse order of pins or different baud rates for tx and rx one can use two openport methods instead.
I'm fine with the names of openport and closeport method. That's a good way for half-duplex use.
Kaio suggested:
5. I would suggest to provide the buffer size instead of the pointer to the buffer end, which is in fact end + 1, in the start and openport method. ... This would also make look the method call as simple.
Cluso99 did respond:
I though long and hard about those 4 pointers. But they make the most sense to be the way they are because it makes it easy (and faster) to use them in the both the mpx_fullduplexserial "interface" object and the driver object which is much more important.
Kaio did respond:
I'm not against the 4 pointers at all. I suggested only to simplify the provided parameters on the start and openport method. If you would use the buffer size instead of the buffer end as parameter the method call will look much simple in the calling program. One could also use a default buffer size which is reasonable for most cases.
This would also reduce the code size in the calling program (which is mostly not an issue on the P2) as the calculation for buffer end is moved into the driver.
Kaio suggested:
6. ...Do reorder the parameters of each method, so that the optional parameter feature can be used in the near future.
https://forums.parallax.com/discussion/172715/request-vote-for-optional-parameters-on-methods-in-spin
Cluso99 did respond:
I'm sorry, but I don't believe in optional parameters. Period. I'm also unsure if Eric intends to implement this either.
Kaio did respond:
You must not believe in optional parameters, they are reality. This feature is already supported by FlexProp as I was mention and probably will be supported by PropTool in some weeks. The same is realness for method pointers which are supported by both dev tools.
Kaio suggested:
7. I would suggest to name a method the same if it performs mostly in the same manner like the widely known printf function in C instead of to name it fstr...
Maybe that needs anyway some rework as Eric already suggested to have a universal formatting object which can be used with whatever driver.
Cluso99 did respond:
I'm not a C programmer and neither is Jon. Some of the naming is the same as P1, and some is partially reigned in to be more consistent. I've changed a number of them to have the tx and rx prefix. But I do want to remain as consistent as possible with Jon's driver as I hope he might choose to use this one so we can have a truly standard spin driver for P2.
...
Remember where I'm coming from. I want to be able to keep the driver running, and the buffers in hub, while loading new programs. And, to be able to substitute on the fly the drivers to swap serial to vga to hdmi etc. My aim is an OS where the OS commands such as DIR, COPY, etc are actually separate binaries that load and execute while keeping the drivers (including SD) running in other cogs. I sort of achieved this, although no where near as far as I wanted, on my P1 OS.
Kaio did respond:
I understand that you don't want change Jon's code interface too much and I appreciate your work you have done so far for this driver. But it looks like that we will end with a version which will fit perfectly with your Prop OS and not in a better solution for use cases of all users as "a truly standard spin driver for P2".
It's not a problem for me if you would admit that you think that my suggestions are not suitable for you. I promise you I will not go the same way as you was going and will not initiate the next multiport serial driver thread. But maybe I will go a better way.
@Cluso99 : SEND is a very nice feature. For example, to use your serial port driver and some hypothetical VGA driver together with my formatting object you'd do something like:
obj ser: "mpx_fullduplexserial" vga: "some_vga_object" fmt: "ers_fmt" pub main() ' ... skip the usual setup stuff ' send the info out the serial port send := @ser.txChr send("Serial weather report", 13, 10) send("The temperature is ", fmt.dec(degrees), " and the humidity is ", fmt.dec(humidvar), 13, 10) ' now do the same thing on VGA send := @vga.putChar send("VGA weather report, in hex", 13, 10) send("The temperature is $", fmt.hex(degrees), 13, 10) send("Probably you wanted decimal:", fmt.dec(degrees))The nice thing about this is that you don't need to wrap literal strings in string("stuff"). You can mix strings with decimal, hex, and other kinds of output formats. The whole thing is driven by the SEND method pointer which just takes one character in and outputs it. And we only need one copy of the formatting functions: the VGA and serial routines don't need to send strings, numbers, or anything else, just one single character. So they all benefit from improvements or additions to the format object, and we only have one copy of that object in memory.
@ersmith
thats more complex than it needs to be. In my use, just the pasm driver program changes. This can be achieved without the binary knowing by merely loading a new driver binary into a cog. That’s how I do it on P1, well it was the intention because I didn’t actually complete it fully. You just change the pasm object from serial to vga etc. it’s not there yet but that’s the idea.
My P1 OS has all I/O (character, not files) go via a hub mailbox. This allows total redirection without recompiling.
SEND only operates per object. AFAIK it’s not possible to have every object that outputs to the same port# to have that changed by just substituting the pasm cog driver. Essentially it’s the pasm cog that uses the port_params (which will ultimately be in a known fixed hub location) and uses this info to get/put characters from/to the buffer and output/input those to the serial/screen/etc.
@Kaio
In general, I’m trying to remain as backward compatible as possible to the P1 and to Jon’s code. This is spin, not C. There’s also python which is gaining a lot of traction and I use this every day at work although my focus isn’t using string formatting so I’m not even sure what’s available in the language.
I really liked Jon’s formatting methods. I would have preferred to use txfstrn() to be consistent but thought that was too much of a change to Jon’s interface. I do like the ‘n’ to indicate the number of parameters (substitutions). I guess here the optional number of parameters could be useful (sort of goes against my views).
I think going forward, a wrapper object to make a simple standard fdx interface might be in order.
@Cluso99 : How is SEND complicated? To switch output streams you just say
SEND = @tx_method
Easy peasy. I think that's a lot simpler than replacing a PASM driver :). But perhaps we're talking past one another. My understanding is that in order to use your framework with both VGA and serial simultaneously, you would end up with two copies of the format binary -- one for the serial, one for the VGA. The source code is the same, and that's a nice feature, but it still has to be loaded into memory.
What I gather from looking at your posts and code is that you're looking for a way to easily redirect one single output stream at run time; that is, depending on some run time configuration you load either the serial port PASM, or the VGA code PASM. That is a nice feature (it's cool that you can load the code at run time). But it's kind of orthogonal to the question of where the format code goes. It doesn't have to go in the output driver at all. We can have one generic formatter that works with any driver, even multiple ones at the same time.
Also, of course, SEND is the "offical" Spin2 way to do this kind of redirection, so if we want to be compatible with what Chip's doing it probably makes sense to use it.
@ersmith
No. Only one object is loaded. The pasm driver could be replaced via a different binary running on a different cog. The whole idea is that the one formatting object is loaded, even when used as multiple objects. I don’t think I’m missing anything here.
yes, redirecting at runtime, even during runtime. It he formatting code is not in the output driver object at all. The formatting object only puts/takes characters from a hub buffer. The driver(s) then take/put characters from the buffer autonomously. Neither really know anything about the other. This is where indirection takes place.
SEND cannot help here - this just confuses things. IMHO It’s a solution to a misunderstanding of the actual problem because the formatting object hasn’t been disconnected from the driver.
@Cluso99:
"No. Only one object is loaded. The pasm driver could be replaced via a different binary running on a different cog. The whole idea is that the one formatting object is loaded, even when used as multiple objects. I don’t think I’m missing anything here."
My apologies, I was looking at the wrong object. No, you're not missing anything here (that I know of) -- it does look like a different COG could control some of the ports, although you'd have to set up some kind of standard for which cog controls which port.
My point about SEND still stands though -- you don't need any of the formatting code in your multi-port object, you just need tx() and rx(). Spin2 already has a standard way to hook these functions up to anything you want. I think disconnecting the formatting object from the driver is a good idea, it makes things more modular and allows interesting drivers that don't even use a COG and have completely different internals to yours. There's an awful lot of wheel re-invention that goes on here (and there always has been :( ).
@ersmith
Different drivers only need to know about the relevant set(s) of 4 longs for the buffer pointers. There may be extra bytes/longs if the driver needs something additional. For instance, my multi port serial driver uses an extra 16 bytes that each contain a flag bit to indicate if the driver needs to service that tx/rx port. By reading the whole 16 bytes as 4 longs with setq it’s really fast to read the config from hub. The 64 port driver uses 64 bytes and reads them as 16 longs with setq. Each 4 bytes can be tested in one mov ... wz instruction which is also fast. I believe this can be improved but it’s good enough. I also expect I’ll do a single port fdx version too.
You’re absolutely right there is a lot of reinvention going on. I don’t really know how to avoid it. I’ve already had to dump the ROM monitor/debugger and SD driver because spin2 decided to use the register block I had used. Then Chip’s debugger overwrote it. Same with TAQOZ. You have the same problem rehanging the compiler to remain compatible with pnut/PropTool.
i tried to be as compatible as possible with Jonnymac’s serial driver in the hope that it might replace Jon’s driver because it’s a superset with minimal call changes (some method names add the tx prefix in attempt to be more consistent).
FWIW for my use, the port_control, port_params and buffers will be in a fixed hub location in upper hub ram perhaps just below the 16KB debug stuff (ie <496KB).
I’m going to post this before I lose it! Just had the forum lockup my iPad for more than 5 minutes!
@ersmith
I’m interested to know what formatting is present in fastspin. I guess it’s specific to fastspin tho ie not in spin?
OT I’m interested in what you have for SD file access? I have Kye’s FAT32 working with my raw SD pasm driver (again decoupled to initialise and read and write a sector). Even tho it’s done, I’m still curious to know if it might be a better alternative??? Could we make it work in pnut/PropTool?
@Cluso99: Yes, I like how you've set up the drivers to use generic buffers, and to use a different driver they just need to know the buffer. But not all drivers will even need buffers in HUB memory, and not all drivers will need another COG (some might want to just run in the current COG). Anyway, it's not a big deal, your code isn't incompatible with SEND, it's just that the formatting may be redundant.
"I'm interested to know what formatting is present in fastspin"
Nothing specific in Spin2, just a subset of Chip's DEBUG stuff. In C and BASIC there are some built in formatting methods (printf and print using, respectively). I suppose I could make those visible to Spin2, but I think it's better to just stick with objects for that.
As for SD file access, again there's nothing built in for Spin2, but C and BASIC have standard I/O routines that work with either the host file system on the PC or with the SD card. You use the "mount" system call to give a name to a file system and then use the appropriate standard library routines for the language e.g. in C you can do:
mount("/sd", _vfs_open_sdcard()); // give the name "/sd" to the SD card
f = fopen("/sd/myfile.txt", "w"); // open a file on the SD card for writing
fprintf(f, "Hello, world!\n");
fclose(f);
I haven't looked at the library code, but couldn't a mountpins function be defined that allows specifying the SD pins? I understand that you added command-line parameters to do this, but a run-time function would be useful also.
@ersmith
For SD access in C, could this be compiled into a binary object that could be callable from spin with some defined jump table or anything else? Might not be worth the trouble, but I just have no idea if it’s possible, or the work involved.
I’m not sure what reference Kye used for his FAT32. I added a couple of missing methods eg find the sector start of a file.
What would be really nice to work out some way to mix spin, pasm and C. Perhaps C could run in a different cog. Or even use RISCV to get there???
I am mindful that introducing C into the mix uses a lot of hub memory, even for anything simple.
I've been working on my next driver, an LCD Driver that can be substituted for the multiportserial driver.
Of course this has thrown up a couple of problems that I hadn't quite considered and hence catered for, while still using the fullduplexserial ("fdx") object (the one that does the formatting). The updated routines will work for both so that's the good part.
First, the fdx object needs an open method (or modified open method) that optionally does not configure the port_control and the smart pins. The port_control is specific to serial ports. The port-params block can and will still be utilised, and remains unchanged.
Second, the lcd driver probably needs some additional configuration parameters such as foreground and background colors, screen size in pixels as it would be good to support multiple sizes that utilise the same driver chips.
FWIW over on the thread
New Generation of Low Level Driver for P2
https://forums.parallax.com/discussion/172849/new-generation-of-low-level-driver-for-p2/p1
I have realised that SEND and RECV does nothing for multiple ports. It can work for a single fdx port but there is no point in using it for multiple ports being used simultaneously
I assume by "spin" you mean "Chip's interpreter" (since calling it from spin in a FlexProp context is trivial). I suppose you could make a binary blob with a jump table. flexspin lets you compile to any fixed address, so you'd just have to pick an address outside of anything the spin2 interpreter is using.
It's called FlexProp
.
Latest code posted on this new thread
https://forums.parallax.com/discussion/172924/multiport-serial-lcd-text-drivers-with-common-format-i-o-object-similar-to-jm-fullduplexserial/p1?new=1