HSEROUT of array of data with termination on a null

[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!!!

[tumbleweed]

Final result: a few minutes over 5 hrs

That's probably not too bad, considering you have to send packet requests to get data.

Doing that's a good idea... I was worried you were just going to stream 256MB out the pic and expect the PC to keep up.

[jimbostlawrence]

Hi Tumbleweed,

Looking at the DS (Pg 342 / Ex 21-1), the calc, using the crystal on this board:

(((22,118,400 / 230,400) / 64) - 1) = 0.5

When sent to the SPBRG, this will result in just 0

Reversing:

22,118,400 / (64 (0 + 1)) = 345,600 BAUD

Is that correct?

I've checked the output file on the PC side and it's all correct - I just substituted '65' instead of the data from the on-board memory, and the file is filled with 'A''s...

The fact that there is no errors - is this because it's asynchronous and the systems are just managing, or am I missing something here?

Edit - just found a site that says switching on the BRGH = 1 with SPBRG = 5, BRG16 = 1, I can achieve 921,600 BAUD. I vaguely remember doing this about 6 years ago with a really bespoke strip board setup! Well, just tested it and the data continues to stream through to file seamlessly.

2.46 hrs for 256 MB.

Will have another read of the DS as I'm definitely missing something here.

Edit!

Ok, just realised my ref for Ex 21-1 on Pg 342 of the DS was for 8-bit BRG!

The correct formula (for anyone that's following this path), with BRGH = 1 with SPBRG = 5, BRG16 = 1, and using a 22.1184 MHz Xtal, should be:

Fosc/(4 * (n + 1)) where n is the SPBRG value (5), so 22,118,400 / (4 * (5 + 1)) = 921,600 BAUD.

Perfect.

Best,

Jimbo

[tumbleweed]

Jimbo,

The pic can transmit at that rate but you might run into trouble receiving.
921K is only 10us/byte, so you'll have to be able to handle incoming data at that rate.

I've run 460K baud with FOSC=64MHz, but it gets pretty tight much faster than that.
YMMV