Software for testing/debug before upload to IDE/Arduino?

Hi.. Does anybody know if does exists a software where I can code and test/debug before upload to Arduino?

I mean.. When I am testing (trying to do something) I have to wait ultil arduiono verify and upload to the hardware. and it may takes 10~12 seconds...

I don't know if there is a solution where I can produce and test/debug quickly and after I am done, paste the code into Arduino IDE and then make the upload?

For me that would be real easier since I don't have much experience.

Thank you so much

Rodrigo

What did your google search tell you? You didn't do one, did you?

yes I did and found a lot of arduinos emulator and things like that but I am not sure If thats what I need.

Tks for your answer, anyway

I'm not sure what you really need. I have a hard time believing that something is going to be faster than 10 to 12 seconds compiling and uploading and trying on the real hardware.

Hi, PaulS.

Well. for me even a simple IF or FOR, for now can be a problem, since I am starting with arduino. (Im sorry for that).

And.. I was thinking about something where I could just TEST the code.. like "test" and it tells you if the code is right or no. based on arduino.

If there is nothing like this, ok. I will keep using IDE arduino. I just wanted wo know.

Tks and I'm sorry if My question seems to be stupid

Your question is not at all stupid.

http://code.google.com/p/simuino/
I have not tested it, but it seems to be something there. Check it out.
http://www.virtronics.com.au/Simulator-for-Arduino.html
There is also this one, but costs money.

It is a pain waiting for the IDE to do its thing but you won't find anything much faster and it's way better that the 24 hours my first programs took to compile and to find that you had a stupid syntax error and the program didn't even get built let alone run!

Mark

it's way better that the 24 hours my first programs took to compile

You must be old! 8)

I remember those days.

enanthate:
Your question is not at all stupid.

Google Code Archive - Long-term storage for Google Code Project Hosting.
I have not tested it, but it seems to be something there. Check it out.
http://www.virtronics.com.au/Simulator-for-Arduino.html
There is also this one, but costs money.

Hi!

Well.. first of all, thank you for your reply!!

I will test the websites and check if I find something. Do yuo use some software else or the Default Arduino IDE?

holmes4:
It is a pain waiting for the IDE to do its thing but you won't find anything much faster and it's way better that the 24 hours my first programs took to compile and to find that you had a stupid syntax error and the program didn't even get built let alone run!

Mark

Wow Mark.. That was really long time!!!!

I have no Idea how that was. Start in programming would take a year for just a "hello world" lol..

Well.. about my question.... I was actually looking for something that doesn't exactlty makes the upload.. just check instantly if the code is ok or have some error.

Do you know if I can find something like this?

Thank very much

cabecinhas:
Well.. about my question.... I was actually looking for something that doesn't exactlty makes the upload.. just check instantly if the code is ok or have some error.

Do you know if I can find something like this?

The verify button on the IDE does this. It compiles the code, but does not upload it to the board. This can be useful if you are using a different means to upload code to the board, and just want the hex file that is produced. But it can also be used to find mistakes that the compiler points out.

MichaelMeissner:

cabecinhas:
Well.. about my question.... I was actually looking for something that doesn't exactlty makes the upload.. just check instantly if the code is ok or have some error.

Do you know if I can find something like this?

The verify button on the IDE does this. It compiles the code, but does not upload it to the board. This can be useful if you are using a different means to upload code to the board, and just want the hex file that is produced. But it can also be used to find mistakes that the compiler points out.

Hi, Michel. Thanks your your reply.

Well.. It helps a lot but I was trying to find a way to do the test and maybe print a debug, without having to upload..

I am afraid its not possible.

Tks anyway :slight_smile:

First programs written in basic using a real TTY and paper tape with a 30 baud (yes thirty) audio coupled modem. the paper tapes where produced using a blind coding desk (no printer to tell you what you had typed just the paper tape).

Great fun - it was a thursday afternoon extra when I was xx years old but the programs ran, there and then!

Mark

holmes4:
First programs written in basic using a real TTY and paper tape with a 30 baud (yes thirty) audio coupled modem. the paper tapes where produced using a blind coding desk (no printer to tell you what you had typed just the paper tape).

