contemplating a arm dev board. - Page 1
Forum section: electronics / general

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 04, 2013, 05:02:14 pm
content: Like the title says. I have been hearing great things about the cortex m micros. Some people say they are great for any project large or small. How easy would it be to setup a Linux toolchain for one of these boards a la gcc, gdb, openOCD. I am talking bare metal dev as in no is maybe just a boot loader to get the code on there as I don't know of anything like the pick it for arm. Also is the general consensus these are the uC future or are they just overkill.

author: c4757p
author_rank: Super Contributor
timestamp: May 04, 2013, 05:09:48 pm
content: Quote from: blewisjr on May 04, 2013, 05:02:14 pmPeople saying "X is the Y future" are seldom correct, and more seldom for the right reasons. At current rates 8-bit MCUs aren't going anywhere any time soon; by the time they finally disappear ARM will too.Just like everything, they have appropriate and inappropriate applications. I think they're a good addition to your toolbox, personally.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 04, 2013, 05:18:05 pm
content: I agree. I have 8bit pics and avrs. I like both for different reasons. I would like to tinker a bit with the arm ucs but finding a devboard that will work with my is is another story. I also find it difficult to justify with the scale of some of the project I want to do just seems overkill.

author: andersm
author_rank: Super Contributor
timestamp: May 04, 2013, 06:17:43 pm
content: Many Linux distros already have the tools in their package repository, so check there first. You can get the chip-specific headers and libraries from the vendor (though some still only distribute these as Windows installers.)

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 04, 2013, 06:21:18 pm
content: No issue with building the tools if I had too the header installers would be.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 04, 2013, 06:51:45 pm
content: Here's a toolchain you can try:https://launchpad.net/gcc-arm-embeddedThe compiler/linker stuff is usually pretty easy to get going. It takes a little more time to get your debug/programming tools set up (e.g., openocd) since there are vendor specific hardware issues. I usually recommend one of STM's Discovery boards because they're cheap, and they have a built-in debugger interface that works well with openocd.

author: nctnico
author_rank: Super Contributor
timestamp: May 04, 2013, 07:01:09 pm
content: Quote from: blewisjr on May 04, 2013, 05:02:14 pmNowadays I'd just go for ARM. They are available in many speed and low power options for prices that make it hard to justify using an 8 bit controller. You could say its overkill but having more processing horse power allows to do more in software and less in hardware. Besides who is still using an old fashioned screw driver instead of a cordless drill?

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 04, 2013, 07:25:32 pm
content: Depends on the job NC sometimes a cordless drill is overkill. I only have $170 ish invested between pic and avr. If it is indeed true with what you say it is not killer for me to invest time in arm. The issue is the justification that it is worth the effort and little bit of cash. Maybe some examples of uses and advantages over various scales will help. Not to mention dev board suggestions.edit:maybe this will help some project I want to do.alarm clockwaveform generator8bit game handheldof these three a majority can be done with a 8bit micro.my issue is choosing a chip to learn well. I bought pic and avr because of this. Turns out I like both for different reasons so when I go to start a project I find it hard to choose and change back and forth and get nowhere. Ugh.

author: c4757p
author_rank: Super Contributor
timestamp: May 04, 2013, 07:54:56 pm
content: Quote from: nctnico on May 04, 2013, 07:01:09 pmThat depends totally on what you're doing! You wouldn't build a house with a screwdriver, but would you disassemble delicate electronics with a cordless drill?ARM vs 8-bit is the same thing IMHO.

author: Short Circuit
author_rank: Frequent Contributor
timestamp: May 04, 2013, 08:10:19 pm
content: Quote from: c4757p on May 04, 2013, 05:09:48 pm8-bit will stay for quite a while indeed, but many new products are designed with 32-bit.Take a look at this recent market research; 8-bit is fairly steady over the past few years, while 32-bit is growing.I'd say this implies 8-bit only goes into existing products and new products are more and more based on 32-bit.http://www.icinsights.com/news/bulletins/MCU-Market-On-Migration-Path-To-32bit-And-ARMbased-Devices/Quote from: blewisjr on May 04, 2013, 05:18:05 pmPersonally I favor the STM32 families from ST, for which very low cost dev boards are available, Google "STM32 DISCOVERY".Overkill is relative. These Cortex MCUs are so friggin versatile in periperals and such that 90% of their features remain unused in 90% of projects

author: c4757p
author_rank: Super Contributor
timestamp: May 04, 2013, 08:15:35 pm
content: Quote from: Short Circuit on May 04, 2013, 08:10:19 pmI'd argue that with a microcontroller or PLD, it's only overkill if there's an advantage to using a smaller one. It's not like some factory worker had to hand-craft the PWM module in my microcontroller - if it's the best option for some other reason, I don't care if you're not using a single one of its million really cool peripheral features.

author: c4757p
author_rank: Super Contributor
timestamp: May 04, 2013, 08:20:22 pm
content: Quote from: Short Circuit on May 04, 2013, 08:10:19 pm1) They're quite new still - there are of course many engineers choosing thembecausethey are new, at least in products that aren't supposed to have a very long lifespan. I'm sure that will die down.2) The number of units shipped is still increasing for all types.3) They have lumped 4-bit and 8-bit together. 8-bit is not dying but I'm willing to bet 4-bit is. That will skew the trends, of course.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 04, 2013, 08:48:43 pm
content: I hear good things about both the atm discovery and to launch pad but again both do not seem to have good Linux support through gcc everything I googled mentioned the ccs compiler which is not free and also all information I found was a year old or more filled with hacks and workarounds.seems the situation is just like avr on linux poor chip programming and hardware debug support.

author: andersm
author_rank: Super Contributor
timestamp: May 04, 2013, 09:22:44 pm
content: GCC supports cores, not individual chips. For Cortex-M4 support you need GCC 4.6 or newer. Cortex-M3 support was added in 4.3.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 04, 2013, 09:32:23 pm
content: Oh I am sure gcc 4.8 arm targeted will compile successfully for every cortex m chip out assuming you do the work to get all the perif/pin addresses out of the datasheet if the company does not have headers for you. The issue still exists debugging said code as well as getting it on the chip for one of the dev boards if there is no front end for gdb to connect to remotely. That is the biggest headache I have come across for avr. Lilly pic had stuff for that. Sadly I had to use asm ultimately because xc8 sucks in free mode.so if the devboard does not work with Linux properly it is not worth the money for me. Right now it would look like I would have to go with NXP chips as they have the tools in place. Not sure about the price tho.

author: nctnico
author_rank: Super Contributor
timestamp: May 04, 2013, 10:13:30 pm
content: Quote from: blewisjr on May 04, 2013, 09:32:23 pmMost chip vendors (like NXP) have code packages with example code for every peripheral including C headers files which will work with GCC because its a C compiler.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 12:09:13 am
content: All depends if the code packages are zipped or if they are installers. Might be able to hack the installers to work but NXP provides a full IDE + GCC compiler toolchain for their chips based off eclipse. From what I see now so does TI but it is limited in what chips it supports. But that is really not my concern if I can get headers and it is supported by openOCD essentially you are good. None of these dev boards seem to be bread board plugin friendly sadly which is a huge advantage to the 8bit micro's. It is really hard to see an advantage outside of power besides the better debug support over avr chips under Linux. That is a good thing I guess. The LPCXpresso has a nice base board you can buy for prototyping efficiency. Which sets its cost from $30 up to $165 which is not too bad but outside of the base boards capabilities can be tricky.Anyone know anything about Linux and the other dev boards?

author: jmole
author_rank: Regular Contributor
timestamp: May 05, 2013, 01:48:05 am
content: I know it's cliche, but the Arduino Due has Linux support via the Arduino IDE, and there's a huge community behind it, making it very likely someone has worked on an Eclipse port as well.

author: poorchava
author_rank: Super Contributor
timestamp: May 05, 2013, 02:11:37 am
content: Setting up an open-source development environment is not that bad, although you will never get the sort of functionality you can get from a commercial IDE. I was setting up an environment for STM32 like a week ago under windoze.You need following stuff:-Eclipse IDE for C/C++ development (google it)-arm-none-eabi (so called 'bare metal') gcc. There's linaro, Yagarto, CodeSourcery and few others. Every package has compiler, linker, various converters, packers, splitters etc.-openocd. Google it. Latest stable version is 0.6.1 available from official site. For windoze binaries you can go to a website of Polish colleaguewww.freddiechopin.info. He provides openocd binaries for windoze. If you aim for Stellaris Launchpad then you need 7.0.2 rc version.-zylin embedded CDT plugin and GDH harware debug plugins for EclipseYou can find tutorials on the net on how to put this all together. One thing you cannot typically do is looking at / editing peripheral registers. By default you only see ARM core internal registers. There is a plugin called embsysregview that overcomes that, although its support list is kinda limited.For particular mcu you need to get following things:-libraries and header files - obviously-proper makefile OR compiler parameters that will inform GCC compiler that you are compiling for example for Cortex M4 and whether your controller has an FPU. This makes compiler spit out usable code-linker script - this will tell the linker where in memory to put variables, instructions, functions pointers etc. It's vital for example for interrupt jump instructions to end up in proper memory cell. Those scripts can be downloaded or written by yourself if you're that hardcore-startup file. A code file, usually asm, but c is also found, that sets up stack pointers and some other basic stuffFor ARM controllers I would say your best shot are either ST or NXP. ST sells stm32vldiscovery which contains stlink-v1 (swd mode only IIRC) which works with all STM32 controllers and works very well with openocd. NXP on the other hand has cheaper MCUs but those cheaper MCUs - like for example LPC1111 - do not use JTAG, only SWD. And NXPs implementation of SWD state machine doesn;t go along with generic SWD dongles. And if it does they typically don;t work with openocd. NXPs LPClink debugger has proprietary encrypted interface which NXP refused to make available to openocd developers. TI's products are on an expensive side compared to NXP and ST. I think that ST's "discovery" evaluation boards offer the best value for money. And ST makes very good silicon (especially if you know from your own experience what a mess that company is internally... )

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 10:44:42 am
content: Ok so ST looks like a solid Linux choice. Anyone know anything about the freescale chips and boards? Do they work with Linux I think the boards just use jlink and jtag but not sure.I guess there is also an option to build my own board but never did that before and I am sure that would fall under the same issues with viewing chip perif registers. Also not knowing anything about arm would make this a learning feat and a half but could be fun.

