Need help with C++

(Scott) #5

No, because program memory is read-only. If you need to alter the PlayFieldMap array then put it in RAM.

(Peter Shaw) #6

If I do I get this message from the compiler: Low memory available, stability problems may occur.

unsigned char PlayFieldMap[] = {0x00, 0x01, ....}; // 28*31 entries = 868bytes

Should I ignore this message?

Probably not. Now my Arduboy is bricked after the second compile.
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
avrdude: butterfly_recv(): programmer is not responding
Found programmer: Id = “��”; type = }
Software Version =

(Scott) #7

It depends. The program will need a certain amount dynamically allocated RAM for local variables, the call stack, etc.

The warning is probably based on the typical amount of dynamic RAM that the program will need when running. If your program needs less than this amount, then it will be fine. If it uses more, then it will likely blow up at some point.

(Peter Shaw) #8

So I am doomed? Because after resetting Arduboy I can upload my game just once. The second time it throws those exceptions and I need to reset again.

(Scott) #9

It’s probably not truly “bricked”. The high use of RAM likely causes the sketch to modify the “magic” RAM location that the bootloader uses to detect a reset. If the sketch runs OK after it’s loaded but you can’t upload another sketch afterwards, then this may be the problem.

You can recover using the reset button, as you’ve done before, but as I’ve already mentioned in the other topic you created, it’s better to include a call to flashlight() after boot() so you can hold the UP button while powering up to allow another upload.

(Peter Shaw) #10

We are talking less then 1kb for that specific array.

Sketch uses 11906 bytes (41%) of program storage space. Maximum is 28672 bytes.
Global variables use 2136 bytes (83%) of dynamic memory, leaving 424 bytes for local variables. Maximum is 2560 bytes.

I do not know how bricked is defined, but I need to reset it now everytime. It works once and thats it.

(Peter Shaw) #11

I do not get this flashlight() thing though. If I now press UP and power on Arduboy I see a white screen and a bright LED lightning up. What is the point? The problem remains. No second upload.

(Scott) #12

And 1K is reserved by the library for the screen buffer. If your array uses about 1K then that leaves about 0.5K of the 2.5K total for everything else.

It’s an unfortunate problem with the bootloader. Instead of using the very last RAM location for its magic number, it uses a location farther down. High RAM usage sketches may clobber this location even though there is sufficient RAM to allow proper operation.

(Scott) #13

Then you must have a large amount of global variables that initialise RAM (and thus one that clobbers the magic number) before flashlight mode is entered. Unless you can reduce the amount of RAM used by global variables, you indeed do have a problem.

(Peter Shaw) #14

Nothing special. You can take a look if you like:

Sorry for being blunt, but I find that amazing that somebody actually built a device with such low specifications. 1.5kb free memory is just insanely low. For a simple Pacmac I need to optimise the hell out of it? I thought this is supposed to get people into programming not scare them away.

(Scott) #15

There are currently over 100 perfectly functional and enjoyable sketches written for the Arduboy that are able to make due with the “insanely low” amount of RAM available.

Yours is the first sketch I’ve heard of so far that can’t be recovered using flashlight mode.

(Scott) #16

Maybe check out Ardu-man for some ideas.

(Peter Shaw) #17

Sorry again. I do not want to argue with you. I find it hard to believe that you cannot put a reasonable amount of RAM into such a device. Nevertheless, I will optimise the memory usage.

(Gavin Atkin) #18

It is definitely not much ram to work with, however the limitation I most often come up against is in program space. If you’re looking for a way to handle tile maps check out Mystic Balloons technical page on the TEAM arg website.

The Virus LQP-79 page has a different way of handling tile maps for larger worlds.

(Peter Shaw) #19

Another C++ beginner question. I need to check if a certain bit is checked in an unsigned integer.

This is my array with the food-pellets in my pacman map. Each integer represents one row. Each bit is than one column.

unsigned int pellets[] = {
  0x00000000, 0x7ff9ffe0, 0x42090420, 0x42090420,
  0x42090420, 0x7fffffe0, 0x42402420, 0x42402420,
  0x7e79e7e0, 0x20004000, 0x20004000, 0x20004000,
  0x20004000, 0x20004000, 0x20004000, 0x20004000,
  0x20004000, 0x20004000, 0x20004000, 0x20004000,
  0x7ff9ffe0, 0x42090420, 0x42090420, 0x73f9fce0,
  0x12402480, 0x12402480, 0x7e79e7e0, 0x40090020,
  0x40090020, 0x7fffffe0, 0x00000000

This is the method to check if a pellet is at a certain map position:

boolean evalFood( const unsigned int x, const unsigned int y ) {
  unsigned int row = pellets[y];
  unsigned int mask = 1 << x;
  return 0 != (row & mask);

I double-checked the values in the array and they are correct. However I get rubbish when displaying them. The pellets are shifted by 8 columns and truncated after 11 columns. Any help is appreciated.

(Kevin) #20

Part of the fun is trying to see what can be done in low memory space. That said, we are working on a new system with more memory for the future. The cool thing is all of the memory optimization done now will pay off even more with the expanded space.

In some ways Arduboy forces you to make efficient code and is meant to challenge you. It’s meant to be fun!

Also, we just used an Arduino Leonardo as the basis of the system, not much additional system design was considered at the time! Keep us posted on the project!

(Peter Shaw) #21

Turns out they were not :slight_smile: I messed up LSB and HSB. However it does not read bits higher than 15.

(Peter Shaw) #23

Because int are not necessary 32bits in Arduino. Got it.

(Scott) #24

If you’re working in C or C++ with data that has to be a known size, regardless of the platform, it’s best to use the specific sized types. In this case it would be uint32_t

However, the Arduboy has an 8 bit processor and natively can only work with bytes. Any larger type takes extra code and processing time. It would probably be better if you made pellets an array of uint8_t (or byte if you want to stay with official Arduino types). Then, treat 4 bytes as a row.

(Peter Shaw) #25

Thanks. I already did that :slight_smile: