Arduino keep restarting

Yes you right about the array thing, sizeof. Now is fixed, i replaced all sizeof's with the constants, thanks.

Now that i fixed the array size problems, arduino still crash for some reason.

Serial monitor sends a stange message: VMDPV_1|1ßUŠAY5 Don't know what it means but im using the VisualMicro

Can you attach your amended code please? Click "additional options" and you can upload your zip file.

[quote author=Nick Gammon link=topic=273383.msg1926693#msg1926693 date=1413691447] Can you attach your amended code please? Click "additional options" and you can upload your zip file. [/quote]

Yes, re-download same link: https://www.dropbox.com/s/jh07prpkb5ejq8n/Intelipower.zip?dl=0

I am not helping you any more until you do as you have been repeatedly requested to do.

Make an attachment.

whats wrong with the dropbox??? is blocked in your contry?
If no, theres no need to spam forum disk and save some IOs to server.

Is attached

Intelipower.zip (27.6 KB)

sn4k3: whats wrong with the dropbox???

Bzzzzz: Irrelevant.... the way this forum works is that code is either posted inline in the text or attached to the post.

const unsigned short MAX_DEPENDENCIES = 100;

...

const unsigned short SOCKETS_NUMBER = 8;

...

	Socket *dependsOn[SOCKETS_NUMBER];

...

SocketRules::SocketRules(Socket *socket)
{
	this->socket = socket;
	for (size_t i = 0; i < MAX_DEPENDENCIES; i++)
	{
		this->dependsOn[i] = NULL;
	}
}

You are going to need some attention to detail here. You are setting 100 elements of this array to NULL, when it has 8 elements.


const char *Outlet::ToString()
{
	return "OK";
	const int MAX_BUF = 2048;
	char *result = (char *)malloc(MAX_BUF);

What Arduino are you running this on?

I put in some debugging displays. This is really your job. If things crash add Serial.prints until you see where it happened.

In particular in Outlet.cpp:

Outlet::Outlet()
{
  Serial.println ("Outlet::Outlet()");
	this->state = STATE_IDLE;
	for (size_t i = 0; i < SOCKETS_NUMBER; i++)
	{
        Serial.print ("Outlet i = ");
        Serial.println (i);  
		char name[255];
		sprintf(name, "Socket %i", i);
		this->sockets[i] = new Socket(i, name);
		this->sockets[i]->Heartbeat();
		delay(500);
        Serial.print ("memory = ");
        Serial.println (getFreeMemory ());
	}
	this->state = STATE_ON;
}

Results:

Setup Down!!
Outlet::Outlet()
Outlet i = 0
Socket::Socket(unsigned short index, const char *name)
SocketRules::SocketRules(Socket *socket)
Done SocketRules
Done: Socket
memory = 60
Outlet i Setup Down!!

You can see from that, that you are down to 60 bytes of memory (out of 2048 on my Uno) after only one iteration of the loop in the Outlet constructor. Now you need to work out why.

Yes, my mistake… I have fixed: Socket *dependsOn[MAX_DEPENDENCIES];, but still crashing :frowning:
The problem can’t be from SocketRules constructor, a empty constructor will do the same effect, i think the problem is Socket reference SocketRules and SocketRules reference Socket, that can cause the problem?

Ignore my ToString() function, im not using for now.

Im using Arduino Uno R3

Running out of memory would make anything crash. You have to work out why that is happening. Put in the serial prints. Find how much memory is free at various steps in the startup process.

I should have used the F macro, like this:

  Serial.println (F("Outlet::Outlet()"));

Use that when you do the debugging or you will run out of memory from the debugging prints.

I did that debuging before, but it seens to crash in the wrong function and i removed all…
Now i see that can be a memory problem, where do i get the getFreeMemory() function?

I will review the code and try to find the mem problem.
Thanks

[quote author=Nick Gammon link=topic=273383.msg1926732#msg1926732 date=1413695373] Running out of memory would make anything crash. You have to work out why that is happening. Put in the serial prints. Find how much memory is free at various steps in the startup process.

I should have used the F macro, like this:

  Serial.println (F("Outlet::Outlet()"));

Use that when you do the debugging or you will run out of memory from the debugging prints. [/quote]

Ok, thanks for the tip. I'm new in arduino so i'm unaware of some macros/functions

sn4k3: I did that debuging before, but it seens to crash in the wrong function and i removed all...

Yes, well, memory problems can me shifted by debugging. Debugging displays (especially if you don't use the F macro) are likely to consume more RAM and therefore make it crash sooner.

Now i see that can be a memory problem, where do i get the getFreeMemory() function?

There are various memory reporting functions around but I got that particular one from:

http://andybrown.me.uk/wk/2011/01/01/debugging-avr-dynamic-memory-allocation/

sn4k3: What's wrong with the dropbox?

Quite a few things actually.

The very simplest as has been mentioned would be that it requires people to go to another site, in another tab, to find it and then to do whatever is required to actually download the file.

That is however minor. A more substantial problem is security. The site claims "The Dropbox website requires JavaScript." which may in fact not be true for downloading your file, but is - unnecessarily - mandated for viewing certain graphics.

You may or may not be aware of this, but JavaScript is the common vector for the great majority of malware on the Web, making it effectively obligatory to use controls such as NoScript. Whilst Dropbox may be safe (as may arduino.cc), the general principle is that JavaScript should only be permitted where strictly necessary for sites, the corollary being that excessive or indeed any use of JavaScript on websites is most often indicative of sloppy and less-than-competent construction - or frankly antisocial intent.

sn4k3: is blocked in your country?

Unlikely - or was that simply facetious? I might put that back to you however, it would be courteous to at least include your country in your profile.

sn4k3: If no, there's no need to spam forum disk and save some IOs to server.

That would most certainly be the pot calling the kettle black. XD

And it isn't that hard to send people where they aren't expecting to go. For example:

Modified code here: https://www.dropbox.com/s/jh07prpkb5ejq8n/Intelipower.zip?dl=0

Ok i have found the problem…

I was using String *runHours[100]; and it seens to stole very memory.
After define that array to be size 1 program go further but still crash on some point.
I got other String on Socket.h and i chaged it to name[50]; now arduino didn’t crash

After seeing Uno R3 specs i found that 2K of memory is tiny for what i need
But still i will try to fit all.

Thanks for all the debuging, that mem function saves my day ^^

sn4k3: Ok i have found the problem....

I was using String *runHours[100]; and it seens to stole very memory.

Oh, you found the problem did you?

I mentioned that very thing in reply #7 on page 1 of this thread. If you read the replies and acted on them, you might have saved quite a bit of time.

Instead "you" found the problem in reply #35.

[quote author=Nick Gammon link=topic=273383.msg1927646#msg1927646 date=1413747382]

sn4k3: Ok i have found the problem....

I was using String *runHours[100]; and it seens to stole very memory.

Oh, you found the problem did you?

I mentioned that very thing in reply #7 on page 1 of this thread. If you read the replies and acted on them, you might have saved quite a bit of time.

Instead "you" found the problem in reply #35. [/quote]

For say the truth i don't even notice that reply and im reading for the first time now... I should have missed because other's replies, my bad.

runHours can be used for define when relay is active or not eg: 10:00:00-11:00:00. So every day relay will be active from 10h to 11h.

As that times are not defined by me, is user defined i already set a high limit. If i need such limit? No. But i thought arduino had more ram. I decrease that size.

For say the truth i don't even notice that reply and im reading for the first time now...

Other members might bear that in mind next time you ask any questions.