author: Unknown
author_rank: Unknown
timestamp: May 05, 2013, 11:13:34 am
content: Quote from: poorchava on May 05, 2013, 02:11:37 amI would rather buy a newer Discovery board (eg. STM32F0 DISCOVERY, STM32F3 DISCOVERY, STM32F4 DISCOVERY) with an ST-link v2 interface, which is a bit nicer (no dodgy mass storage emulation).Quote from: poorchava on May 05, 2013, 02:11:37 amThe LPC Xpresso is not support by open source tools, but they do offer a (proprietary/code-size limited) IDE for Linux.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2013, 11:23:13 am
content: Programming the NXP devices always works fine using the serial port and the Flash magic tool. So Openocd support is not really necessary for programming. IMHO debugging software on a microcontroller is of limited use anyway.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 12:11:21 pm
content: I don't know I think debugging is important especially for someone new to the realm even if it is just a simulator. Easy to make errors when new to something.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 02:44:51 pm
content: Just got a lot of recommendations for the Ti stellaris on stack exchange so I guess I will look into it in more detail. No rush as I got plenty of pics to use for now going to go hands off avr as the debugger quality is pissing me off as I like to see what is going on.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2013, 04:08:55 pm
content: Quote from: blewisjr on May 05, 2013, 12:11:21 pmThere is a simple solution for that: Take a working example and modify little bits. If it stops working, the last change messed things up. It also helps a lot to debug / verify code on a PC first. Debugging on a PC is infinitely faster and comfortable than debugging on a microcontroller.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 04:16:21 pm
content: Quote from: nctnico on May 05, 2013, 04:08:55 pmbut again you can only debug on the PC if you a have a simulator or an interface that reads everything from the chip and feeds it to gdb like ice, jtag, or debugwire. There is the other option of serial writes if you can get a USB to serial converter that works.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 05, 2013, 04:24:57 pm
content: Dude, just go buy a board already a blink an LED. STM32 Discovery boards are less than $20.

author: BravoV
author_rank: Super Contributor
timestamp: May 05, 2013, 04:43:33 pm
content: Should you choosed TI's path eg: Stellaris Launchpad and don't like selling your soul to the TI's offered free toolchain, here are few tips on setting the toolchain under GNU/LINUX and its also using gdb + openocd for debugging.Building the toolchainDebuggingEclipse setup

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2013, 05:17:31 pm
content: Quote from: blewisjr on May 05, 2013, 04:16:21 pmMost of the code which runs on a microcontroller doesn't deal with hardware at the low level. All of that can be tested on a PC. The parts which deal with hardware can be tested using an oscilloscope and a command line interface. I have been developing embedded firmware this way for 20 years and I'm not the only one working this way. Debugging the software inside the microcontroller may seem nice but IMHO its not worth the hassle to set it up. Recompiling and uploading the code is still much slower than starting the software on the PC. And you don't need a simulator. C code will compile & run on a PC just like it compiles & runs for a microcontroller.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 05:33:14 pm
content: Ah I see what you are saying now. Yes I can see it being beneficial extracting out the standard code to ensure the logic works properly. Then uploading and using an oscilloscope to ensure the perifs are operating as expected for the results. This actually would solve my problem right off the bat with avr on Linux. Assuming I know what the scope should show me. That is an excellent tip I would have not expected to get from this thread.edit:after thinking about it this tip would easily solve all the issues I have had with in circuit debuggers. They seem to always hang up and stall out even with the pickit3. So essentially this tip allows me to save money by ditching the pic which pigeonholes me from my prefered dev environment of vim/make and get back into C with the avr where I want to be. Also use my arduino as a programmer and develop c on my attiny2313a's and still be able to debug without the need of all the crappy hacks and take my time getting to arm.

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 05, 2013, 08:32:50 pm
content: Saying 'no' to in circuit debugging just sounds like you are giving up on a major resource just for the sake of it. It just screams old man holding off progress because it's 'a hassle'. The 20 years comment just backs that up. If you have 'constant problems' then by all means find a way around it, but you are absolutely in the minority if you think it's easier just to toggle led's and run a dedicated uart for debugging. Once people here have 20 years of microcontroller experience they might find it not as useful as well, at this time though, giving up an unquestionably useful resource is not good advice.I'm not certain what tools you've use in the past that have caused so much issue (maybe 20 years ago), but I've never had a problem with in circuit debugging. It's not 'a hassle' to setup at all (unless maybe you're trying to setup an open source toolchain) and I can't remember ever having a big issue with it other than in the old FT2232 JTAG/SWD days when it was fairly slow. MSP430, ARM, PIC, the even the old z8E. Doing a test just now on the project in front of me using my J-Link clone it just registered 0.1 seconds to download and start a 14.7k program. That's not slow.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 09:24:46 pm
content: From my perspective I like in circuit debugging but on Linux my jatagice3 is not well supported. But that is not what the thread is about anyhow.

