Max Array Size?

[Art]

Hi
If your goal is to have the maximum RAM array size, what Pic, and what version Pic BAISIC would you be using, and what would that size be?
The Pic can be any Pic BASIC supported Pic, and the Pic BASIC version could be PBP3, or any other version.

Short post, but there really isn’t any more to the question
Cheers.

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

[richard]

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 have made a ks0108 lib for xc8 that uses a frame buffer it works on any pic16/18 with enough
sram . alas pbp is just so far behind the times its just not on my list of thingstodo to port it there even if there was any interest.

i'd like to find a friendly forum for pic projects with at least a few active members. [ regardless of compiler used ]
there's heaps of features to explore using the newer 8bit chips and the mcc . I have found the mcc framework has
inspired me to new discipline for standard easily configured libraries for all sorts of things,this was just never possible using pbp
I don't want to be robinson crusoe it would be lovely to have a forum to bounce ideas off .


I got a explorer16 board on ebay not long back for peanuts and expect some pim modules from Portugal to arrive soon
along with some pigtail expanders from element14 arriving this week . so pic24/dspic are next on the agenda.
frame buffering is high on the list of experiments and i'm hoping mcc will help me build cross platform libs too.
dream on

[Art]

This has the potential to become that forum. PBP won’t be practical forever.

I’m looking at your setpixel routine. I assume you set X & Y somewhere else, and then just call that to write to the frame.
Not quite pretending to understand it yet, but I have every 2D function under the Sun that might possibly be added to it (in PBP very easily).
Forrest Fire Floodfill with 3 patterns, drawline, drawlinedotted, printtext, printsinetext, printlargetextvarwidth, drawtextvarwidthcentered, drawcircle, drawfilledcircle, drawrectroundedcorners,
drawrect, drawrectfilled, readtextfromdisplay, printmonobitmap, and a bunch of other stuff I wrote from scratch, and could do whatever I want with.

A bunch of them need FP support, such as drawtextrotated.

[richard]

I assume you set X & Y somewhere else

yes they are essentially global vars

[richard]

my C version does a lot of that but not all . since there was so little interest in a pbp version I left it pretty basic

C header

/* 
 * File:   ks0108 driver  21/4/18  20 pin ver
 * Author: rc
 * Comments: ver 1.00
 * Revision history: 
 * pins gCS1,gCS2,gRS,gRW,gRST,gE  all defined in mcc files
 * see user defines  for data bus and frame buffer
 */

// This is a guard condition so that contents of this file are not included
// more than once.  
#ifndef XC_HEADER_TEMPLATE_H
#define	XC_HEADER_TEMPLATE_H

#include <xc.h> // include processor files - each processor file is guarded.  
#include "mcc_generated_files/mcc.h"
#include <stdlib.h>
//#include <string.h>
#include "font1.h"

#define cs_on  1
#define cs_off 0
#define Out 0
#define In 255
#define bitset(var, bitno) ((var) |= 1UL << (bitno))
#define bitclr(var, bitno) ((var) &= ~(1UL << (bitno)))

//user defines
#define gPort  PORTC
#define gLat   LATC
#define gDir   TRISC
#define USE_FRAME_BUFFER 1

void GlcdInit(void);
void GlcdBox(char gx, char gy, char gw, char gh);
void GlcdHline(char gx, char gy, char gw);
void GlcdVline(char gx, char gy, char gh);
void GlcdPixel(char gx, char gy);
void GlcdSetxy(char gx, char gy);
void GlcdCls();
void GlcdCircle(char x, char y, char r);
void GlcdLine(char x0, char y0, char x1, char y1);
void GlcdClrxy(char x0, char y0, char x1, char y1);
void GlcdChr(char x, char y, char ch);
void GlcdStr(char x, char y, char * dat);
void GlcdBitmap(char x,char y,char w,char h,const char *bm);


char gread_byte();
char gread_data();
void gcmd_byte(char db, char rs);
const char gMSK[]= {0,1,3,7,0xf,0x1f,0x3f,0x7f};
char gMODE=0;  //  0 normal 255 inverse 1 xor function

// frame buffer functions
#ifdef USE_FRAME_BUFFER
char gFrame[1024];
void gUpdate();
void gScrollL();
void gScrollR();
#endif



#ifdef	__cplusplus
extern "C" {
#endif /* __cplusplus */

    // TODO If C++ is being used, regular C code needs function names to have C 
    // linkage so the functions can be used by the c code. 

#ifdef	__cplusplus
}
#endif /* __cplusplus */

#endif	/* XC_HEADER_TEMPLATE_H */

[Art]

It’s enough for me not to bother.
I’m studying now, and can’t do anything real committing where time spent on it could spiral out of control,
so I’ve been sniffing for a short kind of project.

[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

[Art]

I missed that one Dave. I said I went straight from 16F to dsPic. From there, you can really only go to Pic32
Same compiler though. There wouldn’t be any learning curve, so it’s just down to not having had the use for one.

Can hardly believe I’ve been here 15 years. Admittedly, it would have taken me 11-12 years to use anything other than 16F.

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.

[mpgmike]

I just pushed the "Buy" button on the Microchip Explorer 16/32 Development Board to start playing with bigger-than-8-bit PIC processors. I'm not sure I need that expanded range, but I couldn't possibly know without getting to know it. First exploration is with the PIC24FJ128GA010 (a plug-in on the Development board). Bought a book that uses that PIC for the basis of all learning.

[Art]

It occurred to me later that a PBP array could practically be the size of “all available RAM” so long as you could put up with the performance hit of calling a subroutine
instead of accessing an indexed array element directly.