What's difference between M328 and M328P - CVAVR?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone know offhand why I can select "Bit Variables Size" as 24 for my app when configuring the Code Generation settings in my CVAVR project for a M328P...

...but if I then just go to Project | Configure | C Compiler | Code Generation and set Chip to M328...

..and recompile, I get loads of compilation errors about too many bit variables and have to set the "Bit Variables Size" to 32 to make them go away?

The two resulting hex files, according to www.diffchecker.com are identical.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Shirley the bit variables are just GPIOR registers.
You can tick the box for slower memory.

At least, this box is in the dialog in my v2.60
The dropdowns for both 328 and 328P are identical. (0 - 112 bits)

The 328P has PicoPower, and hence less spare bits.

I never use bit variables.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I never use bit variables.


LOL--I use them a lot.

If you post a stripped-down source that demonstrates, I'd run it through the compiler here to see what comes up.

What CV version are you working with?

It might be instructive to post the .MAP files for the two builds.

Is there a difference in the "Use GPIOR..." setting between the two projects?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
You can tick the box for slower memory.
The Use GPIOR>31 box is not checked in either of my cases.
david.prentice wrote:
The 328P has PicoPower, and hence less spare bits.
Srsly?

CVAVR Help says

Quote:
The maximum size of the global bit variables, which are placed in the GPIOR (if present) and registers R2 to R14, can be specified using the Bit Variables Size list box.
I'm assuming (I can't find any supporting info) that the smaller the selection you make (0, 8, 16, 32, ... 112) the more of the R2 to R14 registers are made available for CVAVR to work its magic on.

But the same code gives the same .hex file, with M328P/32 bits (which I have to use to have no compile errors) as M328/24 bits, which compiles fine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you have the .MAPs handy, Martin?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pwned by the CVAVR user interface ;)

...when you change the processor from 328<->328P either way, the Bit Variables Size gets reset to 24 (without me noticing). So a recompile straight after a processor change and no adjustment to the Bit Variables Size always results in error messages, whatever the processor :embarassed smiley thing:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

...when you change the processor from 328<->328P either way, the Bit Variables Size gets reset to 24 (without me noticing).

Indeed, that is a bit of a gotcha with CV project modification. It isn't that unusual for us to change processor models slightly with a build of a new batch of controller boards--e.g. over the past five years there have been quite a few flavours of Mega48, or perhaps an '88 is going to be used.

One must be very careful to "save" a snapshot of the working project config before a model change. Besides your mentioned bit variable count, stack sizes will revert to defaults, and certain other options IIRC. Annoying/confusing/scary when the simple rebuild doesn't work as expected.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use GPIOR regs as faster ram. Just like the HC11 direct addressed ram was a cycle faster.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I use GPIOR regs as faster ram. Just like the HC11 direct addressed ram was a cycle faster.


Be careful with that, especially for bit variables. Probably in good shape if you stay in SBI/CBI range. However, generally only GPIOR0 on AVR8 is within this range. GPIOR1/2 are indeed OK -- >>if<< no work is done on them in ISRs. If it is used in both ISR and main, as with a bit flag indicating an event has occurred then the can be RMW effects. Of course, you could protect in the mainline and make accesses atomic but then you negate any cycle saving.

As 8-bit scratch pads within IN/OUT range it should be OK if straight assignments.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.