author: benemorius
author_rank: Regular Contributor
timestamp: May 05, 2013, 09:40:08 pm
content: Quote from: blewisjr on May 05, 2013, 09:24:46 pmThat pretty much nails it. In-circuit debugging makes life great, except when it doesn't.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2013, 09:45:36 pm
content: Quote from: TheDirty on May 05, 2013, 08:32:50 pmA few years ago I attended an NXP seminar where their ARM Cortex controllers where introduced. When asked 50% of the embedded software engineers didn't use in circuit debugging. It is usually possible to use in circuit debugging for open source tools but you have to ask yourself what you want to gain by in-circuit debugging versus the amount of money and / or time spend.When it comes to the software which deals with hardware: Toggling leds or I/O pins maybe old fashioned but it is the least instrusive way to find out if a program passes a certain point or not. You don't want to break in an interrupt routine which controls some hefty MOSFETs. Using more I/O pins and a logic analyser (with deep memory and support for statistics) you can even do profiling to see how much time is spend in certain routines. The thing is that an in-circuit debugger can show what the software does but when dealing with peripherals / hardware the problem is usually getting the settings right. That involves reading the user manual and using an oscilloscope or logic analyser to check whether the peripheral behaves as expected. Other problems may be things like timing conflicts between interrupts. I doubt a low end in-circuit debugger can help to find such problems.The rest of the software is just easier / cheaper to debug / verify on a PC. I do that for almost every embedded software project.For checking status / diagnostics I always incorporate a command line interface. That is not only useful during development but also when a device is installed. Connect the serial port and with a few commands it is totally clear what a device is doing.Ofcourse you can still run into a problem with a pointer going wrong or a division by zero during the development phase. Fortunately ARM controllers offer a fault handler interrupt. In debug builds I have the fault handler dump a stack trace to the UART which usually reveals the problem area quickly. In release builds I just have the controller reset itself.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 05, 2013, 10:46:32 pm
content: Quote from: TheDirty on May 05, 2013, 08:32:50 pmThem's fightin' words! %-BI'd guess that "back in the day," in circuit debugging required lots of $$ for hardware and proprietary software. Successful engineers had to build their own tools to get work done.Nowadays, JTAG/SWD dongles are cheap (e.g., your J-Link clone) and the software to drive them is much less expensive, if not free (in the case of openocd). The main expense seems to be the time investment to get a toolchain and debugger all working together. If you can compile the tools from scratch, there's no reason to avoid the debugger.However, for systems where interrupts do significant work within timing constraints, a debugger doesn't help that much. You can put a breakpoint in an ISR, but when it stops there, all the timing dependent stuff breaks. Single-stepping in the presence of ISRs is a pain too (on some architectures) since the debugger can dutifully wander into the ISR even when you don't want to see it.The implications of nctnico's method are interesting though. To get by with such primitive tools on the mcu, you need to know that your code is mostly working before you flash the device. Doing a big chunk of the code development natively on a PC and then porting it to your mcu, probably seems like extra work to the IDE crowd, but it may be a more effective way to build complex projects.A friend of mine with several shipping products under his belt goes even farther and unit tests most of his code on a mac (using Ruby no less!). The production build is for an MSP430 based device with 10K of RAM.

author: nctnico
author_rank: Super Contributor
timestamp: May 05, 2013, 11:33:49 pm
content: The beauty is that if you use Eclipse you can have the PC development version and the microcontroller version inside the same project or workspace.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 05, 2013, 11:34:51 pm
content: Quote from: andyturk on May 05, 2013, 10:46:32 pmThe only issue I see with this method is take for instance 8bit micros. 90% of your code revolves around manipulating the Registers for the perifs. You can't build AVR code so the PC can run it because avr libc in not a standard libc library it relies very heavily on accessing the addresses where the perif registers reside and a majority of the library involves architecture specific assembler for many function implementations. You just can't debug this on a PC without a simulator or debug capable dongle. After looking into it my pervious post is wrong this really will not solve the issue with praying my jatagic3 or pickit3 operates properly. Like you state if you throw time specific code at them they just puke all over the place stall or hang up and become unfunctional. So on one hand I like having the dongle but on the other I despise the darn things.

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 06, 2013, 12:00:34 am
content: Quote from: nctnico on May 05, 2013, 09:45:36 pmSeveral year ago many embedded programmers didn't even use structured programming. Not too many years ago, the C/ASM troll threads were the opposite and most people would say that programming in assembler only was just as fast and readable as any C code. Progress marches forward. Certainly there are places were the debugger has it's limitations, but it's a great resource, especially for those people new to embedded programming or learning a new architecture. It's fine to read the manuals, but if you can step through the code even down to the assembly level while seeing the state of all the hardware registers, it's hard to imagine why you would avoid it.I'm not certain what cost you are talking about here. The cost is adding a 6 pin header to your project for even just the prototype board. For the Cortex-M for example the programmers/debuggers for LPC, ST, TI, and Freescale are all less the $30. It's so simple and cheap and fast that I'm not certain how making up a separate environment for debugging on your PC could save you any time.It's a useful tool. It's a cheap tool. It's difficult to understand why someone would avoid it unless they really want to stick with a specific programming tool and/or a semi supported or unsupported operating system.Quote from: andyturk on May 05, 2013, 10:46:32 pmIt was probably a little harsh and Thanks to nctnico for not stooping to my level.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 06, 2013, 01:05:38 am
content: Quote from: TheDirty on May 06, 2013, 12:00:34 amI would not say harsh it is your opinion. There is a time and place for every tool just like there is a time and place for every chip. In all honesty it is my own fault for going against the norm and using a Linux OS on all my computers. That is a choice I made years ago well before the Windows 8 Monstrosity. It is not my fault that the companies don't really support the OS all that well. For the most part PIC works pretty well so does AVR. From what I hear ARM works pretty well to. The fact remains I still need to work around a lot of various issues because the support is always sub par compared to windows. For instance MPLABX is not the most pretty environment on Linux and I am not much of an IDE guy was just using it because it worked and I wanted to learn. AVR/ARM have great Linux compiler support however, AVR lacks a bit on the debugger side but it really lets me use the toolchain setup I learned to love on Linux. Never been much of an IDE guy. ARM seems to be pretty solid once you figure out all the separate pieces (still doing that). Either way I want to learn Embedded Electronics and make projects.Right now I have invested $68 into PIC, $118 into AVR, and $20 on an Arduino. Hate the Arduino, PIC has a bad dev environment from my point of view even though it does work for the most part minus all the Netbeans bugs. Really like AVR but still trying to work out the kinks. Makes me wonder if I should have listed to everyone that was trying to point me to ARM but I always felt the chips may have been overkill for learning. So here I am looking into ARM's.My ultimate goal is to find an architecture that works for me in the environment that I choose and to learn. So far I am not really there yet. Right now from what I can see ARM might just be what I am looking for if I can figure out all the pieces that is and even if it is overkill. It does seem to give tons of room to grow.(Apologize trying to get back on topic so I don't confuse myself more)The only real issues I see with ARM is finding the right dev board/chips aka. choosing a company to utilize.The other issue is when I want to make my own board for a project as a hobbyist it could be tougher to do due to surface mount. For some reason soldering 64 pins seems a bit tough (in the case of the TI Sellaris I was recommended). This would also mean perf board is out of the question and I would have to get the board fabricated but this is down the road anyway.So looking at the general options I have available...TI Stellaris (good Linux support through gcc and openocd)SM Discovery (horrid doc with semi decent Linux support)Freescale Kenetis Freedom (Have no idea can't find much info "may be do to wrong search strings")NXP (Solid Linux support through proprietary IDE "Not an IDE fan")Those are really the options I can see and any help narrowing down a solid direction to head would be great and much appreciated.

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 06, 2013, 02:28:32 am
content: TI Stellaris (Now Tiva) doesn't have any chips out there that you can buy last I looked and the selection is extremely limited. I think you can rule those out.After that, I'm not certain about Linux support for LPC, ST32, and Kenetis.I run Linux as well, but only on a separate box. It's kinda gone by the wayside now that I don't host things from home anymore and it just runs ZoneMinder.I have it easy. I spent $150 on a personal license for Rowley Crossworks about 5 years ago when I got fed up with the Yagarto chain and working with ARM7. The main problem with the Rowley personal license is that you can't do any commercial development with it, which is a non-starter for most people. If you can handle that though, they do have a Unix version you can try (never tried it myself). It works with just about every programmer/debugger out there now except for LPC/Link (LPC just put out their LPC-Link2, which emulates other debuggers) and just about every ARM manufacturer/model. Crossworks and my JTAG clone $20 are my main investments in developer tools. Not including the stuff I just buy to play with. ST discovery boards, TI Stellaris Launchpad, ...Watch out with a J-Link clones. Most of the ones you see in the black boxes will be bricked by the latest Segger drivers.

