Propeller Serial with Tight Byte Spacing

2»

Comments

  • Peter JakackiPeter Jakacki Posts: 8,772
    edited 2013-08-12 - 19:08:58
    pjv wrote: »
    Hi Peter,

    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.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- The LOT --- TAQOZ INTRO & LINKS --- P2 SHORTFORM DATASHEET --- TAQOZ RELOADED - 64kB binary with room to spare
    P1 --- Latest Tachyon with EASYFILE --- Tachyon Forth News Blog --- More
    paypal.png PayPal me
    Brisbane, Australia
    phone.png
  • Tracy AllenTracy Allen Posts: 6,404
    edited 2013-08-13 - 11:39:52
    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.
  • jmgjmg Posts: 14,094
    edited 2013-08-13 - 15:00:54
    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.
  • pjvpjv Posts: 1,903
    edited 2013-08-13 - 20:45:33
    Yes Tracy, I follow what you are saying.

    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)
  • LawsonLawson Posts: 870
    edited 2013-08-14 - 12:22:21
    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.

    Marty
    micro-power experiments with the propeller.
    Drivers for TAOS TSL3301 line sensor Forum thread, and OBEX
    Lumen Electronic Jewelery Website
    My AWD motorcycle Website and action video
    What I'm paid to work on. UW Lidar Group.
    FME, a Spin-only floating point library with trig, exponential, and logarithm functions. OBEX and Forum.
  • lonesocklonesock Posts: 913
    edited 2013-10-07 - 10:00:17
    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
    Free time status: see my avatar [8^)
    F32 - fast & concise floating point: OBEX, Thread
    Unrelated to the prop: KISSlicer
  • Clock LoopClock Loop Posts: 1,604
    edited 2018-01-16 - 15:39:38
    lonesock wrote: »
    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)

    (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

    1.Silicon gel filled square. <-2.Sonics(ultra even). 3.Lazers. 4.?
    https://hackaday.io/project/162734-a-trillion-year-clock
    54 propeller chips connected, One to rule them all.
    https://forums.parallax.com/discussion/127983/55-parallax-propeller-s-parallells-processing-of-permanent-perturbations/p1
    Seriously contemplating removing ALL my content from the net completely, FREEDOM OF SPEECH IS DEAD.
Sign In or Register to comment.