This thread discusses trying to use a different free tool set to program the UDOO Due. The Due is built around an ARM Cortex-M3 Atmel ATSAM3X8E MCU. The Atmel® Software Framework (ASF) is a MCU software library providing a large collection of embedded software for Atmel flash MCUs: megaAVR, AVR XMEGA, AVR UC3 and SAM devices. see http://www.atmel.com/tools/AVRSOFTWAREFRAMEWORK.aspx?tab=overview Atmel® Studio 6 is the integrated development platform (IDP) for developing and debugging Atmel ARM® Cortex®-M processor-based and Atmel AVR® microcontroller (MCU) applications. It includes the Atmel ASF in its installation. Although Atmel Studio 6 is based on Eclipse, it currently only runs on Windows. It you are using a Windows machine for your development, then its probably the way to go. If you are a Linux user like me, then you have to use something else. I decided to try to set-up an Eclipse based IDE on my Linux Mint Debain edition PC for programming the SAM3X8E on the UDOO. I'll try to document my progress, albeit slow at times, in this thread. My reason for doing this: Some of us have been having problems getting the I2C interface to work. The ASF has its own SAM drivers for twi(i2c) which 'may' give better results (no promises yet until its tested). Here's some documentation for the ASF twi interface library http://asf.atmel.com/docs/latest/sam3x/html/group__sam__drivers__twi__group.html My progress so far: I downloaded and extracted the Atmel ASF I've downloaded and installed Eclipse Kepler CDT from here: https://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/keplersr2 Older versions will not work with the current Eclipse ARM plugin, so I couldn't use what my debian distro provides. I installed everything under my /home/useracct. I installed the ARM plugin by following the instructions here: http://gnuarmeclipse.livius.net/blog/plugins-install/ this is installed through the Eclipse Help->"Install New Software" menu. I installed the GNU ARM toolchain described here https://launchpad.net/gcc-arm-embedded from here: https://launchpad.net/gcc-arm-embed...m-none-eabi-4_8-2014q1-20140314-linux.tar.bz2. Note that ASF and the Eclipse ARM plugin will work with several different toolchains I next successfully compiled an "hello World" program (it prints to stdout, where ever that is on the SAM3X8E). It created an 'elf' file (https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) . Without setting up all the plugin options, I added a post build step to create a binary file from the elf. I then took the UDOO Bossac, created a custom external tool command in Eclipse, and successfully loaded the Hello world binary into the UDOO SAM3X8E. However, I can't tell if its actually running since it doesn't output anything that I can look at. Next Steps See if the objcopy post build step (elf -> -bin) can be setup in the ARM plugin. See if the bossac ext tool to upload the UDOO SAM3X8E can also be integrate into the plugin. Get the Eclpise plugin which provides a serial monitor, just like the Arduino's IDE finally, Build a Hello world example which sends its output over the serial interface to the Eclipse serial monitor and/or flashes a LED.
Update: Its slow going, but made some progress: The Eclipse ARM plugin now creates the bin file for me. I couldn't integrate bossac into the plugin, but it works as an external Eclipse tool (run from Eclipse menu). Unrelated to Eclipse, I still need to manually clear and reset the UDOO Due using the jumpers I installed the Eclispe Serial Monitor Plugin. It didn't work until I applied this fix http://karibe.co.ke/2014/03/eclipse-kepler-terminal-plugin-serial-port-console-in-linux/ Tonight I finally had a successful build and link of the ASF getting started examples under SAM applications. I created the project in Eclipse, copied just the example files over and linked-in all the required include files and ASF source files and ASF libraries. The ATMEL ASF library is completely unmodified and resides in a separate folder. I'm not using any of the ASF make files (there are three which call each other). I may not have all of the linker or compiler oprions set right yet, but I feel I'm making progress. Next step is to upload it to my UDOO and see if it runs
Success! I cleaned up and double checked the GCC compiler options, built the ATMEL ASF getting starting application and uploaded it into my UDOO and everything works. The ATMEL ASF Getting started application blinks two LEDs on PWM13 and PWM9 which can be turned on, or off by momentary switches from PWM12 or PWM3 to ground. The Serial monitor displays some text info on start-up and then prints out a '1' or '2' every time the associated LED is on. This proves-out that Eclipse + Gnu Arm Tool chain + ATEML ASF can be used to develop code on the UDOO's SAM3X8e (Arduino Due). Next Step: Using just the ATMEL ASF libraries, build a simple i2c scanner to see if the ATMEL ASF does a better job of controlling the twi (i2c0 on the UDOO embedded Arduino Due)
Results of I2C_Scanner I was able to successfully build, upload and run an ATMEL ASF version of I2C scanner. For some strange reason, what the ASF calls TWI0 is the UDOO TWI1 (SDA1, SCL1), and ASF's TWI1 is the UDOO's TWI (SDA, SCL). Aside from that, the ASF version properly detects the Adafruit Motor shield V2 on the I2C bus. Here's the code of the main program (I'll document everything I've done soon, its needs a lot of macro defs, includes and libraries of the ASF to build) Code: /* I2C_Scanner * This code was derived from ATMEL TWI EEPROM Example * Written by Keith Smith, 10 April 2014 * * */ #include "asf.h" #include "stdio_serial.h" #include "conf_board.h" #include "led.h" #include "twi.h" /// @cond 0 /**INDENT-OFF**/ #ifdef __cplusplus extern "C" { #endif /**INDENT-ON**/ /// @endcond #define STRING_EOL "\r" #define STRING_HEADER "--TWI I2C Scanner --\r\n" \ "-- "BOARD_NAME" --\r\n" \ "-- Compiled: "__DATE__" "__TIME__" --"STRING_EOL /** TWI Bus Clock 400kHz */ #define TWI_CLK 100000 /** Global timestamp in milliseconds since start of application */ volatile uint32_t g_ul_ms_ticks = 0; /** * \brief Handler for System Tick interrupt. * * Process System Tick Event * increments the timestamp counter. */ void SysTick_Handler(void) { g_ul_ms_ticks++; } /** * \brief Configure the Console UART. */ static void configure_console(void) { const usart_serial_options_t uart_serial_options = { .baudrate = CONF_UART_BAUDRATE, .paritytype = CONF_UART_PARITY };/** TWI Bus Clock 400kHz */ /* Configure console UART. */ sysclk_enable_peripheral_clock(CONSOLE_UART_ID); stdio_serial_init(CONF_UART, &uart_serial_options); } /** * \brief Wait for the given number of milliseconds (using the dwTimeStamp * generated by the SAM microcontrollers' system tick). * \param ul_dly_ticks Delay to wait for, in milliseconds. */ static void mdelay(uint32_t ul_dly_ticks) { uint32_t ul_cur_ticks; ul_cur_ticks = g_ul_ms_ticks; while ((g_ul_ms_ticks - ul_cur_ticks) < ul_dly_ticks); } /** * \brief Application entry point for TWI EEPROM example. * * \return Unused (ANSI-C compatibility). */ int main(void) { twi_options_t opt; /* Initialize the SAM system */ sysclk_init(); /* Initialize the board */ board_init(); /* Turn off LEDs */ LED_Off(LED0_GPIO); LED_Off(LED1_GPIO); /* Initialize the console UART */ configure_console(); /* Output example information */ puts(STRING_HEADER); /* Configure systick for 1 ms */ puts("Configure system tick to get 1ms tick period.\r"); if (SysTick_Config(sysclk_get_cpu_hz() / 1000)) { puts("-E- Systick configuration error\r"); while (1) { /* Capture error */ } } /* Enable the peripheral clock for TWI */ if (pmc_enable_periph_clk(ID_TWI0)) { puts("PMC Clock enable failed\r"); } /* Configure the options of TWI driver */ opt.master_clk = sysclk_get_cpu_hz(); opt.speed = TWI_CLK; printf("CPU Master Clock running at %d\n\r", opt.master_clk); if (twi_master_init(TWI0, &opt) != TWI_SUCCESS) { puts("-E-\tTWI master initialization failed.\r"); LED_On(LED0_GPIO); //Note; these LED controls work opposite: On is off and off is on LED_On(LED1_GPIO); while (1) { /* Capture error */ } } uint8_t uc_slave_addr; uint32_t rst; while (1) { puts("Scanning ...\r"); for (uc_slave_addr = 94; uc_slave_addr < 100; uc_slave_addr++) { rst = twi_probe(TWI0, uc_slave_addr); if (rst == TWI_SUCCESS) { // AdaFruit Motor shiled was on addr 96 puts("I2C device found at address"); printf("%d\n\r", uc_slave_addr); } else { printf("rst = %d\n\r", rst); } mdelay(100); } /* Wait at least 5 s */ LED_Off(LED1_GPIO); mdelay(5000); LED_On(LED1_GPIO); } } /// @cond 0 /**INDENT-OFF**/ #ifdef __cplusplus } #endif /**INDENT-ON**/ /// @endcond
Hi, I'm very happy by your Initiative because usualy, i'm program arduino mega board with eclipse on windows with my own library, no Arduino. On linux,I have experience. I'm looking to found a solution to programme SAM without Arduino IDE on linux with ATMEL libs. Thanks you ^^ Another question I ask myself, can we drive GPIO in C/C++ programme with the ARM part , no SAM.
Update I decided to spend a little more time learning about the GNU ARM Eclipse plugin and the ATMEL ASF to see if I can make the project set-up process easier. There are two problem in setting up Eclipse CDT GNU ARM GCC projects to use ASF: 1. ATMEL's ASF is designed for their entire MCU product line. In the standalone version, they provide make files which set preprocessor switches (#define's) which control the build process for a particular MCU and board. These make files call other make files and all together this process assures that the correct modules and parameters are used for a particular ATMEL product. Its difficult (but possible) to set all of these up in the GNU Eclipse ARM plugin. 2. The GNU Eclipse ARM plugin has project templates, but apparently no way for one to create their own custom template. It does not have one for ASF. Only a few select parameters may be 'exported' and then 'imported' between plugin projects and completely copying a project (to re-use as a new project) tends to bring over links to some of the old project content. Possible Solutions 1. Build ATMEL's ASF as one large static library for the UDOO (Arduino Due). New projects then only need to reference this one static ASF library and I believe the linker only extracts what is needed for your project from it. I believe this is the preferred approach as once its built, many of the #defines are no longer needed. 2. Document a detailed project set-up process. Although this is more work, a detailed set of instructions will at least provide a step-by-step approach. I'm currently asking ATMEL support about the draw-backs of building a single static ASF library. If they indicate that it is a viable approach then I'll attempt to build and use test it. I'm also re-writing the Adafruit Motor control library to use ASF.
UPDATE I spent much more time screwing around with this than I wanted to. The ATMEL ASF is really a collection of configurable source code to support their entire product line. The Windows based ATEML ASF Studio automated everything for you, but there is not currently a Linux version. I tried to build a single static library from it that could be built with the Eclipse IDE and GNU ARM tool chain ona Linux machine, but this proved to be difficult to do. There are a ton of config files that are usually customized for the intended end application and the ASF directory tree and C code include statements make it difficult to extract the required source and header files. ATMEL tech support told me that it not possible to build a static library. I tired anyway, but it turned out to be too much work for the payoff of a static lib. Especially considering that the static lib would have to be built for one set of config files and that I have to repeat all this work when a new ASF release comes out. So, I still believe that one "could" build a static library for at least part of the ASF, but it doesn't seem to be worth the effort required. Otherwise, the ATMEL ASF does seem to have a lot of useful code in it along with plenty of examples. I could run an example's make files with the -n option to just list what would be built (for an Arduino Due or SAM3x8e) and use that info to set-up a project in Eclipse. That's basically what I did to build an ASF version of the i2c scanner, which worked very well. Sorry if I let anyone down expecting static library out of this. You can still mine the ATMEL ASF for a lot of useful code, drivers and sevices. I'd like to get back to my original project. Good Luck ..
INPUT It was a while ago this thread was alive, but thanks for showing that it was doable - so I wouldn't give up But anyway I'm currently running eclipse IDE (Luna) on fedora/linux and use ASF to program my arduino due on the UDOO. But I have taken another approach and instead of trying to use the eclipse-plugin and a static library I create makefile projects based on the ASF makefiles and config.mk and are now doing all of the development from Eclipse and I use ASF. Yes you have to edit the config.mk when you add sourcefiles and so on, but so what. I also upload the compiled bin file with bossac from eclipse using a makefile target. No need for a static library I just compile everything I need when I need it in the project. Works like a charm ... Cheers, Tomas
Hi Thomas, I am trying to do this, use Eclipse creating a project based on ASF makefiles, but this is my first time using Eclipse and I can not get this working. I can compile my project, but I am getting a lot of "Unresolved inclusion: " . What did you have in the "Include Directories" at the "C/C++ General" -> "Path and Symbols" property? Thanks a lot and sorry about my english.
I fixed it! Eclipse use the make output to fnd the headers files that project use. But the ASF Makefile is quiet by default, so I added VERBOSE = 1 to the Makefile before the MAKEFILE_PATH line, and now is working well. Regards, Diego
Hi AntennaSmith, thanks for sharing all of your infos. Actually I am trying to get a console environment running on my UDOO to compile and upload sketches to my SAM. The first tests using arduino-ide and bossac didn't worked. Do you think it is possible, that your setup will work WITHOUT exclipse but with some console / bash commands? Do you have some tips for me how to start from your experiences? I do not have to stay on INO development, I would like much more to develop like in ATMEL studio. So the workflow I am looking for is: 1. Develop and test on Windows with ATMEL studio 2. Save and push sources to a git repo 3. Pull from a number of devices via git the updated sources 4. compile new code directly on the target udoo devices 5. upload binaries internal on udoo target devices via ttymc3 Thanks for some comments. Tom