author: westfw
author_rank: Super Contributor
timestamp: May 06, 2013, 03:24:56 am
content: QuoteSaying "no" to the non-open-source tools provided by the vendor seems about the same to me, though from the perspective of a different "religion."The LCPXpresso IDE is sufficiently full-featured for introductory purposes (128k), and based on open-source tools (gcc, eclipse), so there's nothing stopping you from trying out ARM via an LCPXPresso board, and "graduating" to an open source toolchain later, if you really want. (if you DON'T "really want", the Code Red tools "full price" is relatively reasonable.)Quote(The "mbed", another NXP "introductory" product, is more questionable. IMO.)

author: poorchava
author_rank: Super Contributor
timestamp: May 06, 2013, 07:44:43 am
content: QuoteThat is true when your application works mostly in software. When you have an application which makes heavy use of advanced peripheral functions (which AVR and PICs generally lack anyway) in circuit debugger (together with a scope and a logic analyzer) are vital.If fact I never used a hardware debugger on an AVR. On PIC you get it for free, plus it is kind of necessary when every other line of code triggers some silicon bug or compiler weirdness.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 06, 2013, 11:10:36 am
content: Well like I said my biggest issue is in my choices I want to keep things open source and I have my own personal reasons for that. It is true however with micro is in general you can only get so open source. Due to needing often the proprietary libs for the chips. So if it is a no go on getting TI chips I probably need to re evaluate the other boards and find ways around how I am limited due to my choices.

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2013, 11:24:59 am
content: Quote from: TheDirty on May 06, 2013, 12:00:34 amI'm way aheadI like to stay as high-level as possible by hiding hardware behind functions (hardware abstraction layer) and trying not to bother with assembly, registers, etc. You are thinking too much in boxes which say microcontroller A, B or C which need IDE A, B or C. I focus on the software and don't care about the platform. The way I see software is that it is a black box which performs a function. If I compile it for a PC it works on a PC, if I compile it for microcontroller A then it works on microcontroller A. If you make life that simple you don't need to jump through hoops with vendor provided tools. I standarised ALL my software development around Eclipse and use the same set of basic routines (timer, UART and command line) for all microcontrollers. This means there is no extra time involved for testing / debugging software on a PC. It is just a matter of clicking 'compile for PC'. In my world everything is simple because (almost) everything becomes a standard nail for which I can use the same hammer.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 06, 2013, 11:38:04 am
content: Quote from: nctnico on May 06, 2013, 11:24:59 amOk that makes much more sense why your compile for PC works with so much hardware. Essentially you are using a multitargeted bsp if I understand what a bsp is. This way you can flip a compiler flag and bang it just works. Seems like a lot of extra effort tho but it does give you simplicity in the long run.

author: elgonzo
author_rank: Unknown
timestamp: May 06, 2013, 12:06:58 pm
content: Quote from: nctnico on May 06, 2013, 11:24:59 amI see what you are hinting at. Cross-platform libraries/APIs for common functionality are certainly the future. However they will not be the "end of it all". Even after decades and with today's homogenized PC hardware, PC developer communities still continue to struggle with cross-platform issues. The more projects grow in complexity (which one can reasonably expect given the advancements and general availability of embedded tech), the harder cross-platform support will become...

