when 128k is not enough

[richard]

THE OTHER OPTION
arduino mega 2650 :- 256k flash 8k ram 4k eeprom ,the sainsmart clones <$20 delivered .
big bonus 16mhz mega is about 4 times faster at floats than a 64mhz pic18 and equal or better at most other tasks, plus the free compiler is outstanding , especially in its optimisation capabilities .
floats are pain free in comparison to the microchip float library. its almost as if atmel actually want you to use their products unlike others who want $1000 for a decent optimising compiler.
most of the free libraries I have tried are very good even the colour touch screen glcd lib (try to find a free one that works for a pic), there are bigger/faster models too including a 32bit version that looks to be using the same ide . got one of these (a mega)plugged into the pi too via rs232
ps debugging
wow for $25 got the atmel studio arduino suite plugin , source level debugging at last that actually works and without any fancy (expensive ) headers either

the arduino forum has about a 100 new posts a day compared too ??

[Ioannis]

Richard, what you post seems a lot interesting. But I 'd like a more detailed reasearch. For example, same kind of code in PBP and Arduino C like lanquage.

What size code produces each compiler?

I have a strong feeling that Arduino is not near in the same neighbour. So if Sheldon has problem with 128Kb in PBP, how would this code be efficient enough for the Arduino? I think it won't.

Have seen small programs that take many KB in Arduino that could be built with less than 1 or 2 in PBP.

The other side is that is very easy and worry free as you said. Meaning there is no such thing as free meal.

Ioannis

[richard]

ioannis , what you say is correct esp for core 10 and 14 chips who's architecture is not particularly c orientated . pbp is hard to beat for small efficient code on these chips.
but for floating point work and/or complicated string parsing on pic18's c comes into its own . I firmly believe in horses for courses and lets face it the difference in price between a pic12f1822 and a 18f45k20 is not that great. as I have said before why struggle unless you are going to make and/or sell heaps of units , most of my stuff these days is one off , plus If I can get the esp8266's to behave the IOT becomes a reality . the esp8266 prg is 8.67k compiled with c on a pic . I will port it to arduino and compare. so far I can't get it to function properly with pbp3 the inherently blocking behaviour of basic functions is making life hard for that idea ,but worth pursuing for the IOT revolution (if its not all hype)

[longpole001]

APPLICATION NOTES ON EXTENDED MEMORY BUS
http://ww1.microchip.com/downloads/e...tes/00869b.pdf

[tumbleweed]

I probably should have been clearer when I said there's nothing special you have to do when writing your program.
There was talk of having to use ASM and split the program into multiple sections, manually enter addreses, etc.

To enable MPASM to override the device size so you can use external memory you need to add a __MAXROM statement to the device .INC file, like so:

__MAXROM 0x1FFFFF		; 2Mbyte

I don't use PBP much anymore, so I just did that with an old 18F6680 (64K) program I had and built a 1.2MByte program using PBP 2.47


As you've all mentioned, the trick here is what to do with it once you're done. You have to get part of the hex file into internal memory, and the rest into the external flash chip. If you somehow want to program the devices using an external programmer, there are tools you can use to split the hex file into the needed segments. I'd recommend the hexmate utility that you can get for free w/some of the Microchip tools.
Personally, I think you'd be better off using a bootloader program running in the internal flash and just let the device itself program everything.


some other comments...

also the CE for wait states on external memory bus has been fixed in C5 release of silicon

Thanks for that. I didn't realize it had been fixed.

re reading the datasheet , section 31-1 - note1 Fmax= 25Mhz in 8 bit External Memory mode - FOR VDD VALUES 1.8 TO 3V ,
so i would think that as long as VDD is higher than 3V then Fmax = 64Mhz

I think you're mis-reading that statement. There's a period in that sentence that you've deleted.
In Figure 31-1 the note reads:

Note 1: FMAX = 25 MHz in 8-Bit External Memory mode.
For VDD values, 1.8V to 3V, FMAX = (VDD - 1.72)/0.02 MHz.

That puts a limit of 25MHz on FMAX when using 8-bit external mode. Period.

If you look later in the datasheet at Figure 31-6 it shows an external 8-bit bus cycle. At cycles Q3 and Q4 it shows fetching a byte from each of the byte-wide chips in a single Q period. At 64MHz, each OSC Qn is 16ns! That would be one fast flash chip!

Unfortunately, the datasheet doesn't show a fetch using a 16-bit device. App note AN869B shows a 16-bit fetch, and the timing is a lot more reasonable since it uses Q3 and Q4 together to fetch a single 16-bit value. If you combine that with a wait state (Figure 12) then you'd have a bus cycle of ~120ns, which would match up with the speed of most flash IC's.

The thing is you would still only have roughly a single cycle (16ns) to latch the multiplexed address info. I doubt that the PIC IO pins would actually be able to keep up with this speed. 25MHz would give a single Q time of 40ns, and a bus cycle of ~160ns. You could probably run a bit faster than this, say perhaps 32 or 40MHz before the IO pins quit working properly, but as I said there's nothing in the datasheet to guarantee that.


This is all pretty advanced stuff. You'd have to decide if it's worth all the bother or not. Of course, porting 120K of existing PBP code to something else is a lot of work too!

[pedja089]

I just did quick test.
Compiler doesn't mind compiling code larger than 128K. Actually, there is no way that compiler could know hex size, before assembling. So far so good.
But after assembling, assembler returned error that generated hex is too large. After adding __MAXROM 0x1FFFF to P18F67K22.inc, hex file is generated without any error.
I have done "secure" bootloader for PIC18F67K22, so when I need more memory, there is simple solution.
Thanks, tumbleweed!

[longpole001]

also the CE for wait states on external memory bus has been fixed in C5 release of silicon

[longpole001]

re reading the datasheet , section 31-1 - note1 Fmax= 25Mhz in 8 bit External Memory mode - FOR VDD VALUES 1.8 TO 3V ,

so i would think that as long as VDD is higher than 3V then Fmax = 64Mhz