Hi Gilles,

I think using multiple .ino files instead of cpp is a better solution for you.

It certainly will work and is a big part of Arduino. The thing to know is that only the sketchname.ino needs the library or other #includes.

All .ino files share everything and are automatically combined into a single cpp by the compiler.

So all functions and variables are shared between the .ino files. No need to do anything different to make it work. No need for extern etc.

I need to look into that it's not right. Which Ide are you using the intellisense works differently in them all.

Ok great that is clear for me thanks. I know functions work but forgot to check if the variables are coming through. 

I hope this can be forced in the next version of vm, it depends on how VisualAssistX works

Great. I usually issue beta versions in the beta channel just prior to an official release. This allows a more controlled test by approx 50 users per day. If I make a new official release everyone gets notified and then hundreds download it. Any bugs and my life ends 

I don't issue early beta's so it's usually ok to take. This one has been quite well tested now but I don't think it contains anything useful for you.

http://visualmicro.codeplex.com/releases/view/106554

It's mainly fixes for Atmel 6.2, better trace diagnostics, improved library support and workarounds for users with a corrupted windows wmi database. 

However the more people that test it the better 

Hi Gilles,

Quote:


You don't need to use cpp files there is a lot of support in Visual Micro to handle the complexities of a combined cpp. Yes there can be more but I think we can work through this with a little discussion.

It is wrong that the temp copy in the build folder was displayed, Visual Micro is supposed to handle that but a few variations sometimes slip through the net. I would like to see your code or similar and understand the error and where it was. 

Here is a simple test

I create a source called blink2.ino in my blink project. I added the following code with an error in the definition of a2. The compiler correctly gave me an error for the line and when I double clicked I was taken to it.

int a1;
int a 2;

void test()
{
}

void blah()
{
}
 

Some points to note.

Sometimes there is more than one line to an error. Clicking the lowest line is usually the one that you need.

By default, when you hit F5 for debug upload two compilations happen. 1) Your normal code, 2) your code with debug breakpoints. Sometimes the breakpoints can produce errors and Visual Micro does need to handle these better in terms of tying the errors back to the source

My bad  .

Here is the contents of MicroBuild:

Compiling 'UF_TSNOS_1' for 'Mega Pro 2560V 3.3V'
Build folder:
UF_TSNOS_1.ino:In function 'void ML12100()'
Menus.ino:2850: error: 'pResol' was not declared in this scope
Error compiling
 

If I click on the 3rd line - UF_TSNOS_1.ino... - I am brought to line 1 of this file which is the project .ino file.

But if I click on 4th line, - Menus.ino:2850... I am brought to the correct line in Menus.ino. 2850 is not the correct line number, but since the correct line is highlighted, that fine.

No one should code Arduino without AtmelStudio+VisualMicro  .

Hi Tim,

this morning again clicking on a compile error message does not bring me to the right code line  . I think it may not have to do with VisualMicro code.

Are you aware of any situation that could 'fool' VisualMicro ? I came across situations a few times to that would fool intellisense in VB for example. A line of code would break the editor and it behaved strangely.

My code compile and upload fine - when there is no obvious bug -, but it acts strangely. I get int variables corrupt when I manipulate strings and send them to an LCD by means of a serial port. The strings are global and the int are local, really weird. I know this look like out of this world, but I suspect a condition that  makes it way through the compiler but is wrong and induces issues.

Or maybe I drink to much water  .

Thanks

Tim,

I know well C and the ways strings are handled, and how you can easily poison your life  .

I started coding in C at the age of CP/M: 64K memory, and forget about IDE and breakpoint... stone age  .

I also came across a bug on a Rabbit  MCU where the compiler incorrectly handled strings, to solve the issue I had to reorder variables declarations. The time it took to find out that...

Well,

the bug has been located standing about 16" inches from the monitor .

It was a darn byte vector that was sized too small . It could have been a char string, I would have had the same issue. Every string is huge pitfall in C.

Arduino has a new String object that automatically grow itself, much like in old VB. I read that there are some glitches though. I have used it in another project, and found out that one method of the class behaves badly, that is length(): MyString.length() is equivalent to strlen(MyCharArray). Other than that , I was happy with it. It's very easy to use, with loads of methods like .substring() and .indexOf() for example. Reference is here http://arduino.cc/en/Reference/StringObject Higly recommended.

Sure, it uses more memory than conventional char arrays, but if your MCU has plenty of RAM and FLASH, it has many advantages.