Boolean Variables and RAM space efficiency

[triokenwood]

Hi all,

(and apologies if this topic has already been raised / discussed elsewhere)

Am I correct in understanding that FlowCode makes no attempt to condense the use of Boolean Variables into individual 'bits' within 'bytes' stored in COMRAM / Access RAM (or BANKn) space?

In other words - does every single boolean declaration in FlowCode result in the full and total use of an individual 8-bit byte?

In fact - does FlowCode even have control of this decision, or is it a function of the (non-free) 'optimised' versions of the XC8 compiler?

Cheers,
Bill

[LeighM]

Hi Bill

does every single boolean declaration in FlowCode result in the full and total use of an individual 8-bit byte?

Yes, it's standard C to do that, and is a function of the compiler.
XC8 does have a "bit" data type, but using this would cause confusion and incompatibilities.
Within your own C code functions you could also use bitfield structs.

Leigh

[Benj]

The GCC range of compilers (AVR / ARM) will also do this. I was hoping it would pack the bit's together for you but that doesn't seem to happen in practise without doing the packing yourself.

If you need optimal results then the best bet is to use say a byte as your variable and then set and clear the individual bits in the byte manually. I have had to use this approach in a few situations which were tight on memory.

Set bits in a byte

byte = byte | 0x01
byte = byte | 0x02
...

Clear bits in a byte

byte = byte & 0xFE
byte = byte & 0xFD
...

Test bits in a byte

byte & 0x01
byte & 0x02
...

[triokenwood]

Thanks both,

As I have thought more and more about the issue, I started to realise that, yes, of course 'bit-packing'' could be employed to put 8 boolean variables into a single RAM byte.

But, only at the cost of requiring those extra processor cycles to achieve the 'setting / clearing / reading' algorithms.

I am also now realising that there is also a 'code overhead' to store variables outwith the 'Access RAM' memory segment (in the 'Bankn' segments for eaxample (I'm dealing with an 18F2331 at the moment) - yes, you gain far more RAM space, but you have to deal with the BSR in order to switch in and out of the banks in the first place.

Unfortunately, all of this has come about because of an issue with one flowchart - an issue that has held me up for almost three months now. It seems that one of my 'Byte' counter variables is being 'corrupted' by a 'memory overlap' from a variable defined by FlowCode and/or XC8.

So, in trying to find out what on earth is going on, I am having to learn a whole load of C, ASM and XC8 functionality that I didn't really want to have to learn in the first place (which is, after all, the whole point of investing in FlowCode in the first place - all of this 'back room' stuff should not really be of any concern to someone writing simple flowcharts!)

What I was trying to do just now is to condense the amount of RAM used by my variables, and to also guarantee - somehow - that the 'memory overlap' that is happening does not affect my data.

Cheers,
Bill

[Benj]

Hi Bill,

Running out of RAM and memory corruption can happen on an AVR but on a PIC you should at least get compiler messages in the compiler output window warning you that this might happen.

Can you share you program and describe where the corruption is happening and maybe we can help.

[triokenwood]

Hi Ben,

That's what I will do - but I'll start a bew topic to nake things easier.

Cheers,
Bill