when 128k is not enough

[richard]

Got it. Of course having it interrupt driven by default has drawbacks of its own. Is it high/low priority? Does it in turn block other interrupts? How much overhead does it add in term of interrupt processing etc etc. I suspect there are commands available that does not use interrupts so I do get your point.

for the arduino as soon as you issue the serial.begin() command the system takes control ,the user has no say in the buffer size (and I don't how big it is) and its behaviour when full or overrun is undefined .
it also has a millis() interrupt running every 1 millisecond and a micros() int running every 1 microsecond too presumably wether you want them or not. nothings perfect (a mans got to know his limitations )
and as jerson indicated the arduino ide does its best to completely hide the hardware from the user for better or worse . but I have to hand it to them their library code is pretty slick and the optimising capability of the complier is outstanding.
I have used pic chips for more than 20 years and I am very comfortable with their hardware modules and can nearly understand the data sheets . The pwm section alone of a atmega2560 is 25 pages and I find it quite difficult to come to grips with it the and terminology seems foreign to me . so when it comes down to a nut and bolts nitty gritty situation I keep bouncing back to known territory.

[longpole001]

MICROCHIP have confirmed that emb works at 64mhz at 16bit mode , recommends glue logic, and sram - see links

i have asked charles to confirm method would work as he is working on code using the 18f87k22 at the moment

regards

Sheldon

We have received some suggestions from another engineer for third party components. Obviously, anything suggested will need to be vetted by you for your application as Microchip can not support or verify third party products. However, here are the suggestions:

A lot matters on the choice of vcc
http://www.nxp.com/documents/data_sh...LVCH16373A.pdf - is a 3 v part
http://www.ti.com/lit/ds/symlink/sn74ahc16373.pdf is slower, but supports 5v
http://www.alliancememory.com/pdf/sr...c1026bv1.3.pdf 64Kx16, 5V
http://www.cypress.com/?docID=49420 256Kx16, 5V
http://www.alliancememory.com/pdf/sr..._8TIN_V1.4.pdf 256Kx16, 3V

[tumbleweed]

Thanks for the updated info. Interesting idea about using SRAM and serial flash for 0 wait states.

this method on surface may allow for the expansion of available ram to the PIC as well

It would, but you're limited to accessing it using TBLRD and TBLWR instructions, so it wouldn't function as "normal ram"

The points highlighted in the thread indicate that the generated hex file would need be edited at the 128k code boundary , sub divided into 2 hex files manually, then loaded in to the PIC program area , then into external flash , then from external flash into the sram for use at startup

You'll likely have to have a bootloader anyway to read/write the serial flash, so you could just have the bootloader handle the whole hex file without having to manipulate it. Store the entire thing in serial flash, and then at power on read the data and either program the internal flash (for the first 128K) or copy it to the SRAM (for the rest). After doing that once, you wouldn't have to reprogram the internal flash unless things change.