Jump to content
soft2

Large Data Arrays, Bank Switching

Recommended Posts

I'm trying to re-use some code for a PIC18F device that is using a large array - 512 bytes. I'm evaluating the best options to solve this problem and would like some input. The code will compile and work OK using C18 compiler which allows you to use arrays > 256 bytes by changing the size of a memory section in the linker file and then using the #pragma udata directive. Does SourceBoost have a similar directive or some other way to achieve the same result? Here are some options I'm considering:

 

1) Re-write the code for 256 byte arrays. This would be a huge amount of work.

 

2) Move the whole project to Mchp C18. I already paid for SB Pro license and don't like C18 as much. Not to mention at least 60% of the code has already been written for SB.

 

3) The datasheet refers to "indirect addressing" FSR registers etc. It appears these can be used to manipulate large array pointers. Has anyone used this feature? I'm not experienced with assembler but combined with option 1 may be a good solution.

 

4) Move the whole project to another hardware platform and say goodbye to PIC and SB altogether.

 

I'm curious the real reasons that the PIC defaults to 256 byte memory bank size. It appears they are using 12 bit addresses on the PIC18 devices, so why this limitation? In the C18 forums many people have successfully used section sizes other than 256 bytes so why the limitation in the first place? I don't fully understand how the the BSR saves much overhead.

 

Does SB have methods to use the FSR registers, INDF operand and address pointer manipulation instructions? They can be used with POSTDEC, POSTINC, etc for linear pointer arithmetic beyond 256 bytes.

 

Thanks!

Share this post


Link to post
Share on other sites

I'm idly curious as to why you need to manage such a large amount of data on a PIC.

 

What is it you are trying to achieve?

Share this post


Link to post
Share on other sites

Have you actually tried to compile a 512byte array? I must admit that I haven't but the manual says that an array may be any size as long as it does not cross the memory page boundary.

In the PIC16 chips this is 256 bytes (8 bit memory addressing) but in the PIC18 chips with their 12 bit memory addressing the page size would surely be 4Kbytes.

 

Please ignore all the above. I just had a closer look at the PIC18 memory organization and even though the addressing is 12 bits wide, for reasons known only to Microchip the memory is broken up into 256 byte pages.

Edited by AlexR

Share this post


Link to post
Share on other sites
I'm idly curious as to why you need to manage such a large amount of data on a PIC.

 

What is it you are trying to achieve?

 

I recently had the same problem, in my case I was buffering a 256 ints from the AD port which made 512 bytes....so it does happen sometimes. Got around it by being less fussy about precision but would have liked a big size array.

 

Possibly one solution would be to write your own array access primitives (ie your own functions) using the FSR registers you've mentioned, although I haven't looked into it myself. I would suggest googling 16 bit addressing for PICs as I imagine this has been addressed before.

 

Phil

Share this post


Link to post
Share on other sites

Well MikroC can do large arrays. It uses FSR0 register and MOVFF instruction.

 

Like this:

unsigned char bigarray[500];
unsigned int index = 401;

mybyte = bigarray[400];
mybyte = bigarray[index];

 

I am sure Dave and Pavel can squeeze this feature in the PIC18 library.

 

Cheers

 

Reynard

 

ps. I didn't want to show you this but it comes out something like this:

;		 mybyte = bigarray[400];
$007E $C1C1 F030 MOVFF _bigarray+400, _mybyte
;		 mybyte = bigarray[index];
$0082 $0E31		  MOVLW _bigarray
$0084 $242E		  ADDWF _index, 0, 0
$0086 $6EE9		  MOVWF FSR0L, 0
$0088 $0E00		  MOVLW @_bigarray
$008A $202F		  ADDWFC _index+1, 0, 0
$008C $6EEA		 MOVWF FSR0L+1, 0
$008E $CFEE F030 MOVFF POSTINC0, _mybyte

Edited by Reynard

Share this post


Link to post
Share on other sites
I'm idly curious as to why you need to manage such a large amount of data on a PIC.

 

What is it you are trying to achieve?

It's not a large amount of data, just a large array (for a PIC). I'm buffering input data from an SPI implementation and the data objects are 512 bytes. It would be handy for that reason but the biggest reason I want that size array is I'm trying to re-use some code that is heavily dependent on the array. The code is somewhat complicated and has already been thru extensive testing. To make major changes to it is possible as in option 1 in my OP but it's a large task and then would require much more testing.

Share this post


Link to post
Share on other sites
Well MikroC can do large arrays. It uses FSR0 register and MOVFF instruction.

Reynard thank you for this information. That compiler looks like it has some cool features. I've never heard of MikroC before! It implements large arrays better than C18.

 

The example you give using large arrays sure looks good. And the sample of assembler for how it's implemented is helpful. It's one thing to read the datasheet and another to actually see some sample code. Like ppulle suggested, I may have to write some low level methods. It would never be as elegant as uchar bigarray[512] which won't compile on SB. I'm just trying to figure out which is easer of my listed options. A whole new compiler and/or platform, re-write the code for SB, or some other option.

 

I am sure Dave and Pavel can squeeze this feature in the PIC18 library.

