Hi,

Read my posts, it workd but needs some tweaking (thats all).

As for VS2010 intellisense is a great feature ;-)

I found it strange that i can run the installer (without elevation) but need elevation if I run parts of it manually. No big deal (a clean install worked like charm).

wvd_vegt

Hi,

trying to compile the ticker sampe but get an error on:

1. include <agutil.h>

wvd_vegt

Wim, you probably just need to build the sample dependencies. Just go into your samples directory and run "make" from there. This will build all of the sample directories in the correct order to satisfy the build dependencies. Later you can just build each sample as you need unless you were to touch something like the agutil dependency.

Edit: Actually the missing dependency should give you a link error and not a compile error. You don't list the exact error you get but I am guessing it is related to not being able to find the agutil.h header. I would still try to run make (outside of Visual Studio) from the root of the samples directory and make sure that it is able to build everything successfully. The linker will require the agutil directory to be built before Ticker anyway so the proper make from the root will fix that.

Hope that helps.

Go for it!!

I won't be trying to get the LPC2368 board working since I don't have one and there were many times when working on LPC1768 support that I needed to debug the code on the actual device to figure out why it wasn't working and I plan to concentrate on mbed-LPC1768 development until my pre-ordered STM32 F4 board arrives:) I will however be more than happy to take the fruits of your labour and incorporate them into the gcc4mbed project.

That "Object has vendor-specific contents that must be processed by the 'ARM' toolchain" error doesn't look too promising to me either. I didn't encounter anything like that with the LPC1768 libraries.

Hi Adam,

That did the trick! Thanks (one step forward again!)

Wim

Hi all

First let me say thanks for this work. It's amazing to be able to compile off-line. I've been playing around with it and had no problem getting it up and running. However I have a problem with Serial, and I was wondering how much the mbed library is functional when used like this. I confess I know very little about this project as I only looked started playing with it last night. Anyways the issue I had is that at the beginning of my sample program I had written:

...

Serial pc(USBTX, USBRX); // tx, rx

int main() 
{
...
  pc.baud(115200); 
...

When built with the on-line compiler this works and you get all your debug printfs coming out at 115200, however when you use sourcery the UART0 remains stubbornly at 9600. I tried dumping the UART0 registers to a file (great thing that local file system works -interestingly opening for append works equally bad on-line off-line!) and you can see differences in the values between on-line and off-line compiled versions. Any ideas? how can I dig further? Maybe I am doing it all wrong anyways?

Cheers

Charles

Ah well I went away and thought about it for a bit. If you avoid using printf completely you can get USB serial port (UART0) to work at any speed. I guess the reason is that the on first use, the _OpenStandardHandles will be called and that in turn would reinitialise the UART0? just guessing. If so it might make more sense to always open the handles on init of a program. Just as very quick experiment I tried it and it normal printfs are now coming out at the desired speed :

diff --git a/src/gcc4mbed.c b/src/gcc4mbed.c
index 4696992..94c92f7 100644
--- a/src/gcc4mbed.c
+++ b/src/gcc4mbed.c
@@ -84,6 +84,10 @@ extern "C" __attribute__ ((section(".mbed_init"))) void __main(void)
     /* Initialize static constructors. */
      __libc_init_array();
 
+    _sys_open("/stdin", OPENMODE_R);
+    _sys_open("/stdout", OPENMODE_W);
+    _sys_open("/stderr", OPENMODE_W);
+
     /* Call the application's entry point. */
     ExitCode = main();
     
diff --git a/src/syscalls.c b/src/syscalls.c
index 0221238..8f3d150 100644
--- a/src/syscalls.c
+++ b/src/syscalls.c
@@ -256,10 +256,10 @@ extern "C" int _write(int file, char *ptr, int len)
     int BytesNotWritten;
     
     /* Open stdin/stdout/stderr if needed */
-    if (!g_StandardHandlesOpened && file < 3)
-    {
-        _OpenStandardHandles();
-    }
+    /* if (!g_StandardHandlesOpened && file < 3) */
+    /* { */
+    /*     _OpenStandardHandles(); */
+    /* } */

Obviously the above is hack, but wouldn't take much to clean it up

Cheers

Charles

Charles, good catch. Your change almost puts the code back to the way that I originally wrote it. I switched to the delay open to shrink the size of samples like HelloWorld which never use StdIO but would pay a large penalty for _sys_open()'s use of sscanf() which pulls in a lot of CRT code (including some floating point support) that isn't really needed.

I would have thought that you would need the _sys_open() calls to occur before __libc_init_array() so that the 9600 baud init happened before your global constructor for the Serial pc object was run to re-init to 115200 baud unless you moved the pc Serial object into main().

I will try to address this issue soon.

Edit: I am tracking this issue on github at https://github.com/adamgreen/gcc4mbed/issues/4

Heading camping this weekend, so not going to get a whole lot of time to work on anything, but thought I'd share my current project. It's a work in progress. I've never used NSIS before, still ironing out the kinks...

(Basically a GUI-fied version of the batch file)

Hi Adam

Had not realised about the size issue, and not sure how it could be worked round. On the the constructor question, the suggestion makes sense, but it's not the Serial constructor which initialises the UART to 115200, it is the baud function which I was calling from main. But I guess in general it would be safer to do as you suggest.

Cheers

Charles

Ahh, that makes sense.

I just cleared some other gcc4mbed issues off of my list and this one is next. I am going to try playing around with a few ideas to see if I can fix your issue and not blow the size of HelloWorld up :)