author: nctnico
author_rank: Super Contributor
timestamp: May 06, 2013, 03:40:40 pm
content: When C was invented they also created a standard C library which became part of the Posix standard (http://en.wikipedia.org/wiki/POSIX). Interestingly when C was invented computers where less powerful than today's microcontrollers so most of the functions are written with low resources in mind. Ofcourse the libraries got bloated over the years but there are still several small sized libraries around like the standard C libraries for the mspgcc (GCC for MSP430) which can also be compiled for ARM. In my experience it is best to stay close to the Posix standard even in an non-operating system environment. What I often see is that people create their own string printing routines because printf sucks in so many library functions. The better solution is to just replace printf with a minimalistic implementation. Several minimalistic printf versions can be found on the internet.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 06, 2013, 04:04:43 pm
content: Quote from: nctnico on May 06, 2013, 03:40:40 pmOn top of what is out there it is not hard to write your own minimalistic libc for various chips. Hell the best c book on the market imho is k&r and it teaches c by showing how implement various features from the original libc. The problem is a lot of newer c developer are learning from the internet and never truly learning what c was all about. I learned from k&r 10 years ago and glad I did.

author: elgonzo
author_rank: Unknown
timestamp: May 06, 2013, 04:47:04 pm
content: Quote from: blewisjr on May 06, 2013, 04:04:43 pmIf your focus is mostly on performance and complexity levels of 8-bit micros, this approach works nicely.However, this view is naive if you just look a little forward into the future. Even in the embedded world, you (will) have 64-bit micros with hardware virtualization and multiple GB address space. Talking about minimalistic libraries when looking at the things to come, yeah... well... um...

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 06, 2013, 06:10:54 pm
content: I would see that as quite far into the future even modern PC 64 bit chips run quite hot but by then maybe cpp will have a reason to survive lol.

author: poorchava
author_rank: Super Contributor
timestamp: May 07, 2013, 06:21:31 am
content: As far as I know stm32 equipped with stlink adapter work reasonably well under Linux. They are very popular so proper tools are definitely out there.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 07, 2013, 10:16:49 am
content: Yes this is the deduction I came to last night as well. Openocd has stlink support as well as there being a tool specifically for stlink. So right now I am contemplating ordering a stm32f4 discovery. Gunna have to find some other stuff to order first so I don't get nailed as hard on shipping.

author: nctnico
author_rank: Super Contributor
timestamp: May 07, 2013, 01:03:41 pm
content: And if the programmer doesn't work on Linux you can always use Virtualbox for running Windows and/or Apple's OSX.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 07, 2013, 01:14:52 pm
content: True and there is always the possibility of wine working as my laptop only has a 128gb ssd so vbox would kill space.

author: nctnico
author_rank: Super Contributor
timestamp: May 07, 2013, 01:22:20 pm
content: Forget about Wine. The beauty of virtualbox is that the harddisk image grows with the actual information stored. So a fresh 100GB partition with WinXP and a few programs will only use a few GB of space.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 07, 2013, 01:36:00 pm
content: I would use my win7 gaming laptop before I did that. The thing is the only time I use that thing is if I am in the mood for a game or if an application for my online classes requires windows period. I do not develop code on it.

author: elgonzo
author_rank: Unknown
timestamp: May 07, 2013, 01:49:15 pm
content: Quote from: blewisjr on May 07, 2013, 01:36:00 pmYep, if you have a second machine available this can be quite comfortable.However, i often found myself in the need of setting up specific (test) OS configurations, fighting with experimental driver stacks and the need to compare software behaviour on different OS versions, that using virtual machines became the only feasible solution. Since my host OS is (evil) Windows, the VM i use is VMware Player. I never managed to get USB pass-through working with VirtualBox...

author: jmole
author_rank: Regular Contributor
timestamp: May 07, 2013, 01:56:21 pm
content: Quote from: elgonzo on May 07, 2013, 01:49:15 pmYou need a few things:1) Install VirtualBox Extensions Pack2) Enable USB 2.0 Host Controller (duh)3) Only use 1 CPU in the GuestNot sure why you can't use more than 1 CPU with USB, but it caused me a big headache until I figured it out.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 07, 2013, 02:04:28 pm
content: Quote from: elgonzo on May 07, 2013, 01:49:15 pmNever said windows was evil jus manipulative and restrictive lol. The only other feasible option "quiver" would be to bite the bullet and install win 7 on the damn thing. Which would involve buying a copy. Sure my laptop came with win 8 but all those recovery partitions are long gone hehe.edit:forgot about the other option. I could always turn the Linux laptop into a $1000 touch screen svn server if I turn off sleep when the lid closes then I have a ultra compact vcs server that runs on my intranet if windows is so important for embedded development as it seems to be.

author: elgonzo
author_rank: Unknown
timestamp: May 07, 2013, 02:32:13 pm
content: Quote from: blewisjr on May 07, 2013, 02:04:28 pmHehe, no, i said it. I didn't try to imply that you expressed something in this direction. Sorry! lol...Choose your OS simply based on whether it is supported by your favourite development tools, and whether you have to consider certain, usually very project-specific, driver-related dependencies. In most cases both Linux and Windows do fine. Heck, in many cases it's actually like the spare parts bin: Just use what you have lying aroundEDIT: If you really going to convert your gaming laptop into a server, please let me know

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 07, 2013, 02:43:58 pm
content: No the Linux laptop. Gaming one will never be a server need that fix every so often lol. By the looks of it everything is windows oriented and the Linux support is usually hacked together and buggy. Everything in my work area seems to prefer windows lol. Even my scope but luckily excell files can get opened on Linux lol.

author: westfw
author_rank: Super Contributor
timestamp: May 07, 2013, 03:35:18 pm
content: QuoteWhere "a few" is "about 10." At least, my 10GB partitions quickly became so full that I couldn't do updates, even though I was trying to install the apps on a separate virtual disk. Some of that was my carelessness, some was microsoft's insistence on keeping around temporary files and histories, and some was their insistence on putting things on C: After some careful cleaning, I got it down to about 7G...(The "virgin" XPsp3 install "from which virtual machines are cloned" is slightly over 4G.)

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 07, 2013, 04:12:34 pm
content: Either way with this machine a vm is not an option. So it will be all or nothing.

