Shop OBEX P1 Docs P2 Docs Learn Events
'Serial' transmission speed? — Parallax Forums

'Serial' transmission speed?

GadgetmanGadgetman Posts: 2,436
edited 2009-12-21 10:47 in Propeller 1
I might have a project, but it all depends on the read/write transmission speed I can get on a 'serial' link.

Physically, it's a 5V CMOS level interface with Data and Clock(Clock is driven by the master) and speed of the clock is either 1.5MHz or 3.84MHz...
To add a 'slight' challenge to it, it's 12bit packets...

Is this doable?
(Will it need any external chips? )

In case anyone wnders, the interface is the one used in Psion Organiser 3 series PDAs for their expansion slots and for the serial adapters.
(It's a strict master/slave network with up to 63 slave units. )

The same interface is used in their old HC and Workabout industrial handhelds, the diminutive Sienna, and even their MC-series laptops.
While the old FLASH SSDs usedin these machines are good, it's darn near impossible to read those in a modern computer. (We can use the synch software which will give access to them as extra drives, as long as the PDA is connected and powered up, but at serial speeds... There was a SSD-reader available one, but with the disappearance of ISA slots in PCs, they disappeared off the market. Besides, those used·DOS-based·SW·)
But if I could use the SD-card library and make the Propeller pretend to be an SSD...
(The custom ASICs that originally handled the protocol are not available on the open market, and besides, I think they've been discontinued now.)

Anyway, any thoughts?

Or should I just wait for the Propeller II ?


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

Comments

  • LeonLeon Posts: 7,620
    edited 2009-12-19 13:47
    It should be feasible, there are some serial comms examples running at that sort of speed.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
  • GadgetmanGadgetman Posts: 2,436
    edited 2009-12-19 13:51
    Yeah, but it needs to capture 12bit packets.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • LeonLeon Posts: 7,620
    edited 2009-12-19 13:56
    I was just pointing out that it is feasible. You'll have to write your own software, or get someone to write it.

    Leon

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Amateur radio callsign: G1HSM
  • localrogerlocalroger Posts: 3,452
    edited 2009-12-19 15:41
    The Propeller is a 32 bit microprocessor, so 12 bit packets are a non-issue. Simple bit-banging loops generally reach a couple of megahertz; I'd consider 1.5 MHz easy but 3.84 MHz might be a bit tight. Depending on exactly how the protocol works you may be able to do a lot better than that by automatically clocking bits in with the counters, as in Lonesock's SD card driver, but that will require some very fancy counter code.

    I think the bigger problem, if you get the driver working, will be implementing the business logic for one of those bus interfaces in the Prop's limited Hub RAM. I'm not familiar with this particular unit but those interfaces generally implement a whole zoo of functions, most of which are seldom used but could break the interface if they're not available when expected.
  • kwinnkwinn Posts: 8,697
    edited 2009-12-19 16:12
    The speed is attainable with the prop and the fact that it is 12 bits should not make it that difficult. The simplest would be 12 bits per 16 bit word of hub ram or 2 bytes of sd. Tighter packing is also possible.
  • GadgetmanGadgetman Posts: 2,436
    edited 2009-12-19 17:46
    localroger said...
    The Propeller is a 32 bit microprocessor, so 12 bit packets are a non-issue. Simple bit-banging loops generally reach a couple of megahertz; I'd consider 1.5 MHz easy but 3.84 MHz might be a bit tight. Depending on exactly how the protocol works you may be able to do a lot better than that by automatically clocking bits in with the counters, as in Lonesock's SD card driver, but that will require some very fancy counter code.

    I think the bigger problem, if you get the driver working, will be implementing the business logic for one of those bus interfaces in the Prop's limited Hub RAM. I'm not familiar with this particular unit but those interfaces generally implement a whole zoo of functions, most of which are seldom used but could break the interface if they're not available when expected.
    The problem with speed is that I don't know in beforehand WHICH speed it will have to use, and it's the master device that sets the speed. If I wanted to build a 'card reader' to allow other computers to read the SSD cards, that might not matter(As the reader then would be master), but as I'm setting out to emulate a SSD that's not an option.
    (I really like to use the PDAs... full keyboard, WYSIWYG wordprocessor, 40+Hours usage on 2 x AAs)

    The 1.5MHz speed was used on the first models. The 3.84MHz came later. At the moment I don't know if there's a 'detect speed' function, or not.
    The good news is that I have a couple of the machines that only uses the 1.5MHz speed.
    (One is my MC400 laptop. 1989 vintage, 256KB RAM, 640x400 BW LCD, touchpad, NEC V30H 8086compatible CPU, WYSIWYG wordprocessing, instant on, fully pre-emptive OS with a GUI. It also does 20Hours on a recharge, or 60+ Hours on 8 x 1.5V AAs)

    The 'business logic' shouldn't be much of a problem. The SSD cards are 'pretty stupid' units, and all 'file system' processing(searching for free space, updating the FAT or whatever, locating sector X of file Y) is all done by the host computer.

    I have lots of FLASH SSDs of different sizes, a couple of ROM SDs(commercial SW)·a RAM SSD, a serial link, Centronics link, Serial-PCMCIA pod (for use with cellular modems) and even a third-party 3.5" floppy drive, so I have a lot of devices to test communications with.
    (The comms link is both a serial interface and a ROM disk. as it contains updated SW for installation on some models)

    My first task would be to create a 'network sniffer' and use that for dumping the activity when I do all kinds of operations, from plugging/unplugging devices, reading a FLASH, formatting it, or just checking the battery level on the RAM SSD.

    For simplicity I'll implement the SSDs as 'fixed size' files on the SD card. Therefore I won't have to worry about any 'file system translation'.
    (I have no clue as to the FLASH file-system, and only a suspicion about the RAM file-system)


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • localrogerlocalroger Posts: 3,452
    edited 2009-12-19 18:36
    I went searching and found a nice document describing the protocol: http://scss.com.au/family/andrew/pdas/psion/hdk.pdf

    It looks like the basic problem will be clocking bits in at 1 bit every 200 ns. At 80 MHz one prop clock cycle is 12.5 ns and it typically takes four clocks per instruction, so that gives you room for 16 instructions in the inner bit-banging loop -- this should be easily do-able. I think you will need a cog dedicated to shifting bits and moving the resulting data into appropriate hub RAM buffers based on the control bits, and another cog taking the byte-stream data and working with it.
  • GadgetmanGadgetman Posts: 2,436
    edited 2009-12-19 19:43
    I already have that document.
    (I also have the complete SDK, which is two very thick A4 ring binders)
    Unfortunately, it focuses mostly on using the ASIC as a peripheral controller, not as an SSD controller, so I need to sniff out some information.

    I get 260nS for the clock pulses, which should mean the COG can do about 5 instructions (a PASM instruction takes 4+ System Clock ticks, and each tick takes 12.5nS each. 200nS equals 16ticks, 260nS equals 20something ticks. )
    That's not much time.

    The .PDF doesn't state if there's a wait time between packets, but if desperate, I guess I could use the time of the last 'Idle bit' to increase the time I have for writing. (I really don't want to do that)

    If there's enough time, I may be able to set up a rudimentary logic in the COG to filter out packets adressed to other devices.
    (This requires parsing the 'Control Packets'. ) There shouldn't be any packets adressed to other units, as there's separate busses for most ports, but again, I don't have all the information, so...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • localrogerlocalroger Posts: 3,452
    edited 2009-12-19 20:46
    Arrrgh, yes, I forgot to divide 16 by 4. That's why it's tight.

    If you can set the counter up to clock bits in or out (like Lonesock's SPI driver) then you really would only be running code every 12 bits to process each frame, which would be much more comfortable.
  • GadgetmanGadgetman Posts: 2,436
    edited 2009-12-19 21:49
    Yeah.

    I'll be studying that driver...

    I found some notes on 'page 11' in the .PDF where they list how many cycles there must be between reads/writes. Those numbers are as seen from the host. (The host must wait at least 12 clocks after some writes before performing the next, and so on.) That gives me some time to transfer the finished data to/from HUB RAM, but I'm not certain how long I'd have to retrieve data from SD before it must be clocked out to the host.
    There's no mention of how long the host can wait, just how long it must wait.

    SD-cards, though, are read using SPI, so it may not always be fast enough.
    (SPI uses block addressing. The SSDs can in theory be read/written Byte by Byte. Some parts will probably have to be cached at all times no matter what. )

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
  • VIRANDVIRAND Posts: 656
    edited 2009-12-21 08:30
    Use external shift registers (and at least 12 pins)?
  • GadgetmanGadgetman Posts: 2,436
    edited 2009-12-21 10:47
    That is of course a possibility, but I would like to do it without external components if possible.
    (If I can do it in SW I'll only need to handle the 3.3V - 5V shift. )

    I also want to make it as compact and cheap as possible, in case other 'Psioneers' also want one.
    (I doubt I can match the size of the original SSDs at 64 x 42 x 6mm, particularly as I'll need to include a battery)

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Don't visit my new website...
Sign In or Register to comment.