Go Down

Topic: UECIDE: A New Fork of the IDE (Read 59397 times) previous topic - next topic

pito

#255
Jul 21, 2013, 09:48 pm Last Edit: Jul 21, 2013, 10:21 pm by pito Reason: 1
1. No line numbers there..
2. when the board's folder is not available and pragma points to it, the compilation freezes
3. the plugin manager upgrades Grapher even there is no grapher.jar downloaded and placed into plugin directory
4. decrease indent does not decrease the indent

majenko

1. Yes there were, you just couldn't see them - grey on grey.
2. It now refuses to select a board that doesn't actually exist.
3. I can't get that top happen.  If grapher is installed and out of date it upgrades.  If it's not installed, it doesn't upgrade.
4. Yes, I know - that is a problem I am working on.  It used to be done manually by the code, but now the editor does it itself.  Getting the menu to do it though is proving tricky.  Just use shift-tab for now - that works fine.

pito

Save:
1. maybe it shall Save when compiling or uploading automatically
2. autosave option would be nice to have

majenko


Save:
1. maybe it shall Save when compiling or uploading automatically
2. autosave option would be nice to have

No, I don't think so.  Firstly, that's not what the Arduno IDE does, and UECIDE has to maintain some semblance of being like the Arduino IDE.  Secondly you don't want to make an experimental change, compile and upload to see if it works, find it doesn't, then not be able to reload the old version that did work because it's now been overwritten by the new broken version without you asking it to.

Now, an auto-archiving module which saves the sketch to another location with versioning so you can then go back say the last 10 versions, that would be more useful.

All these kind of things can be done as modules.  I need to focus on getting the main core system working right first.

majenko

I have just made some major changes to the compilation system.  Changes for the better I hope.

Libraries and the core are now compiled separately from the sketch.  They are compiled into proper .a files (named libXXX.a, where XXX is the name of the library, or "core") and cached in a per-core-per-board cache directory.  On linux that's .uecide/cache/<core>/<board>, and windows it's the uecide folder in AppData (or whatever convoluted place it sticks it).

If any library or core files are found to be newer when the sketch is compiled it recompiles just those changed files and replaces them in the library.  If nothing has changed, then there's nothing to do, so nothing is done.

The sketch is then linked against those cached libraries (with -lcore -lSPI etc).

Extensions (like Cosa) are also compiled like the core into their own separate library file and cached, named after the folder the extension is in.  So, for Cosa with "#pragma parameter extension=/home/matt/git/Cosa" you would end up with a libCosa.a which the sketch gets linked against.

These cached files persist until they are deleted, so once you have used a library, core, or extension for the first time on a board, from that point on compiling becomes lightningly quick, as all it needs to do is compile and link the sketch, and convert the elf to whatever output files are needed.

To force a re-compile of all libraries, cores, etc, just delete the .uecide/cache folder - it will be recreated the next time you compile.  I may add an option somewhere to do that at the press of a button.

All this does mean that the format of the core.txt file has changed slightly with regards to some of the recipes.  Please download the complete package rather than the upgrade, or you won't be able to compile.  Also, any extra cores you have installed will need to be upgraded before you can compile with them.

In brief, the changes are:

1. The combine recipe now does not reference core.a, but instead has ::-L${libraries.path}::${libraries} appended - libraries.path is the path of the board specific cache folder, and libraries is the list of -l... entries for linking.
2. The ar recipe also doesn't reference core.a, but instead references ${library} which points to the library file (.a) that is being worked on at that time.

pito

#260
Jul 22, 2013, 03:41 pm Last Edit: Jul 22, 2013, 03:57 pm by pito Reason: 1
Cool!
Cosa examples need 2-3 secs to build now. One thing to this: Would it be possible to set the .a cache path similarly as we do with Sketchbook? To minimize places all the stuff is stored..
Ie. in preferences:
Code: [Select]
Cache location:
C:\MyCode\Arduino


So it stores cache in:
Code: [Select]
C:\MyCode\Arduino\cache\avr105\mighty1284p
instead of
C:\Documents and Settings\pito\Application Data\uecide\cache\avr105\mighty1284p

majenko


Cool!
Cosa examples need 2-3 secs to build now. One thing to this: Would it be possible to set the .a cache path similarly as we do with Sketchbook? To minimize places all the stuff is stored..
Ie. in preferences:
Code: [Select]
Cache location:
C:\MyCode\Arduino


So it stores cache in:
Code: [Select]
C:\MyCode\Arduino\cache\avr105\mighty1284p
instead of
C:\Documents and Settings\pito\Application Data\uecide\cache\avr105\mighty1284p



I can see no reason why not...  I'll be moving plugins, cores and boards to that same uecide directory at some point in the future, away from the sketches.

pito

#262
Jul 22, 2013, 06:32 pm Last Edit: Jul 22, 2013, 07:41 pm by pito Reason: 1
I've been trying to build the another larger example: nilSdLogger.ino from the latest NilRTOS distro. I copied the 5 distro libraries (SdFat, NilRTOS, TwiMaster, NilTimer1 and NilAnalog) into my sketchbook \libraries.
The IDE152 does compile the stuff:

Code: [Select]
c:\MyCode\Arduino\ABuild/nilSdLogger.cpp.hex
Binary sketch size: 14,272 bytes (of a 32,256 byte maximum) - 44% used


with uecide I get (cache cleaned before build, for uno) while linking libraries:

