TVout fails malloc in begin

Other Hardware Displays
1

I am using the Google Code Archive - Long-term storage for Google Code Project Hosting. and the sample code DemoPal fails in the begin method on the malloc(...) that returns a NULL.

I am using a UNO and the binary sketch size is 17,284 bytes.

Surely it should get past the malloc ... and consequently not much is happening :frowning:

screen = (unsigned char*)malloc(x * y * sizeof(unsigned char));

where x = 120 and y = 96 (which is what is in the sample code) and is == 8280 bytes .

2

The UNO uses an Atmega328P which has 2KB or 2048 bytes of sram. You can't allocate 11.5KB (120*96 bytes is 11520) of memory on such a device.

3

Aha. Am I only the one trying to run TVout on a UNO? I'm sure I caught some YouTube vids of people using it :(?

4

Ah yes 11520... I have a lame explanation as to why my maths came up with smaller number...

5

Am I only the one trying to run TVout on a UNO?

No, but I suspect you're the only the trying to use eight times (hint) too much memory.

6

Looks like a UNO here

and here

???

7

Thanks for the hint but its just the sample code that comes with the library...

What do you think it should be AWOL?

8

It's a monochrome output, not grey scale.

9

AWOL you are being very cryptic.

What is it that I have done? Where is the 256 shades of grey you seem to be referring to?

10

There are no shades of grey, so allocating more than a bit per pixel is a waste of memory.

11

Agreed...BUT this is the supplied library

12

The version I have first checks to see if x is divisible by 8, then divides it by 8 before the malloc.

(quick swap from tablet to laptop) Voila

char TVout::begin(uint8_t mode, uint8_t x, uint8_t y) {
	
	// check if x is divisable by 8
	if ( !(x & 0xF8))
		return 1;
	x = x/8;
		
	screen = (unsigned char*)malloc(x * y * sizeof(unsigned char));
13

Yep mine too... so I'm not allocating too much so why did it compile on my Mega and not my UNO... :frowning: hmmm - digging in deeper

14

so why did it compile on my Mega and not my UNO

Wait a minute; are you saying "it" doesn't compile?
malloc is runtime failure, not a compile-time failure.

What exactly is "it"?

15

It doesn't run past the malloc... I stuck some trace points in (which is why I'm embarrassed to have missed the divide by 8)

16

why did it compile on my Mega and not my UNO

It would compile for both, but there's the rather obvious point that the Mega has four times as much RAM

17

Head banging time :frowning:

On the UNO the malloc in begin returns NULL. Also Nano with 328 returns NULL but MEGA2560 mallocs okay....

I am remembering to set the board type between uploads. WTF

18

I'll say it again - the Mega has four times as much RAM as the Uno or Nano.

19

AWOL:
I'll say it again - the Mega has four times as much RAM as the Uno or Nano.

I know but cannot understand why the UNO and Nano fail because, as you say, the allocation is only 1/8th what I originally said.

20

It's still 1440 bytes out of 2048 bytes.
A few other buffers (serial, for instance) are going to eat that up.