author: M. András
author_rank: Super Contributor
timestamp: May 07, 2013, 04:56:35 pm
content: external hard drive for that laptop install to that and you wont use up the space on the ssd

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 07, 2013, 05:05:30 pm
content: Vm or no vm it still costs a license to Windows which I would ultimately rather avoid all together. Which is why I mentioned moving the Linux laptop to a server if I end up having to use windows for development. It saves me $200 to do it that way compared to the vm.

author: andyturk
author_rank: Frequent Contributor
timestamp: May 07, 2013, 10:47:35 pm
content: Quote from: blewisjr on May 07, 2013, 05:05:30 pmPaying for WinBlows(tm) is sooo last century.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 08, 2013, 12:06:42 pm
content: Quote from: andyturk on May 07, 2013, 10:47:35 pmI agree so much better to not use it at all!!!!!

author: elgonzo
author_rank: Unknown
timestamp: May 08, 2013, 03:06:23 pm
content: Quote from: andyturk on May 07, 2013, 10:47:35 pmYour comment reminds me of the late nineties, wheren Linux was still a contender for the desktop. So, yupp, that's last century

author: elgonzo
author_rank: Unknown
timestamp: May 08, 2013, 03:13:23 pm
content: Quote from: blewisjr on May 08, 2013, 12:06:42 pmI am glad that you are happy with Linux. I suppose, all the concerns you vocalized before are resolved

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 08, 2013, 03:59:53 pm
content: There are always concerns even on Windows at times things do not work like they are suppose to. I will see what time brings do not know what is going to happen yet as of right now my PIC chips work find with Linux. AVR is a bit fussy still trying to work the bugs out of building the toolchain but all most there but not sure if I am going to use AVR for any projects in particular yet because my PIC's are more then capable for them. As for ARM time will tell what I choose. I suck at making over all decisions especially where I like many different things about everything. One thing I do know is I am a Linux Junky even if it never gets main stream on the desktop which likely it never will. As for Linux and embedded development don't know how overall support is it may come down to the fact that I need to use windows for desktop work and Linux for server work only time can tell with that as well. So far in computing Life Linux has not let me down yet!!!!! This may be the first time ever

author: elgonzo
author_rank: Unknown
timestamp: May 08, 2013, 04:28:24 pm
content: No it's fine using Linux (i think i mentioned it somewhere before).It's just a fact that for the time being, Linux has lost on the desktop front. That sucks, no doubt about it. But it doesn't help overly idolizing things, which looking at your remarks, i don't think you run the danger of succumbing toYeah, and it always sucks if you are presented with no alternatives, no matter where. It simply sucks.Being mostly a Windows user, but occasionally my work requires me to use MacOS, because of iOS-development-related things. Now, i don't really hate MacOS, but i dislike to need just another, secondary PC (Mac) just for that purpose (which is kind of a similar situation you face, just with different players). So, my company got me a Mac Mini just for that, but which i don't use. Officially i use the Mac for this dev work (because of the license terms of the Mac software), but inofficially and in reality i run MacOS in VM as it is more convenient for me. Now, contrary to your situation, i did not have to worry about the costs of all this, so, yeah, you could accuse me of speaking from the high horseAnd one minor correction: No, Linux did not let you down. Linux as such is by no stretch a failure, otherwise it would not be one of the dominiating OS'es for servers and super computers. It is just the whole situation that evolved around desktop(!) Linux during the last decade, with all its elitism/fragmentation and in-fighting in its developer community, as sad as it is

author: nctnico
author_rank: Super Contributor
timestamp: May 08, 2013, 05:13:27 pm
content: I wouldn't say Linux has lost or won something. The thing is that Linux in itself works way better than Windows but for some software there is no proper alternative available for Linux. I'm gradually moving more and more to my Linux machine. This takes times because it is a lot of work. Having Windows in a virtual machine helps a lot so I can continue to use software for which there is no Linux alternative.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 08, 2013, 05:16:57 pm
content: I agree to some extent about the fragmentation the real issue lies in the fact that Linux could have succeeded on the desktop if it was not for that high horse mentality. Many companies tried very hard to include Linux in the mix and still are trying very hard just look at Nvidia but the fact remains they get shutdown constantly when it comes to providing drivers for the Linux kernel because they do not want to expose the proprietary parts of the driver. The Linux high horse is so huge that even if a open source middle man layer between the proprietary parts and the open source parts exists they still get hard flack and shut down. Right now that is the biggest issue Nvidia is having with getting the optimus technology stack in the kernel. The developers of many Linux packages and the Linux Kernel just do not understand everything can not be open source. Open source is great but there comes times when open source is not possible due to the actions of comities, stakeholders, and competitive edge.The in fighting side of things gets worse by the day to the point where it is beginning to hinder progress to new and innovative ways to do things. They are very hard engrained in the old for the most part so much to the point that anything new like Gnome3 and Ubuntu's Unity is considered treason. Not sure why... They are both effective environments and much better then windows Metro crap (which btw is awesome on a phone yes I use a windows 8 phone and it is the best phone I ever owned)So over all I am far from elitist (which you did not accuse me of) I use what is best for the particular job at hand. If embedded development is better one windows I will use that and leave Linux to what it is great at servers. Which come to think of it is probably what I am going to do anyway because I am tired of fighting to get the toolchains up and running it just gets old after a few days of bashing your brain of the terminal trying to get crap to build like it is suppose to. I can't count how much source code I had to modify for some of these projects to get them to build. I mean who in there right mind puts out a release tarball with syntax errors in it. I know people who refuse to update there damn compilers to versions that are not 5 years old lol.I do agree that over time things do get better on the Linux front but to this day I have yet been able to do a full switch for everything hence why I always have at least 1 windows related computer. One thing I can say is I will never use Windows 8 on any desktop or laptop. It just does not work well at all. Wish they just separated the two interfaces between mobile and desktop would have been much better.

