chipKIT® Development Platform

Inspired by Arduino™

Uecide & Arduino_Due

Created Wed, 23 Apr 2014 09:45:27 +0000 by tcsaba101

tcsaba101

Wed, 23 Apr 2014 09:45:27 +0000

I couldn't resist to buy an Arduino Due board, for 26$. It will be good for a coming project where a built in DAC is a gift.

Compiling doesn't work in uecide. It works in Arduino 1.5.6-r2 IDE. Compiling, uploading, working.

Uecide setting to "SAM3X Arduino Due programming port" stucks forever in "Compiling Sketch..." status, with the console message, 'Due_listing.txt' what I have uploaded to Majenko's ftp server's incoming folder.

There are HUngarian words in the listing....., but maybe it is enough to find the bug.

The same Uecide reconfiguring to uC32 board, compiling, uploading withiout glitch.

majenko

Wed, 23 Apr 2014 10:24:25 +0000

java.io.IOException: Cannot run program "C:\Program Files (x86)\Majenko Technologies\UECIDE\Uecide settings\compilers\arm-sam-gcc/bin/arm-none-eabi-g++" (in directory "C:\Users\CSABA~1.TMA\AppData\Local\Temp\build-f2bdd7f0-1f31-4dae-968e-323d5517eab1"): CreateProcess error=193, %1: nem Win32 alkalmaz<C3><A1>s

That looks like the main problem here... WHat is "nem Win32 alkalmaz<C3><A1>s" in English? Not a win32 application?

majenko

Wed, 23 Apr 2014 10:28:44 +0000

Ok, yes I am seeing the same problem on Windows. Looking into it now.

majenko

Wed, 23 Apr 2014 10:48:41 +0000

Ok, this is bizarre.

Copy and paste the command line from the debug console and it works. Run from inside UECIDE and it says its not a Win32 application. The lm4f compiler (stellarpad), which is essentially the same compiler (arm-non-eabi) works perfectly. I don't understand this at all.

majenko

Wed, 23 Apr 2014 10:59:06 +0000

Oh hang on, I think I see the problem. What th **** have Arduino done with this compiler installation...?!

arm-none-eabi-gcc.exe:       PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows
arm-none-eabi-gcc:           Mach-O executable i386
arm-none-eabi-gcov.exe:      PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows
arm-none-eabi-gcov:          Mach-O executable i386
arm-none-eabi-gdb.exe:       PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows
arm-none-eabi-gdb:           Mach-O executable i386
arm-none-eabi-gdbtui:        Mach-O executable i386
arm-none-eabi-g++.exe:       PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows
arm-none-eabi-g++:           Mach-O executable i386

It seems the Windows compiler archive also contains the Mac compiler. No wonder it's so bloated.

That's going to need manually cleaning up I think...

majenko

Wed, 23 Apr 2014 11:13:07 +0000

Ok, I have enhanced the packaging system to remove all those rogue files. If you uninstall the current SAM compiler then install it again it should magically start working.

tcsaba101

Wed, 23 Apr 2014 19:27:19 +0000

That looks like the main problem here... WHat is "nem Win32 alkalmaz<C3><A1>s" in English? Not a win32 application?

You understand Hungarian!!!..?

Ok, I have enhanced the packaging system to remove all those rogue files. If you uninstall the current SAM compiler then install it again it should magically start working.

I did 2 times, the same problem: it stucks in Compiling phase, I have got a different listing, I have placed in your ftp folder. Unfortunately you have to brush your Hungarian, ;) because I couldn't find how to switch to english listing. I can change the input language, but the output language doesn't change.

Many thanks!!..

majenko

Wed, 23 Apr 2014 19:44:16 +0000

Hmmm... can't replicate that one.

I have even set mine up the same as yours (I think), and it executes the files fine.

Question: are you using the --datadir option, or the settings in preferences to change where it stores the files?

tcsaba101

Wed, 23 Apr 2014 21:26:53 +0000