Hi Adam, All,

This is awesome work! Nicely done!

We'll work on getting you an mbed-official gcc-compatible release of the libraries in the next few weeks if you're up for testing, so you don't need to do the annoying patching of the libraries, plus we can make sure all the corner cases really do work.

Cheers, Simon

Hi Simon

Official Support: Great news!

Can you add my two small Visual Studio related fixes too (the snippets containing the GCCFIXUPS define so IntelliSense works in VS2010)?

Wim van der Vegt

Hi Adam

After Simon's welcome announcement this could be totally irrelevant. As I am not that experienced with gcc/ld and I was curious to learn more I played around and got a solution. It might be a bit too hacky but it did seem to solve the problem generating smaller binaries on programs that don't use stdio, and allowing you to have a call to printf (et al) and Serial::baud work as expected. Basically I wrapped the Serial::baud symbol so that if it gets called before a stdio read/write it will open the standard handles. Otherwise it works as before. So the first to run, Serial::baud or printf/scanf..., will be the first to open the handles. my wrapped baud then calls the original version. The binaries for HelloWorld seem to shrink from 72k to 24k, and my test code which calls baud before printf, and the StdIO sample, seemed to work. Here is a patch delta:

diff --git a/build/gcc4mbed.mk b/build/gcc4mbed.mk
index 6b4e16d..f8d1a2d 100644
--- a/build/gcc4mbed.mk
+++ b/build/gcc4mbed.mk
@@ -80,7 +80,7 @@ GPFLAGS = -O$(OPTIMIZATION) -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork
 GPFLAGS += $(patsubst %,-I%,$(INCDIRS))
 GPFLAGS += $(DEFINES)
 
-LDFLAGS = -mcpu=cortex-m3 -mthumb -O$(OPTIMIZATION) -Wl,-Map=$(PROJECT).map,--cref,--gc-sections,--no-wchar-size-warning -T$(LSCRIPT) -L $(EXTERNAL_DIR)/gcc/LPC1768
+LDFLAGS = -mcpu=cortex-m3 -mthumb -O$(OPTIMIZATION) -Wl,-Map=$(PROJECT).map,--cref,--gc-sections,--wrap=_ZN4mbed6Serial4baudEi,--no-wchar-size-warning -T$(LSCRIPT) -L $(EXTERNAL_DIR)/gcc/LPC1768
 
 ASFLAGS = $(LISTING) -mcpu=cortex-m3 -mthumb -x assembler-with-cpp
 ASFLAGS += $(patsubst %,-I%,$(INCDIRS))
