The code I posted three years ago was not intended to be a universal speed programmable model. It was a response to a need of "fastest serial ASCII link" that I had for an industrial application, and I just thought I would post it in case there was interest in the subject. There seemed to be none. Regrettably it also appears not to meet your requirements....... but luckily there are many others to choose from.
Cheers,
Peter (pjv)
Well I knew that you knew what you had written it for but I wanted to make sure that others also understood this as it was not made clear that this was a specialized serial driver much like Beau's high speed serial link. But we understand the problem with the hub access, if only the hub writes were at least latched then they could have been made fast and deterministic, assuming that the minimum cycle time was observed of course.
Peter (pjv), I recall looking at your code at the time and again now thanks to PJ's link. It is not that I didn't find it interesting. Quite the contrary, it is very tight and a good exercise to follow through your logic and timing. The problem for me and probably a lot of other people is that you eschew any involvement with spin apart from the necessary cognew. The code as it stands does nothing useful, although I am sure it was fleshed out with links to other pasm for your industrial application. It is not an object as most of us spinners would have it. I thought about making a command interface to it that would support a half-duplex scheme, something like,
PUB hub5Mbps(commandloc, bufferloc, buffercountloc, rxpin, txpin, timeoutms)
but that intention got lost in other business, and my slower conventional alternative does serve my purposes okay.
I think the nops you are seeing are simply part of the 3 Mbaud only hack (receive3) and not the general-purpose code (receive) which is limited to around 2 Mbaud max. At this speed trying to test for special end conditions etc would make the code unreliable however the code works reliably up to 2M baud without a hitch.
I think most links have control of the number of stop bits, so it could be useful to document the gains that might give.
Then there is the choice of local buffering, or hub buffering,
If local buffers can give a jump in speed, users may be able to work with that.
Seems there is a lot of spare local RAM in these examples.
Most USB transactions tend to be packet based anyway, and host SW is usually actually half duplex at the handling level.
The cheaper USB chips might allow higher nominal baud rates, but heir actual thruput, is lower.
You need to go to the FT232H/FT2232H series, (or another Prop) to get sustained mega-baud transfers.
To be truthful, I have not yet learned all the SPIN things needed to be proficient in that language, so I just continue writing my apps in assembler. I also need the speed of assembler, or at least that's what I tell myself. In fact when I posted that code three years ago, I included the comment that I'm SPIN challenged.
But since then I have been making significant advances with it, to the point where now I could provide the necessary or required SPIN wrappers. But again what would be the point if there is negligible interest.
You will also note that I had not posted that code, or any other for that matter, to the OBEX, realizing it was not a complete solution. And furthermore, as a commercial developer who makes his living selling software solutions, I have a problem with the whole OBEX-MIT thing anyways. I simply post these code tidbits for folks to realize that there generally ARE solutions to most problems. I just like to show some insight from my perspective.
Hopefully I can become a more prolific contributor to the forum in time to come.
I've also been lurking on a lot of the high-speed UART discussions. So far I've been able to work with 115200 baud serial for all my devices. That said, I'd use a 1Mbaud full duplex or 2Mbaud half-duplex driver if it existed.
Just for grins, I ported FFDS1 to a 2-cog solution, thus FFDS2. It seems to be able to do a minimum bit period of 18 clock, so 4.44 Mbps, with a single stop bit. It definitely needs more testing, though. The timing works great on a direct-pin-cog-to-cog controlled test, but may be too tight for something with optoisolators inline...we'll see.
Just for grins, I ported FFDS1 to a 2-cog solution, thus FFDS2. It seems to be able to do a minimum bit period of 18 clock, so 4.44 Mbps, with a single stop bit. It definitely needs more testing, though. The timing works great on a direct-pin-cog-to-cog controlled test, but may be too tight for something with optoisolators inline...we'll see.
Let me know if it works!
thanks,
Jonathan
Wow, old thread, sorry for reviving it from the grave, but I had to.. no one gave jon mad props...
IT WORKS! (and it retains the function rxtime() str(), plus more of fullduplexserialplus)
(thats been a big issue when people re-write serial drivers, no functions to make it backward compatible)
Comments
Well I knew that you knew what you had written it for but I wanted to make sure that others also understood this as it was not made clear that this was a specialized serial driver much like Beau's high speed serial link. But we understand the problem with the hub access, if only the hub writes were at least latched then they could have been made fast and deterministic, assuming that the minimum cycle time was observed of course.
PUB hub5Mbps(commandloc, bufferloc, buffercountloc, rxpin, txpin, timeoutms)
but that intention got lost in other business, and my slower conventional alternative does serve my purposes okay.
I think most links have control of the number of stop bits, so it could be useful to document the gains that might give.
Then there is the choice of local buffering, or hub buffering,
If local buffers can give a jump in speed, users may be able to work with that.
Seems there is a lot of spare local RAM in these examples.
Most USB transactions tend to be packet based anyway, and host SW is usually actually half duplex at the handling level.
The cheaper USB chips might allow higher nominal baud rates, but heir actual thruput, is lower.
You need to go to the FT232H/FT2232H series, (or another Prop) to get sustained mega-baud transfers.
To be truthful, I have not yet learned all the SPIN things needed to be proficient in that language, so I just continue writing my apps in assembler. I also need the speed of assembler, or at least that's what I tell myself. In fact when I posted that code three years ago, I included the comment that I'm SPIN challenged.
But since then I have been making significant advances with it, to the point where now I could provide the necessary or required SPIN wrappers. But again what would be the point if there is negligible interest.
You will also note that I had not posted that code, or any other for that matter, to the OBEX, realizing it was not a complete solution. And furthermore, as a commercial developer who makes his living selling software solutions, I have a problem with the whole OBEX-MIT thing anyways. I simply post these code tidbits for folks to realize that there generally ARE solutions to most problems. I just like to show some insight from my perspective.
Hopefully I can become a more prolific contributor to the forum in time to come.
Cheers,
Peter (pjv)
Marty
Let me know if it works!
thanks,
Jonathan
Wow, old thread, sorry for reviving it from the grave, but I had to.. no one gave jon mad props...
IT WORKS! (and it retains the function rxtime() str(), plus more of fullduplexserialplus)
(thats been a big issue when people re-write serial drivers, no functions to make it backward compatible)
(i haven't verified its ability for the data to arrive 100% but it looks like its working...
https://forums.parallax.com/discussion/comment/1429591/#Comment_1429591