More Variables Needed

[luminastrum]

Currently using a 14m chip and running out of variables fast. Reusing helps, but more unique variables is ideal. I'm moving up to the 40X2 chip, but I'll eventually run into the same problem. Does external EEPROM offer more? Will picaxe ever expand to the new PIC 32-bit chip?

 

[hippy]

Currently using a 14m chip and running out of variables fast. Reusing helps, but more unique variables is ideal.

One option is to move variables out to Ram/SFR (POKE), re-use them, and when done get the original back (PEEK).

I'm moving up to the 40X2 chip, but I'll eventually run into the same problem.

Everything has its limits.

Does external EEPROM offer more?

It won't deliver more variables but will deliver more space to hold variables if using the swapping mechanism, use I2CWRITE and I2CREAD rather than POKE and PEEK. Eeprom isn't a good choice for frequently writing to ( slow and life limited ), I2C Ram is better.

Will picaxe ever expand to the new PIC 32-bit chip?

Maybe one day. The instruction set of the 32-bit PICmicro is significantly different toearlier PICmicros ( likewise for the dsPIC ) so if the Firmware is written in optimised Assembler it could be difficult to change and the effort not considered worthwhile given the main PICAXE target market.

If the firmware were written using a portable high-level language, any architecture, even non-PICmicro, could be used. High speed of processor execution would likely outweigh any inefficiencies of the HLL usage. A lot of the code would likely be very specific to the actual target though so it's still not a ten minute task.

 

[kevrus]

Slightly off topic, but I would like a bit more code space in the 08M and 14M, actually, twice the amount...

 

[hippy]

More 14M code space isn't going to happen unless Microchip produce a 14-pin PICmicro with twice as much Eeprom or self-programmability.

 

[lbenson]

Twice the amount of code space in the 08M, 14M, or 20M would be very helpful. I know that without the appropriate Microchip PIC, it won't happen, and even if the chip were available, it might not fit into Rev-ed's business plan. We can wish.

 

[demonicpicaxeguy]

when you consider how much ram is actaully in these pic's eg pic16f88(18x) has 386 bytes unless almost all of it is used by the interpreter (i doubt it) you'd think they would have a few more variables availble for use

as for the pic32 chips they are an interesting kettle of chips ( pun intended ... "kettle chips"?)

as for a pic32 based picaxe... i wouldn't hold my breath, while it's one of those chips that are quite easy to write compilers and interpreters for it because it doesn't really fit in with the market they target and that you can only get it it surface mount i doubt we'll see it at all but you know whay Rev-ed are like there's always a suprise waiting around the corner

 

[inglewoodpete]

My understanding of the PICAXEs is that if the 08M, 14M and 20M had more variables, they would fit less programme. With the highly compressed tokenised code, it would take more bits to address the additional registers. This in turn would make the tokens larger and mean that less programme could be stored.

The 08M is a magic chip. It balances code space very well with the number of pins. It teaches you to write very efficient code. The only real advantage the 14M offers to me is the additional pins for an I/O intesive application. If you need more programme space, use the 18X rather than the (yet to be released) 20M.

Peeking and Poking are very inefficient ways of storing data: they take up a lot of programme space. I find I have to use looping structures to use it in the 'M' series. I understand the frustration that there is more RAM available than can be accessed in nearly all applications.

I guess its the challenge of the technology: getting something to work well with limited resources. We're always pushing the limits. I'm sure PICMicro and Rev-Ed are well aware of it!

 

[luminastrum]

Anyone have success linking several picaxe chips together for more RAM and more variables? For instance, create a master chip that contains the "main" code, and slave chips that contain subroutines with elaborate algorithms but simple inputs & outputs for the master chip. Is this worthwhile? I'm willing to take a hit in speed for more RAM and more variables. Appreciate your comments.

 

[MartinM57]

If your happy with knowing all your variable as just memory addresess, then Ramtron FRAM is fantastic - it even remembers all the values when you turn it off!