HSEROUT of array of data with termination on a null

[jimbostlawrence]

To all,

MANY thanks for all your help with this guys. I have some data recovery to do on another project but will be back on this either tonight or over the next few days.

I'm running this on an 18LF26J53 hooked up to a 256MB Micron NOR FLASH chip, together with a crystal running at the magical 22.1184 MHz, so 115k BAUD is nice and clean. Will give the binary / TXREG a shot and get back to you. I used to be into assember back in the 80's (6502 / BBC B, and 68000 / Amiga) but not gone that deep in a long time. I think for now, I'll stick high-level and only go that deep if needs must.

Thanks again. Will see what happens.

Much appreciation,

Jimbo

[jimbostlawrence]

Hi all,

using:

          
for cnt = 0 to 255
                
    while (TXSTA.1 = 0)
    wend         
                
    TXREG = page_buffer[cnt]
                
next

Worked very nicely.

Initially, as I was working with VB as well, that I'm not that familiar with, I decided to initially stick with the transfer of double hex chars per byte, working on the multiple 256-page byte capture and export to file. I then brought in the above code (thanks Tumbleweed!) on the PIC side to stream the data as binary, halving the number of transmitted bits. It was then a fun job to adapt the threaded side of things in VB, but finally got it working.

As hex char's, I calculated it to be about 23.5 hrs (!) to transfer the entire 256MB of data from the Micron chip. That's now down to around 14.5 hrs. Still a long time, but transfer is stable; no errors.

I could probably bring this down some more by buffering the multiple pages, rather than "file.Write(byte_array, 0, 256)" each page to file. I expected that with the number of char's halving, that the overall time would halve, so assume this is now the bottleneck.

Perseverance, sweat, copious amounts of coffee, n munch, goes a long way!

Many thanks again all.

Best,

Jimbo

[HenrikOlsson]

I'd try increasing the baudrate even further.
According to Wikipedia 256kbits/second is a predefined serial port speed in Windows so you "should" have that available without doing anything "special". If you put a RS485 tranceiver at each end you get up into the Mbits/seconds without much problem but then something like DMA on the PIC-side would start to make sense.

[tumbleweed]

Most PC serial ports will run at 230400 baud.
The J53 will... just set:
BRG16=1
BRGH=0
SPBRGH=0
SPBRG=5

That might shave it down to under 4 hrs.
Make sure the MAX232 (or whatever you're using) supports 230K baud... some transceivers don't.

If I were sending that much data I'd be inclined to use a transfer protocol like XMODEM or something.
Are you just blasting 256MB out the pic uart and hoping the PC will keep up?

[jimbostlawrence]

Hi all again,

I'll give that a shot Tumbleweed. Was wondering about possibly taking it higher. I'll give those parameters a shot. I'm hooking up to a FT231X chip on a small custom board. The laptop has kept up without a hitch at 115.2k BAUD no problem. Not running any ECC but will if need be.

Yup, blasting out of the PIC EUSART thingy! Running all at 2.0V. It's actually the 18LF26J53 (not sure if I mentioned that above). The FT231X is good down to 1.8 V I believe.

Best,

Jimbo

[jimbostlawrence]

Quick update - thanks again Tumbleweed. Now running at 230.4k BAUD.

Time for 256 MB download now at an estimated ~ 11.2 hrs.

The bottleneck will be the handshake as I'm "requesting" each page (256 Bytes) by sending a short stream of characters $$$8xxxxxxx where xxxxxxx is the page number. The PIC waits for the $$$ and then reads the page request value, transfers that page from memory to the PICs RAM and replies with the data. This way it's a very ordered delivery; perhaps too ordered!!!

I think I'll try having it send each block (or whatever its correct term is) of 65536 pages in one long stream (16 of them in all on that memory chip, making 1,048,576 pages x 256 Bytes = 256 MB). Just need to buffer for longer on the PC side. If I get any errors, I can just reduce the number to something more manageable and request corrupted pages.

Will let you know how it goes, and many thanks again!

Best,

Jimbo

[jimbostlawrence]

Ok, didn't go for the full 65,536 pages.

Set initially to transfer 16 pages which brought it down to something considerably less.

Then upped it to transfer 64 pages which only improved it by about 20 minutes.

** Final result: a few minutes over 5 hrs

This is probably slightly higher than your original estimate (@Tumbleweed) due to having to transfer each page (very brief but does add up I guess).

Thank you!!!