when 128k is not enough

[longpole001]

i am using 18f67k22 , like to use - anything bigger for code space and pbp ,

the device is holding together well with the code as it is running at 64mhz , but faster, bigger , more would be nice for some wiggle room , 2 or more cpus are the only option forward when using pbp and a chip that has 128k code space close to full

[towlerg]

I had a quick look, may be wrong but the only devices I could find with more that 128K were PIC24 and PIC32. If that is the case, don't even bother hinting to ME, it a whole new compiler.

George

[longpole001]

The only reference I've found in the 87K22 datasheet is a note that says"Fmax=25MHz in 8-bit external memory mode". Using a 16-bit wide memory may ease this a bit, but there's nothing in the data sheet to back that up.

this would mean the whole chip has to run at 25mhz , assuming that you external mem/ addressing is used for compiled code by the sounds of things

Assuming that the compiler doesn't have any internal program size limits, there's nothing special you have to do when writing your program... you just end up with a really big hex file.

i am not so sure that it does , i have always though it was tied to the chip selected when compiles , as such the chip size limits would apply and give errors in the compile , not warnings and thus not compile ???

[towlerg]

i am not so sure that it does , i have always though it was tied to the chip selected when compiles , as such the chip size limits would apply and give errors in the compile , not warnings and thus not compile ???

I guess you'll need to edit BLOCK_SIZE in the device file.

George

[HenrikOlsson]

I'm not saying there isn't a way to make it work but I'm pretty sure PBP doesn't support it natively.
You'd need to somehow fool the compiler into thinking the device has more memory than it has (if that's even possible). Then the compiler and assembler generates a single .hex file which you'd need to split at the correct location, program the first half into the PIC itself and the second half into the external memory device using some other type of device programmer.

I don't know the format of the .hex file, if there's any sort of header and/or checksum or anything like that. If there is, then simply cutting the file into two most likely isn't going to work and some sort of software would need to be written to repackage the large hex into two with the correct format.

Again, I'm not saying it isn't possible and I look forward to hear about any experiments. All I'm saying is that I don't think it's going to be straight forward.

/Henrik.

[Demon]

I'd head over to the MeLabs forums for something so technical.

Robert

[HenrikOlsson]

I've just tried a couple of things....

In MicroCodeStudio I selected an 18F1220, which has 4k of FLASH.
I started to add code and compile untill I got close to 4k (I got to 4095 bytes).
At that point I expected to get an error message if trying to add more code but I didn't. Since I knew I was at the limit I added started to add @ NOP, one by one, each adding two bytes to the compiled/assembled size as shown in MCSP. Finally, at a reported size of 4107 bytes, it no longer seemed to get "any bigger". However, the compile and assemble process finnishes without errors and the actual .hex file keeps growing.

I then started MPLAB, selected a 18F1220 as the device and imported the .hex file. Needless to say, the last line displayed is at adress 4094
I then found this blog post which discusses the format of the actual .hex file.
What it tells me is that, as expected, it's not just a matter of simply splitting the file at the right location and I have no idea if the compiler/assembler process actually generates the correct adresses etc for calls outside of the chips "normal" memory.

In MPLINK helpfile there's a short section on how to set the linker up to build C and assembler Project for use with external memory. How that could be applied to PBP (if at all) is beyond me at this point.

I'd definitely drop MeLabs a line but considering you've already mentioned you're up against the 128k limit at their forum I would've expected them to suggest using external memory if at all possible.

/Henrik.