Yes, I use it.

That was a development in 0.8.5a. It solved the problem to have more instances of Uecide in different versions.

Anyway I haven't tried former version about Due.

majenko

Wed, 23 Apr 2014 23:42:53 +0000

Nope, just can't get it to fail now. I have a fresh shortcut with --datadir set to the exact same as you, and it all works perfectly.

All I can suggest is manually delete all references to the Due and it's compiler, and reinstall it again. Maybe as a test set up a new shortcut with a new datadir location and do a fresh install into that to see if it works.

tcsaba101

Fri, 25 Apr 2014 04:52:14 +0000

Many thanks. I did your proposal, it works now, both Due and chipKIT boards.

But now I see the new setup data went in the ....\Appdata\Roaming directory in spite of the --datadir pointing to other directory. The datadir directory also has content, only chipKIT setups.

If I understood well:

  1. I have to copy the content of Roaming\uecide to the --datadir directory
  2. Change the Uecide, Preferences, Locations to --datadir links Then it will use the --datadir directory? I will try.

That means the preferences setup has priority, and what ..datadir setup does in this case? Please explain!

Thank you!

majenko

Fri, 25 Apr 2014 10:34:36 +0000

You shouldn't copy anything anywhere. When you specify --datadir, if the folder you specify doesn't exist it is created for you. All downloads and preferences then get stored directly in there.

It is primarily aimed at moving your preferences file - if you copy an existing one in there from somewhere else then those settings may override it, if that preferences file contains locations for things like cores, etc. If the preferences does not contain any locations for those items (and the default preferences doesn't contain any) then the --datadir is used as a default.

I suspect that in copying your Roaming settings into your --datadir folder you inadvertently placed some override settings that pointed it back to the Roaming folder.

The order of precidences is:

preferences.txt:

  1. --datadir
  2. System default

Cores, compilers, boards & plugins:

  1. Preferences
  2. --datadir
  3. System default

Hope this helps clear things up.

tcsaba101

Fri, 09 May 2014 20:52:22 +0000

Thanks.

I didn't want to install again, so I copied the content from Roaming to the -datadir location....... It works.

Just a question: My code is going to be longer and longer, I should break it to separate files and concatenate for compiling.

In Arduino reference has been declared the multi sketch mode. This is not working in Uecide.

How to break up the code to separate files, storing on the tabs of uecide. What extension should be used for the auxiliary files?

I would separate the definitions and some similar tasks from the main part.

Csaba

majenko

Fri, 09 May 2014 22:17:51 +0000

Thanks. I didn't want to install again, so I copied the content from Roaming to the -datadir location....... It works. Just a question: My code is going to be longer and longer, I should break it to separate files and concatenate for compiling. In Arduino reference has been declared the multi sketch mode. This is not working in Uecide. How to break up the code to separate files, storing on the tabs of uecide. What extension should be used for the auxiliary files? I would separate the definitions and some similar tasks from the main part. Csaba

There's two ways of splitting the sketch, and both need care and attention.

The first way is the "Arduino" way. It works, kind of.

All the .ino or .pde files in your sketch are joined together into one huge .cpp file for parsing. The latest versions of UECIDE do this as the main sketch file coming first, followed by all the others in alphabetical order. Then the mega-file is parsed and all the function prototypes, etc, are generated and inserted at the top.

Includes should only be in the main file, and never in any of the others, or they end up included part way through the .cpp file - the same with any globals, structs, etc.

This mode is selected by default. In Preferences you can turn it off (Compiler -> Combine all INO/PDE files into one .CPP file).

With it turned off you get to do it the proper C way. Each .ino (or .pde) file is a completely separate unit. Anything you want to share between them has to be done with the "extern" keyword. It can be useful to have each .ino file with its own .h file with the functions and variables in it you want to share tagged as extern, then you just include that .h file into each .ino you want to use those functions in.

I would recommend doing it that way as it gets you out of bad Arduino-imposed programming habits and starts to teach you proper programming structures.