Max Array Size?

[mpgmike]

Are you asking what PIC has the largest RAM or are you asking how to fill the available RAM on any PIC to the brim?

[Art]

Neither.
No pic I’ve used with PBP has provided a mechanism to define all available RAM in a single array, probably due to bank swapping.
I’d guess PBP wants the RAM in an array to be continuous, and access it without any bank switching.

But I’ve only ever used PBP with pics up to 16F876/877, and went straight to dsPic with C from there.
Maybe some version of PBP/3 with some 18F family can have larger PBP arrays.

[mpgmike]

When you compile you get several files, one is called your .LST or List file. If you open that file, at the bottom it shows you how much available memory you have used in each of the categories.

[Dave]

Art, You really need to look at some of the newer pic's. I have just finished some code for my daughter to build a table lamp with 1000 APA102C's. That's controlling over 3000 memory locations contiguously. It uses an 18F26K22 with dual UART ports. !
1 for EPS8266 support and 1 for BlueTooth with a bootloader.

[richard]

here is an example using linear memory access to make a large array , note how the memory is reserved in pbp


http://www.picbasic.co.uk/forum/atta...5&d=1508279203

[Art]

My current project is for dspic33FJ128GP802, and has an 8000 byte, a 1024 byte, and 2048 byte arrays, but that’s not PBP.
(I say current, but I think it’s finished now).

I was wandereng if PBP needs a 2D graphics library. To port mine easily would need a single linear, easily accessed 1024 byte array.

I do remember one being posted years ago, and think that included lines and shapes, etc.
But then there have been consistent questions about getting mono graphics displays working over the years also,
such as a recent one, but granted, that was only about the interface.

It isn’t for any project of mine, but might be fairly easy to port for others. It’s contingent on some PBP supporting a 1024 byte array, because unlike most gfx libs,
The frame buffer is already in the format of the display when it’s sent to the display.
It’s the pixel functions that write into the frame buffer in a manner that accommodates the vertically stacked byte arrangement for some LCDs (and possible OLEDs).

[richard]

pic18's in pbp can handle large arrays no problem. although bit offset indexing is limited to 256 [byte size] dimensions .
for pic16 user command and a bit of asm can overcome array size limitations

its just easier in C
I published this

http://www.picbasic.co.uk/forum/showthread.php?t=21235

but it attracted little interest

[Art]

Oh my. The fact that yours hasn’t gotten a single reply puts me off. It’s not like I’d benefit at all porting one to PBP.
I looked at it enough, that it looks tidy, and in the end it does look like a KS0108 128x64 pix GLCD,
that you have just simplified the hardware interface for.

I used the LCD pins as is for mine, but used a shift register for the 8 bit data interface, so it ends up just trimming 8 pins,
and adding 2 pins for the shift register... remaining balance = -5 pins.
It doesn’t need to be a latching SR because the LCD enable pin is the latch that the LCD listens to.

[Ioannis]

I published this

http://www.picbasic.co.uk/forum/showthread.php?t=21235

but it attracted little interest

Missed that... I 've moved the thread to Code Examples in hope it has more attention as it was buried.

Regarding the size of arrays, for the 18F series, the manual says that size is limited by the amount of available memory. So, bigger PIC, bigger array.

Ioannis