VS
Dear Friends ,
Today I'm working on IDE for Multipilot 2.0 . I found different kind of approach available For developing application on Arm Cortex A3 microcontroller.
Actually I'm studing this kind of platform :
Xduino , Maple IDE and CooCox IDE.
The first two ide are Clone of official Arduino project . This kind of ide use same Arduino Java ide and add support for gcc arm compiler instead of gcc . Normaly support usb uploading of firmware don' support jtag debugging. The Maple is better of xduino at the moment. The standard arm library is wrapped for using same arduino language sintax. Is not yet fully compatible with original arduino sintax.
The second one instead is a Eclipse ide , that include support for makefile automatic production , gcc compiler , linker, debugger and support Jtag interface for debug and upgrade firmware.
Support a lot of functionality of ARM micro , is available a micro operating systems that support task and preemptive multitasking.
Personally I prefer second kind of approach , more professional approach not for entry level programmer . The first kind of approach is very good for people that normaly use arduino for development of his application .
My idea at the moment is to support all kind of systems .. actualy the second kind of ide don't support the arduino .pde application ,but i think that is possible to develop a wrapper class and a mod for eclipse that support this kind of improvment.
What kind of approach do you prefer ?
http://www.coocox.com/CooCox_CoIDE.htm
http://leaflabs.com/docs/ide.html
Official Thread : http://www.virtualrobotix.com/forum/topics/what-ide-do-you-prefer-for
Regards
Roberto
Comments
Some news update ... Xduino work on Ardupilot32
http://www.virtualrobotix.com/forum/topics/what-ide-do-you-prefer-for
@Todd not that I'm suggesting Java per se, but you seem a bit confused about a few things.
In general, languages don't "support DMA". DMA is a hardware facility, and support for it in an embedded environment boils down to whether or not you have the ability to touch the hardware. If your JVM can't touch the DMA hardware, it can't touch any of the other hardware, and vice-versa.
Multi-tasking is a badly overloaded term, but in any case the definition you mean (multiprocessing) is a function of the runtime that you're using (e.g. an RTOS or a standalone threading package) and the JVM.
There are plenty of reasons for not wanting to use a JVM; these are not two of them.
I like this project a lot, I'm a huge fan of STM32. I think the real question here is programming language not IDE. Java based or portable C code. If you use Java based it limits functionality as these don't support DMA and multitasking which will especially come in handy with this project. If you use portable C then it doesn't matter what IDE, and anyone like me will use their particular favorite flavor.
-Todd
atmel will show in march a beta of the new development environment for the 8 bitters - it is eclipse based :)
eclipse does need a (steep) learning phase. for those never programmed it might be hard. but i think it is possible to provide binaries for a few variants of the firmware.
CooCox is a non-starter; as a closed-source, Windows-only product it cuts out much of the community.
The APM team has more or less settled on a baseline requirement that it must be possible to tweak, build and upload the firmware using the Arduino IDE, regardless of what tools developers use personally for their work.
In my case, for example, I use Eclipse wrapped around a set of Makefiles to build the APM application, libraries and examples. I've used the same make-based tools under CodeLite, Code::Blocks, NetBeans, emacs and the shell. This is easily the most portable approach, but it's difficult to make it work with WinAVR and thus it cuts out Windows users, so again it's not really OK for APM.
From the perspective of bringing up AP32, I think that building with make is the *only* sensible way to go. What you're trying to codify is the build logic, not the toolchain (there are several that are worth considering) or the IDE (many worth considering). The GNU ARM tools work well with make on Windows (via cygwin) so you shouldn't have the WinAVR issue there.
Likewise from a debug perspective there are plenty of intermediate options, but they (almost) all support GDB, and so if it's necessary to actually automate any of the debug process, presuming GDB and leaving the rest up to the developer is the most reasonable thing to do. Whether the user is using OpenOCD talking to (anything) or a BDI, or any of a dozen other debuggers, this will work.
Further down the line, picking an environment as the 'standard' and documenting its setup won't lock anyone out, and you have the flexibility to adapt to almost any setup.
As a side note, doing 'real' debugging with Arduino is pretty trivial. Find the build directory, and point your debugger at the <sketch>.cpp.elf file. Connect to your favourite AVR JTAG debugger (JTAGICE mkII-CN is < $100 shipped off eBay) and presto. Symbolic debugging (using GDB) with Arduino.
Arduino is simple and rather good for the first steps. It's easy and effective for simple projects.
But the lack of debugging is just not acceptable for larger projects. You have to figure out tricks for testing code parts, blinking leds, oscilloscope on pins, serial output to a terminal - it's a pain and not effective at all.
If you need serious multitasking, Arduino can't do that. You got comfortable tools, no need to bother with the hw (registers of the peripherals etc), but the possibilities are very limited.
Mbed is similar to Arduino on stronger hw and newer sw solutions, but the problem is the same - debugging.
I agree that an Eclipse IDE s way too complicated for the average user who is not interested in coding but needs firmware upgrades. But a usb bootloader solves that problem.
For firmware development the Eclipse IDE, GDB server plus OpenOCD&JTAG or propritary solutions like Segger etc. is way better. I was working with Raisonance, Eclipse&Yagarto IDE and with CooCox too.
Raisonance is hands down the best, but code limited.
CooCox is easy to install and compact. There are many built-in peripheral libraries, but I dont know their quality as I started the project using the original ST samples. While ther are bugs, CooCox is definitely useful for serious hobby work.
Eclipse with plugins and GDB is OK too, the only problem is the difficult setup. For example the most popular ftdi jtag adapters need a driver. The original ftdi driver is reliable, but it's not allowed to distribute OpenOCD binaries for the closed source ftdi driver. There is a opensource driver too, but it's slow and not working on 64 bit Windows etc. So you have to build your own Openocd from the source, or searching for an illegal Openocd copy.
There are bugs in Eclipse too, for example the .S bug. It's not working, and you are not sure if you just missed something, or you need a workaround. Searching the forums, reading many ideas, and with some luck finally find the real solution.
It's not easy at all.
I understand the strive for simplicity, I think this is important for the success of open-source projects. I think you should however not underestimate the value of REAL debugging - the Arduino IDE has no way of running your code in single steps, looking in real time at the variables instead of a few blinking leds and guessing what could be wrong.
Given this argument, would you still make the point that learning the menus of an IDE are more difficult than finding a bug in microcontroller C code? Or maybe even worse, an in-flight crash because proper testing was not possible?
Don't mistake an Autopilot with a normal Arduino project - autopilots have to manage lists (waypoints, parameters), have many controllers and a rather complex mainloop in contrast to 99% of the typical Arduino use cases, where you want to read out a few things and control a few others.
One thing I didn't see here so far: Code autocompletion! Especially if you work with a complex project (such as an autopilot) it is annoying to have to remember all the variable names. Eclipse allows you to auto-complete them by hitting CTRL-Space easily. Many users would for sure appreciate this.
I think it would be very, very important to have a state-of-the-art IDE and support for free/cheap JTAG adapters such as OpenOCD. This IDE here is similar to CooCox and worked well for on ARM7: http://www.yagarto.de/
yes, i understand. when the arducopter software is mostly working and the copter crashes.
how would you describe that?
http://www.coocox.com/CoLinkGuide/Other_Jtag_Probe.htm
it has to work and not mostly.
i have a jtag device from that list and it does not work.
this is prob. what you would call mostly.
The jtag debugger circuit that Coocox uses is mostly identical to others like floss-jtag (used for OpenPilot)
Coocox says that their implemenation is free and open, includes schematic, bom, eeprom data, code to program the eeprom, drivers for the whole thing. They've laid it all out. Free everything.
http://www.coocox.com/CoLinkGuide/CoLinkDIY.htm
-
1
-
2
-
3
of 3 Next