My very first program was wired onto a plugboard, on an IBM 6400 Electronic Accounting Machine. 32 words of memory, 32 words of alphabetic memory, relays controlled program flow.

I considered it quite an advancement when I wrote my first program on an IBM 360/30, in assembler, punched onto cards and loaded in on a 'fast' card reader (about 500 cards/minute.

We've come a long way!

cabecinhas:
The verify button on the IDE does this. It compiles the code, but does not upload it to the board. This can be useful if you are using a different means to upload code to the board, and just want the hex file that is produced. But it can also be used to find mistakes that the compiler points out.

Well.. It helps a lot but I was trying to find a way to do the test and maybe print a debug, without having to upload..

I am afraid its not possible.
[/quote]
Well, the verify button does exactly what you want. It will compile the code, and report any errors it finds. It does this quite quickly. I just did a quick test on a sketch that's about 8K in size. Compile/upload too about 9 seconds. Verify took justove 4 seconds.

And if you have any errors, it will tell you exactly where they are, and what they are.

@ lar3ry @ PaulS et al

From Monty Python

Four Yorkshiremen Sketch

Monty Python
Four well-dressed men sitting together at a vacation resort.
Michael Palin: Ahh.. Very passable, this, very passable.

Graham Chapman: Nothing like a good glass of Chateau de Chassilier wine, ay Gessiah?

Terry Gilliam: You're right there Obediah.

Eric Idle: Who'd a thought thirty years ago we'd all be sittin' here drinking Chateau de Chassilier wine?

MP: Aye. In them days, we'd a' been glad to have the price of a cup o' tea.

GC: A cup ' COLD tea.

EI: Without milk or sugar.

TG: OR tea!

MP: In a filthy, cracked cup.

EI: We never used to have a cup. We used to have to drink out of a rolled up newspaper.

GC: The best WE could manage was to suck on a piece of damp cloth.

TG: But you know, we were happy in those days, though we were poor.

MP: Aye. BECAUSE we were poor. My old Dad used to say to me, "Money doesn't buy you happiness."

EI: 'E was right. I was happier then and I had NOTHIN'. We used to live in this tiiiny old house, with greaaaaat big holes in the roof.

GC: House? You were lucky to have a HOUSE! We used to live in one room, all hundred and twenty-six of us, no furniture. Half the floor was missing; we were all huddled together in one corner for fear of FALLING!

TG: You were lucky to have a ROOM! We used to have to live in a corridor!

MP: Ohhhh we used to DREAM of livin' in a corridor! Woulda' been a palace to us. We used to live in an old water tank on a rubbish tip. We got woken up every morning by having a load of rotting fish dumped all over us! House!? Hmph.

EI: Well when I say "house" it was only a hole in the ground covered by a piece of tarpolin, but it was a house to US.

GC: We were evicted from our hole in the ground; we had to go and live in a lake!

TG: You were lucky to have a LAKE! There were a hundred and sixty of us living in a small shoebox in the middle of the road.

MP: Cardboard box?

TG: Aye.

MP: You were lucky. We lived for three months in a brown paper bag in a septic tank. We used to have to get up at six o'clock in the morning, clean the bag, eat a crust of stale bread, go to work down mill for fourteen hours a day week in-week out. When we got home, out Dad would thrash us to sleep with his belt!

GC: Luxury. We used to have to get out of the lake at three o'clock in the morning, clean the lake, eat a handful of hot gravel, go to work at the mill every day for tuppence a month, come home, and Dad would beat us around the head and neck with a broken bottle, if we were LUCKY!

TG: Well we had it tough. We used to have to get up out of the shoebox at twelve o'clock at night, and LICK the road clean with our tongues. We had half a handful of freezing cold gravel, worked twenty-four hours a day at the mill for fourpence every six years, and when we got home, our Dad would slice us in two with a bread knife.

EI: Right. I had to get up in the morning at ten o'clock at night, half an hour before I went to bed, (pause for laughter), eat a lump of cold poison, work twenty-nine hours a day down mill, and pay mill owner for permission to come to work, and when we got home, our Dad would kill us, and dance about on our graves singing "Hallelujah."

MP: But you try and tell the young people today that... and they won't believe ya'.

ALL: Nope, nope..

Mark

cabecinhas:
Hi, Michel. Thanks your your reply.

Well.. It helps a lot but I was trying to find a way to do the test and maybe print a debug, without having to upload..
I am afraid its not possible.
Tks anyway :slight_smile:

I must admit to not understanding why you are so reluctant to load the program on the machine. Sure, back in the day when I worked on ports of GCC targeting embedded machines, we would often times use a simulator, because the manufacturer hadn't yet made the silicon chip yet (since they were using our compiler to write the firmware, we often times needed to be done before the chip came out). Likewise, in bringing up new variants of machines and thinking about adding new instructions or modeling the current machine to identify problem areas, again we would use simulators.

And I'm old enough that I did start programming on cards, and in a few cases, we would have one shot that we gave the operator the card deck at night, and got the print out the next morning. That needed desk checks to verify stuff. Similarly, if you are talking to a computer in a space ship, or controlling millions of dollars of gear, you need to do extensive mock up testing before going on the real hardware.

But for a machine that costs $20, and you can load and run the program in a minute or two, I'm not sure I see the need to simulate the program before going to the hardware. When I'm writing Arduino/Teensy code, I put in Serial.print statements, and use the serial monitor to track the process of the program. Unfortunately, for ATtiny85 chips, you can't run the standard serial support, but there are other ways to debug it (there is a software serial support, and you can blink lights, etc.).

Sure, I miss having a real debugger on the Arduino, and if you had asked for that, my answer would be different, since that is something that is missing in the environment, but you were asking to simulate the program in software before getting to the real device, and with the device being easy to download the usual programs written for Arduinos, I don't see the need to delay getting to the hardware.

Now, if you use Linux, there is an older AVR simulator. I don't know whether it would work for programs using the Arduino infrastructure, or not, and it uses Motif which is kind of showing its age: http://avr.sourceforge.net/

The Atmel studio has a simulator as well: http://www.atmel.com/microsite/atmel_studio6/debugging_simulation.aspx and http://www.engr.sjsu.edu/~wdu/ME106Spring2010/LectureNotes/SimulatorTutorial.pdf

MichaelMeissner:
Sure, back in the day when I worked on ports of GCC targeting embedded machines, we would often times use a simulator, because the manufacturer hadn't yet made the silicon chip yet (since they were using our compiler to write the firmware, we often times needed to be done before the chip came out).

And you were lucky! Back in my day, we had to build the machine that would run the compiler to create the firmware for the machine that we used to build itself! Try figuring that little paradox out! :stuck_out_tongue_closed_eyes:

OP: Embedded programming is a bit of a different beast. Another fellow here asked for something similar recently. It seems those questions come from folks who are used to PC development, where you can poke around the program as it runs to make sure everything's going the way you planned. On embedded devices, you have to be a little more creative.

Get the darn program to compile first. Start small, with as little happening as you can manage. Begin by printing out a welcome message through the serial console. Once that works, add bits and pieces in until it stops working. Then undo the last change.

There's a huge difference between writing a program that runs but doesn't do what you want, and writing one that won't run at all. In either case, it might still compile just fine -- which is where you're "flying blind" a bit. Try not to do anything that might crash the program until after you've been able to print a "starting up" message via the serial console. That way, you can at least track the program's progress and narrow the fault down to a particular area or function call.

One thing you'll have to watch out for is RAM. It's very, very easy to use up all 2KB of RAM on an Uno, and then things go south. The program will technically run, but it will start behaving erratically. The exact symptoms depend on the layout of memory (which is very difficult to tell in advance), so in those cases you want to keep the program small and add things in until things that previously started working, stop working. Then you know you probably ran out of memory.

All of this takes a little getting used to, but there's currently no good substitute for running on hardware. Because it interacts with all the components that are plugged into it, you can't just emulate the CPU -- you have to simulate the entire working environment, which is often subject to chaotic influences (like noise and power issues) that wouldn't apply in a simulation until you thought to add them. And if you thought of this, you'd think of troubleshooting that in the hardware first.