PDA

View Full Version : Max Array Size?



Art
- 28th April 2018, 06:30
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
- 28th April 2018, 14:48
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
- 28th April 2018, 18:13
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
- 28th April 2018, 20:01
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
- 28th April 2018, 20:03
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
- 28th April 2018, 23:34
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/attachment.php?attachmentid=8485&d=1508279203

Art
- 29th April 2018, 03:38
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
- 29th April 2018, 04:25
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
- 29th April 2018, 10:18
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
- 29th April 2018, 11:32
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
- 29th April 2018, 12:03
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
- 29th April 2018, 12:08
I assume you set X & Y somewhere else
yes they are essentially global vars

richard
- 29th April 2018, 12:19
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
- 29th April 2018, 16:17
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
- 30th April 2018, 09:42
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