Why not? I'm sure they have nothing else to do. :angry:

Seriously Pavel and Dave, can you do this?

 

Thanks for your help!

Regards,

softy

 

PS. Pavel that was a joke about "nothing else to do". Not meant to be an insult.

Share this post


Link to post
Share on other sites

You may not have heard of Wiz-C by FED either. I don't have this currently installed on my machine just now so don't know if it does large arrays. Had a scan through the manuals but no joy.

 

I am not a big PIC user so have no bias towards any PIC compiler although I do own a copy of BoostC. I just dabble with the others demo versions to see what they can do. I just offer my tupence worth to BoostC users.

 

I was brought up on 8051 and Z80 cored devices like Dallas DS2001 and Rabbit 2000 etc. Shows you how old I am.

 

Cheers

 

Reynard

Share this post


Link to post
Share on other sites
Seriously Pavel and Dave, can you do this?

 

It might be possible to remove array size limits for PIC18. We'll investigate.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
It might be possible to remove array size limits for PIC18. We'll investigate.

 

Regards,

Pavel

Pavel thank you for looking into this. When do you think you might have more information for us? I was getting ready to port to another compiler but I will wait to hear back from you...

 

Thanks.

Share this post


Link to post
Share on other sites
It might be possible to remove array size limits for PIC18. We'll investigate.

 

Regards,

Pavel

Pavel thank you for looking into this. When do you think you might have more information for us? I was getting ready to port to another compiler but I will wait to hear back from you...

 

We are busy with a new release. Once it's out we'll have time to look at the big array issue.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
Just a thought, would this work as a union - giving you exactly what you want?

Thank you for that idea from your previous thread! That will help if I decide to stop waiting for SourceBoost to be updated for large arrays on the PIC18F. Any word yet Pavel?

 

As for the union, I've thought about this before but couldn't figure out how it would help. SB allows you to compile a variable declared as:

unsigned int big[256]; which crosses a 256 byte page. But I'm not sure what happens if you do this:

 

union _wholeEnchelada {
UINT   uBigInt[256];	  // this will compile but how is memory managed?
UCHAR  cBigChar[256];	 // array size is somewhat arbitrary here
} wholeEnchelada;

wholeEnchelada.cBigChar[500] = 'A';		

// or this:

*(wholeEnchelada.cBigChar + 500) = 'A';

 

For that matter, what happens when you access elements of uBigInt beyond the first page starting with uBigInt[128]?

I don't know if you have already tried any of these things which are somewhat dangerous. I haven't because I'm waiting for word (hopefully soon) from Pavel as to when/if they will allow large array size for 18F devices with SourceBoost.

 

How were you thinking of using a union?

 

Thanks! ;)

Share this post


Link to post
Share on other sites
It might be possible to remove array size limits for PIC18. We'll investigate.

 

Regards,

Pavel

Pavel thank you for looking into this. When do you think you might have more information for us? I was getting ready to port to another compiler but I will wait to hear back from you...

 

We are busy with a new release. Once it's out we'll have time to look at the big array issue.

 

Regards,

Pavel

The new release is out so I was wondering if you had a chance to investigate this. I'd like to get back working on this project again.

 

Thanks.

Share this post


Link to post
Share on other sites
The new release is out so I was wondering if you had a chance to investigate this. I'd like to get back working on this project again.

 

Yes we started looking at this. Plan to have a test compiler build that supports this feature in about one or two week. We'll send it to you to try out.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Does anybody know if this has been added? I have aan array of 17 bytes * 50 entries = 850 bytes of data in the array. I do not get any compile errors so I am wondering if this will be an issue or not. I am using the latest BoostC++ compiler with a full license... Part 18f4620

 

Any advice would be most helpfull

 

Thanks

Share this post


Link to post
Share on other sites
Does anybody know if this has been added? I have aan array of 17 bytes * 50 entries = 850 bytes of data in the array. I do not get any compile errors so I am wondering if this will be an issue or not. I am using the latest BoostC++ compiler with a full license... Part 18f4620

 

Any advice would be most helpfull

 

Thanks

 

Yes large array support will be available in SourceBoost release 7.0 that is under development. We plan to publish a pre-release of it sometimes soon.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites
Yes large array support will be available in SourceBoost release 7.0 that is under development. We plan to publish a pre-release of it sometimes soon.

 

Regards,

Pavel

Thanks we are waiting patiently for that. Just to give you an idea how patient we are, I'm sure most of us could wait a few more hours, possibly even until tomorrow. :) So, don't rush or anything... ;)

Share this post


Link to post
Share on other sites
Yes large array support will be available in SourceBoost release 7.0 that is under development. We plan to publish a pre-release of it sometimes soon.

 

Regards,

Pavel

Thanks we are waiting patiently for that. Just to give you an idea how patient we are, I'm sure most of us could wait a few more hours, possibly even until tomorrow. :) So, don't rush or anything... ;)

 

Pre-release date has not been set and I don't feel comfortable to promise anything just yet. We have couple of smallish issues left and hopefully will have something available soon.

 

Pavel

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...