diff --git a/src/gcc4mbed.c b/src/gcc4mbed.c
index 4696992..8a6eced 100644
--- a/src/gcc4mbed.c
+++ b/src/gcc4mbed.c
@@ -91,3 +91,15 @@ extern "C" __attribute__ ((section(".mbed_init"))) void __main(void)
     exit(ExitCode);
 }
 
+
+extern "C" void OpenHandlesIfNeeded();
+
+extern "C" void __wrap__ZN4mbed6Serial4baudEi(int) __attribute__((naked));
+void __wrap__ZN4mbed6Serial4baudEi(int)
+{
+  asm("push {r0,r1,lr}"); // maybe should pad to 32
+  asm ("bl OpenHandlesIfNeeded");
+  asm("pop {r0,r1,lr}"); 
+  asm("b __real__ZN4mbed6Serial4baudEi");
+}
+
diff --git a/src/syscalls.c b/src/syscalls.c
index 0221238..fb14f63 100644
--- a/src/syscalls.c
+++ b/src/syscalls.c
@@ -57,6 +57,10 @@ static void _OpenStandardHandles(void)
     g_StandardHandlesOpened = 1;
 }    
 
+extern "C" void OpenHandlesIfNeeded() 
+{
+  if (!g_StandardHandlesOpened) _OpenStandardHandles();
+}
 
 extern "C" int _kill(int pid, int sig)
 {

Cheers

Charles

Hi,

Any luck yet with Netbeans?

Btw maybe monodevelop at http://monodevelop.com/ is a nice one to try (it should support C++). Or http://bloodshed.net/dev/devcpp.html

Small update, monodevelop can be used but without syntax highlighting and code completion (so not much better than notepad+console window ;-).

Next update, Netbeans seems tricky. You need to edit quite some xml files before it notices the arm toolchain.

Last update, for devcpp I found (but did not try yet) a document telling how one can setup the Arm Gcc toolchain. See http://www.bloodshed.net/dev/SetDevCPPArm.pdf

After last update, in devcpp, if you just point to cs-make.exe ion Tools|Compiler Options|Programs and set Project Options (right click project)|MakeFile to ise custom makefile and select the makefile it starts to work and you can compile. You need to add some directories to a) the C++ include paths too (external\mbed, external\mbed\lpc1768 and arm-none-eabi\include\c++\4.5.2) and b) to the C path (arm-none-eabi\include) and c) the libraries path (arm-none-eabi\lib) and d) binaries (the bin directory).

Wim

I have test it with my TFT touch projekt. http://mbed.org/users/dreschpe/notebook/micro-paint/

- Export the code and unpack into a new dir in the sample folder.

- If you use a imported lib, open the .lib file. There is a link to get the lib. Download the lib and unpack also.

- copy the makefile from the HelloWorld.

- change the project name inside

- start shell.bat

- go inside the project dir

- make

bingo it works.

The code is bigger: ARM 42K, GNU 83K, but it works.

Peter

Peter, that is awesome news. I am happy to hear that it worked for you.

I am in the process of updating the README for gcc4mbed. Do you mind if I include your steps for pulling down your own project?

Simon, that's awesome news! Emilio is rocking the house.

Thanks,

Adam

Hello Adam, feel free to use the steps to describe the export of a project to gcc. My next step was a little to optimistic. I try to port my biggest project to GCC. It is using nearly all things : SDHDFilesystem, Ethernet server with RPCInterface, internal filesystem ... I came across one thing we have to handle with a define to get it working on both compilers. The packed atribute is used different. The ARM compliler use:

__packed struct P_AB {  
....
};

GCC want

struct P_AB {
....
}__attribute__ ((packed));

With a #define GCC and a #if #else construct we can handle this.