author: elgonzo
author_rank: Unknown
timestamp: May 08, 2013, 05:21:24 pm
content: Quote from: nctnico on May 08, 2013, 05:13:27 pmYes, probably "lost" was the wrong word in the context. Maybe i should have said something along the lines of "hurt". But anyway, i do not want to start a debate, because generally i agree with you.And i can also understand blewisjr, that, when contemplating about getting a proper Windows license for a VM and seeing the price tag, he goes like: "WAT?"

author: nctnico
author_rank: Super Contributor
timestamp: May 08, 2013, 06:26:25 pm
content: About the Windows license... just go on Ebay and buy an OEM XP license or so for a few $. OTOH the laptop probably came with WIndows so the license to run Windows on it is already there.

author: elgonzo
author_rank: Unknown
timestamp: May 08, 2013, 06:37:43 pm
content: Quote from: nctnico on May 08, 2013, 06:26:25 pmCareful about that. Not all OEM license keys work with retail versions, some of the keys are even language-specific. Do this only if the vendor is reliable and thrustworthy.

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 08, 2013, 07:47:17 pm
content: Quote from: nctnico on May 08, 2013, 06:26:25 pmWindows 8 purchased laptops do not come with a license key on them. It is actually built into the factory oem recovery partition which is actually long gone by now. It really does not matter. I already have my large 19" gaming laptop setup for both PIC and AVR programming and it only took maybe 5 minutes total. Who would have thunk it. As of right now I will probably use this and put the other laptop on the shelf for now. I am tired of fussing around I just want to learn and make projects damnit

author: M. András
author_rank: Super Contributor
timestamp: May 08, 2013, 07:59:29 pm
content: must be a sticker somewhere in the laptop with the windows license btw

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 08, 2013, 08:12:25 pm
content: Not with windows 8 laptops. My gaming laptop also use to be a windows 8 laptop no license key on it either. Windows 8 Computers do not come with license keys.

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 08, 2013, 08:47:14 pm
content: Ya, if I ever get a computer with OEM Windows I always recover the Product Key right away. Once that drive is wiped with the recovery partition, that's it for the key.For those people wanting to make sure they keep their key, just google 'windows 8 product key viewer'. Same with Win7.

author: M. András
author_rank: Super Contributor
timestamp: May 08, 2013, 08:47:22 pm
content: thats simply stupid lol,

author: Unknown
author_rank: Unknown
timestamp: May 08, 2013, 08:48:27 pm
content: Quote from: nctnico on May 08, 2013, 06:26:25 pmI'm pretty sure the Windows XP OEM license does not allow it to be used for VM guests. Last time I checked, you needed retail licenses for VM use. They probably changed this in later versions, although it may have specific requirements about the host OS.

author: elgonzo
author_rank: Unknown
timestamp: May 08, 2013, 09:14:13 pm
content: Quote from: alm on May 08, 2013, 08:48:27 pmThis depends entirely on the laws/jurisdiction of the particular country you are in.In Germany, it has been specifically ruled by the federal court that it is legal to sell such OEM licenses, and that any terms in those licenses trying to restrict the kind of hardware the software is running on are invalid. So, in Germany at least, you can use OEM licenses in a VM. In this situation, even pushing an argument that a VM is not hardware would not work -- in consequence, the guest OS is executed on exactly the same hardware as the VM itself, which nobody can deny.However, if you would need to do modifications/hacks on the OS to make it run on a VM, as it might be necessary with MacOS for example, then those modifications might violate the license terms&conditions.But... different countries, different rulings.

author: nctnico
author_rank: Super Contributor
timestamp: May 08, 2013, 09:15:29 pm
content: Quote from: elgonzo on May 08, 2013, 06:37:43 pmDuh...you keep the OEM license in shrink wrap and get an image from internet... No hassle with activating etc. Over here the law says that if you own the medium you own a license.

author: elgonzo
author_rank: Unknown
timestamp: May 08, 2013, 09:17:33 pm
content: Quote from: nctnico on May 08, 2013, 09:15:29 pmWell, i would have problems using a russian, korean or chinese Windows, if that is the OEM license this sneaky Ebay vendor would have sold me...Ohh.. and then there are those OEM licenses, where you can get only install media suitable for specific laptop models...... etc, etc... but i think i just bored you...

author: westfw
author_rank: Super Contributor
timestamp: May 09, 2013, 03:07:09 pm
content: QuoteWhy? I noticed recently that Atmel has a download of the toolchain (gcc/etc) for linux, already built with their patches/etc. I guess you'd still have to set up eclipse or whatever...

author: blewisjr
author_rank: Frequent Contributor
timestamp: May 09, 2013, 05:18:51 pm
content: Quote from: westfw on May 09, 2013, 03:07:09 pmNah I was actually trying to get the patches into the newest version of binutils and gcc and it just was being really fussy to the point where the patches were breaking the builds. This is a non issue at the moment anyway because I now have Atmel Studio setup on Windows and I am using that. I am not much of an IDE guy but Atmel Studio is working quite well.

author: 0xdeadbeef
author_rank: Super Contributor
timestamp: June 11, 2013, 11:01:01 am
content: Quote from: TheDirty on May 06, 2013, 02:28:32 amWhich can be easily fixed though