Frankenstein's Multi Port Serial (Based on JonnyMac's and Cluso99's Code)
Duane Degn
Posts: 10,588
In an attempt to understand the multi port serial driver developed by Jon McPhalen and Ray Rodrick, I butchered the code beyond recognition and then slowly put it back together.
The version attached to this comment is likely inferior to the versions previously published but I like this version since I understand it (at least the Spin portion).
One of the things I wanted to achieve with my program was to make the interface with the driver similar to previous multi port drivers used with the Propeller 1.
AddPort Method:
Rather than use the "OpenPort" methods to establish a half duplex port, I used the familiar "AddPort" method to add a full duplex port. Hopefully it's obvious the ports are numbered 0 to 7 rather than 0 to 15.
Child Object Access:
Clusso99 has already provided an example of using the serial driver from within a child object but I made my own example. The example attached can be used from a child object and from multiple cogs (provided appropriate lock methods are used).
Lock:
I added multiple methods to make it easier to set and clear locks. For example "Strs" starts the debug lock. "Stre" releases the lock once the string as been sent.
The methods "SLock" and "ELock" start and release (end) the lock without sending any characters.
The method "DebugCog" identifies the calling cog as part of setting the debug lock.
Here's some example output from the program:
`2: secondsActive = 1050
2: secondsActive = 1060
2: secondsActive = 1070
2: secondsActive = 1080`
Warning:
Most of the "PressToContinue" do not release the debug lock. You'll need to press a key to release the lock.
If there's a bunch of text in the PST terminal, press any non-menu key to refresh the menu.
A modified version of Clusso99's "Echo" method is included in the program. You'll need to press the "~" key to exit the echo portion of the program.
I reinvented the wheel multiple times in this program. Earlier versions likely had superior methods to perform the same task which my new methods perform. Again, this was about understanding the code more than anything else. I generally understand code I write better than the code written by others. (Even though though the original code was likely superior to my code.)
Lack of Documentation:
I wasn't very thorough about commenting the various methods. Sorry about that. I'll be glad to answer any questions about my changes here.
Summary:
I make no claim I made any improvements to the already existing objects. I made these changes mainly to make the interface similar to previous multi port drivers. These changes were made for myself but I thought others might want to see these changes as well.
Thank you JonnyMac and Clusso99 for bringing the multi port serial driver to the Propeller 2!
Comments
Duane,
I took a quick look at your mods. Congrats!
BTW I've changed the fundamentals to my multiserial drivers to be a general purpose formatter and the multiport serial driver is also self-contained.
I was playing around with your demo, it looks very nice and worked great. The best part is examining the code base behind it!
I'm looking for ways to improve my version of a multi-port object by reviewing the code behind others ideas. I also like the AddPort() method of adding new ports, I use a similar process in my code as that is what I have been using on the P1 4 port serial object and I like the simplicity of the port setup. I've been getting frustrated with my code as it isn't behaving well (I did get the transmit section working for a single port) and my lack of pasm knowledge make it harder to troubleshoot (although starting to use debug in Pnut helps a lot). What I liked about the original P1 code was that it was pretty self contained and didn't need any arrays/variables outside of the serial code base itself. That's the design that I have been working slowly towards.
I personally like the having buffer locations and buffer sizes specified by the calling object.
I frequently ran out of RAM on the P1 and I'd repurpose the PASM section of other drivers for stack space or OLED graphic buffers.
I hope I don't run out of RAM in my P2 projects but I like the option of assigning serial buffers to any arbitrary location in case I need to start repurposing PASM images again.
Thank you for taking time to look at the code.
Thanks. I used your code to as a starting point. Thanks for sharing your work with us.
Luckily I rarely ran out of memory space on the P1 but I can understand where you are coming from.
I'm taking a couple of ideas I got from looking at your code and am putting it in my code. So far I've managed to blow my code up so this is giving me a chance to try out debugging in the new version of Prop Tool. The new version is nice. Now back to figuring out what I'm doing wrong again!