At the moment I have a problem inside the RPCInterface. The gnu compiler is handlig the scope of some vars different than the arm compiler. I get a error in RPCInterface/RPCVariable.h 93:119. RemoteVar was not declared in this scope ... ?

Peter

Thanks Peter. I have updated the documentation on this site and github to add in a link to the beginnings of some porting notes which so far just include notes based on your posting. It can be found here: https://github.com/adamgreen/gcc4mbed/blob/master/notes/porting.creole#readme

I also pushed up some commits for issues that people reported here and on github over the last couple of weeks and added a Quick Start section to http://mbed.org/users/AdamGreen/notebook/gcc4mbed/.

Charles, I fixed the stdout/stdin/stderr with a change that was very similar to your first solution. I moved the handle open up before the static constructors get run and then have a variable that is set in samples like HelloWorld to revert to the old behaviour so as not to bloat them.

-Adam

Hi

For those interested in trying Visual Studio 2010, the free C++ Express version can be downloaded from http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express

With the two proposed code changes and the projext settings mentioned earlier in this thread you get mBed support including Visual Studio's Code Completion.

wvd_vegt

wvd_vegt

Have you hooked it up to VS2010 yet? I'd like to try but not sure how to integrate it into studio. I also tried running the stuff on here the other day and it gave a whole slew of errors and I didnt have time to debug but maybe now I will get after it.

What is the process for getting external compiler hooked to VS2010? I will be the guinea pig and try it posting my results/comments.

THanks

hi,

Just scroll back to page one of this thread and read my steps in

http://mbed.org/forum/mbed/post/13912/

You have to install the offline version and make two source modifications & change the make.bat file a bit.

Then you can create VS solotions and projects and adjust project settings there so everything works like charm.

The results is that you can:

1) off-course compile (build project will call the make.bat file). 2) have intellisense on mbed c++ (including libraries) 3) have vs check the syntax when not building. 4) have vs handle source control. etc

So no guinea pigs neccesary it seems to work fine (but comments or improvents are welcome ;-).

Ideally would be that the mBed website would generate a solution/project file for VS (for example Unity3D does that and so allows you to use VS for editing in their game development environment).

Wim

Incase you haven't seen it yet, Simon is currently looking for alpha testers of mbed's upcoming officially supported GCC build process in this posting: http://mbed.org/forum/bugs-suggestions/topic/2796/

I just pushed up a fix to the gcc4mbed install scripts on Windows for a problem first reported by Peter Drescher where cs-make would attempt to use Cygwin's shell instead of the expected cmd.exe.

If you tried installing gcc4mbed on Windows before and got the following error, then it should now be fixed:

win32\applydiff --binary -p1 <mbed.patch
/usr/bin/sh: win32applydiff: command not found
cs-make: *** [patch_mbed] Error 127

Thanks to mbed user klaxon44 for answering a bunch of questions today so that I could reproduce this issue on my Windows machine and attempt a fix.

I am looking for some help from the mbed community with a gcc4mbed addition that I am currently working on. It's called MRI, Monitor for Remote Inspection, and is a debug stub which allows gdb to attach and debug code running on the mbed 1768 device.

I have some questions related to this project:

• Is the community interested in having a debugger solution for the mbed?
• Are there members of this community which are experienced with using command line mode gdb and would be willing to help me out with the alpha testing in a month or so?
• For the beta testing, what GUI frontend would the community like to see supported? I am not the biggest fan of the Eclipse IDE but if that is what the community wants, that is what I will initially support. We can always add support for additional front ends later.
• This will probably only work for gcc4mbed built projects where it is easy to control how the debug stub gets linked into the final binaries, what tools are used for compiling/debugging, and the symbols that are generated for the resulting binary. Does this make the mri debug stub useless to the community?

This is a sample gdb session giving a taste of what mri already supports:

/depots/mri/samples/HelloWorld$ arm-none-eabi-gdb HelloWorld.elf --baud 115200
Reading symbols from /depots/mri/samples/HelloWorld/HelloWorld.elf...done.
(gdb) target remote /dev/tty.usbmodem412
Remote debugging using /dev/tty.usbmodem412
__main () at ../../src/gcc4mbed.c:97
97	    __debugbreak();
(gdb) bt
#0  __main () at ../../src/gcc4mbed.c:97
#1  0x000014f4 in Reset_Handler ()
(gdb) break main
Breakpoint 1 at 0x736: file main.cpp, line 24.
(gdb) c
Continuing.
Note: automatically using hardware breakpoints for read-only addresses.

Breakpoint 1, main () at main.cpp:24
24	    volatile int IterationCount = 0;
(gdb) n
28	        myled = 1;
(gdb) p IterationCount
$1 = 0
(gdb) n
29	        wait(0.2);
(gdb) 
30	        myled = 0;
(gdb) 
31	        wait(0.2);
(gdb) 
32	        IterationCount++;
(gdb) 
26	    while(1) 
(gdb) p IterationCount
$2 = 1
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x00011348 in wait ()
(gdb) bt
#0  0x00011348 in wait ()
#1  0x0000074c in main () at main.cpp:29
(gdb) 

If you need to see inside your Cortex, get an MRI!

Thanks for your help,

Adam

Hi all, I have some problems to have internet access these two weeks. So I tried to install it using both way, the one given in the home page, and the one given here.

The first one stops here and I am always waiting: Installing mbed libs and headers...

And the second one seems to install it correctly but when I tried to make the sample directory I got this error: C:\Users\thierry\Downloads\installer\samples>make cs-make -C agutil cs-make[1]: Entering directory `C:/Users/thierry/Downloads/installer/samples/agu til' arm-none-eabi-gcc -O2 -gdwarf-2 -mcpu=cortex-m3 -mthumb -mthumb-interwork -fshor t-wchar -ffunction-sections -fdata-sections -fpromote-loop-indices -Wall -Wextra -Wimplicit -Wcast-align -Wpointer-arith -Wredundant-decls -Wshadow -Wcast-qual -Wcast-align -Wnested-externs std=gnu99 -I../../external/mbed -I../../externa l/mbed/LPC1768 -I../../external/FATFileSystem -I. -DTARGET_LPC1768 -c debug.c - o debug.o debug.c:18:19: fatal error: error.h: No such file or directory compilation terminated. cs-make[1]: * [debug.o] Error 1 cs-make[1]: Leaving directory `C:/Users/thierry/Downloads/installer/samples/agut il' cs-make: * [agutil] Error 2

C:\Users\thierry\Downloads\installer\samples>

Any idea?

I don't know what method this is but it is probably not one I support anyway. I am guessing that your first approach which hung matches what you find at this link: https://github.com/adamgreen/gcc4mbed#quick-start. Is that correct? If so, it looks like it is hanging when I use Subversion to pull down the libraries/headers from the mbed.org site. Do you get a prompt for a Authentication Realm password at this time? If so, just press Enter at the prompt. I have seen the actual Subversion command hang due to some issue in Subversion and/or the mbed.org site hosting the repository. This can typically be fixed by just running the process again. If you try running it again and it hangs in the same spot, can you post the contents of your win_install.log between code tags like this so that no escaping is done to the output:

<<code>>
Insert the contents of your win_install.log between the <<code>> and <</code>> tags here.
<</code>>

Hi there,

Those instructions probably need to be updated since our upgrade to support mercurial (http://mbed.org/blog/entry/Collaboration-update-now-live/)

To download the mbed library using mercurial, you want to do:

 hg clone http://mbed.org/users/mbed_official/code/mbed/

Hope that helps,

Dan

Thierry, just try rerunning the existing script. Don't attempt to use Dan's Mercurial suggestion. That won't be compatible with the current master branch of the gcc4mbed project.

Dan, thanks for the heads up. I will switch future branches of gcc4mbed to source the mbed libraries from Mercurial instead of Subversion.