Code: [Select]
C:\Documents and Settings\pito\Application Data\uecide\cache\avr105\uno\libSdFat.a(Sd2Card.o): In function `Sd2Card::chipSelectHigh()':
C:\MyCode\Arduino\libraries\SdFat/Sd2Card.cpp:181: undefined reference to `digitalWrite'
C:\Documents and Settings\pito\Application Data\uecide\cache\avr105\uno\libSdFat.a(Sd2Card.o): In function `Sd2Card::chipSelectLow()':
C:\MyCode\Arduino\libraries\SdFat/Sd2Card.cpp:188: undefined reference to `digitalWrite'
C:\Documents and Settings\pito\Application Data\uecide\cache\avr105\uno\libSdFat.a(Sd2Card.o): In function `Sd2Card::begin(unsigned char, unsigned char)':
C:\MyCode\Arduino\libraries\SdFat/Sd2Card.cpp:266: undefined reference to `pinMode'
C:\MyCode\Arduino\libraries\SdFat/Sd2Card.cpp:267: undefined reference to `digitalWrite'
C:\Documents and Settings\pito\Application Data\uecide\cache\avr105\uno\libSdFat.a(SdSpiAVR.o): In function `SdSpi::begin()':
C:\MyCode\Arduino\libraries\SdFat/SdSpiAVR.cpp:24: undefined reference to `digitalWrite'
C:\MyCode\Arduino\libraries\SdFat/SdSpiAVR.cpp:27: undefined reference to `pinMode'
C:\MyCode\Arduino\libraries\SdFat/SdSpiAVR.cpp:28: undefined reference to `pinMode'
C:\MyCode\Arduino\libraries\SdFat/SdSpiAVR.cpp:29: undefined reference to `pinMode'
C:\MyCode\Arduino\libraries\SdFat/SdSpiAVR.cpp:30: undefined reference to `pinMode'

majenko

That's what I love about you - you always manage to find some strange piece of code to break things ;)

In this case it's the order the libraries are linked - I really don't know why the linker is incapable of working this out for itself.  Put -lcore last and it all works fine.  Put it first, and it can't find some things that are in -lcore.  It's a bit stupid really.  Still, I have tweaked it now so it is <imported libs> <extension> <core> instead of <core> <extension> <imported libs>.

pito

ok with 63b
Code: [Select]
Program Size:
  Flash: 43% (14180 bytes out of 32256 bytes max)
    RAM: 1775 bytes

pito

#265
Jul 22, 2013, 08:30 pm Last Edit: Jul 22, 2013, 09:22 pm by pito Reason: 1
Now the ChibiOS is under test :)
With IDE152 it compiles fine
Code: [Select]
c:\MyCode\Arduino\ABuild/chFifoDataLogger.cpp.hex
Binary sketch size: 14,942 bytes (of a 32,256 byte maximum) - 46% used

with uecide I get while compiling (chFifoDataLogger.ino):
Code: [Select]
chFifoDataLogger.cpp:3: error: 'msg_t' does not name a type..

IDE152 chFifoDataLogger.ccp :
Code: [Select]
#line 1 "chFifoDataLogger.ino"
// Data logger based on a FIFO to decouple SD write latency from data
// acquisition timing.
//
// The FIFO uses two semaphores to synchronize between tasks.

#include <ChibiOS_AVR.h>
#include <SdFat.h>
//
// interval between points in units of 1024 usec
#include "Arduino.h"
static msg_t Thread1(void *arg);
void setup();
void mainThread();
void loop();


uecide chFifoDataLogger.ccp :
Code: [Select]
#include <Arduino.h>

static msg_t Thread1(void *arg);
void setup();
void mainThread();
void loop();

#line 1 "chFifoDataLogger.ino"
// Data logger based on a FIFO to decouple SD write latency from data
// acquisition timing.
//
// The FIFO uses two semaphores to synchronize between tasks.

#include <ChibiOS_AVR.h>
#include <SdFat.h>


majenko

Am I missing a trick here?  ChibiOS doesn't appear to be anything that can run under the Arduino IDE...

pito

#267
Jul 22, 2013, 09:21 pm Last Edit: Jul 22, 2013, 09:25 pm by pito Reason: 1
See above the difference in cooking the first lines in .cpp
uecide messes the first lines somehow, therefore the error on the line 3 above in .cpp

Chibios - yes, there is ChibiOS for arduino:
http://forum.arduino.cc/index.php?topic=176757.msg1311478#msg1311478

majenko

Goddamn Arduino breaking standards and encouraging lazy programming!

I hate it,  HATE IT HATE IT HATE IT HATE IT HATE IT!!!

Functions should be ALWAYS defined BEFORE they are used, or the USER should put in a forward reference prototype for them.

I fail to see how this is even possible to do whilst still maintaining some semblance of normality.  I guess the 1.5.2 IDE mercilessly rips out the #include lines from your program and dumps them unceremoniously at the top before it spams the program with prototypes that should never be there.  Who knows what order those #includes will now be in!  It's no wonder you can't affect the content of a #include with a #define if it goes and messes them around like that.  The whole system is just bloody stupid.

Turn off adding of the prototypes, and add your own prototypes where needed.  It's not my fault that Arduino have taught people to write programs badly.

*grump*

majenko

You cannot go moving #include lines around willy nilly.  What if you have a #include file referenced partway through your file?  Perfectly legitimate.  Does that get moved to the top?  Does that then break your program?  Or do you try and insert the prototypes between the includes and the start of the program?  Again, what if there#s a #include partway through the file?  Do the prototypes then get put in after that, partway through the program?  How can that possibly work?  The whole thing is a major piece of hacky cack that should be removed completely.

Go Up