What microcontrollers offer good/great Linux toolchain support? - Page 1
Forum section: electronics / general

author: R2D2
author_rank: Newbie
timestamp: February 25, 2014, 04:52:29 pm
content: Howdy,I'm interested in programming microcontrollers in C and assembly under Linux. What mainstream inexpensive microcontroller families have a good to great Linux tool chain? I'm at home in a terminal and am looking to go bare metal in my tinkering around. Any help or suggestions would be appreciated. I also have access to OS X terminal in addition to Linux.Thanks!

author: mathias
author_rank: Regular Contributor
timestamp: February 25, 2014, 05:08:47 pm
content: STM32 is supported by arm-gcc (https://launchpad.net/gcc-arm-embedded). This has no limits on code size or optimization. There also exist a ST-Link for linux from github (https://github.com/texane/stlink) for programming/debugging. STM32 boards include a debugger onboard and are dirt cheap.I am using this combo myself for quite some time, and I'm really happy with it. I don't use any IDE, just a text editor (Vim) and the command line tools (Make, ST-util, gdb, ...). Everything works out of the box for me, and that's using both linux Mint at home and CentOS at work.A great place to stat is this page:http://eliaselectronics.com/stm32f4-tutorials/setting-up-the-stm32f4-arm-development-toolchain/

author: nctnico
author_rank: Super Contributor
timestamp: February 25, 2014, 06:38:49 pm
content: Quote from: R2D2 on February 25, 2014, 04:52:29 pmBeter ask which aren't supported. Every CPU core supported by GCC can be used.

author: dannyf
author_rank: Super Contributor
timestamp: February 25, 2014, 06:58:21 pm
content: Anything that is supported by GCC would be a good starting point.If you use IAP, all you need then is the compiler as the chip is self-programming itself.Google AN2557.

author: tszaboo
author_rank: Super Contributor
timestamp: February 25, 2014, 07:01:35 pm
content: Are you seriously buying the coat for the button you already have?

author: zapta
author_rank: Super Contributor
timestamp: February 25, 2014, 07:06:57 pm
content: I had good results with avr using Linux and osx.

author: Lukas
author_rank: Frequent Contributor
timestamp: February 25, 2014, 09:21:44 pm
content: From my experience, I can confirm that AVR, MSP430 and STM32 all have rather good linux toolchains available (GCC, avrdude/mspdebug/openocd or st-util). The advandage of maintaining the toolchain using a Makefile yourself is that you don't have to learn a new IDE every time you use a different micro. Make, gcc, and gdb are always the same, only the programmers are different. Additionally, you don't have to leave your favorite enviroment (text editor, etc.) for developing for your mcu. I can encourage everyone to learn the basics of makefiles and create their own workflow, it gives deep understanding of the tools you're using, there's no/less 'black magic' anymore. This really comes in handy if 'it breaks' or you want to do nonstandard things.Example: The STM32 have a builtin ROM bootloader for USB. In order to make my device less easy brick I shifted the main app by one flash page+512 byte. The 512byte contain a md5 checksum of the main app. (it had to be 512 bytes because the interrupt vectors have to be aligned at 512 byte boundaries) The code in the first flash page, which gets executed on power up calculates the md5 sum of the main app and compares it to the one stored in flash. If the checksums don't match, it'll execute the usb bootloader in order to fix the app. It's been very easy to modify the build process, because with the makefile, you've got full control.You have to understand make to use it properly, but instead of some IDE's XML rubbish a normal person can understand it.

author: dannyf
author_rank: Super Contributor
timestamp: February 25, 2014, 09:44:39 pm
content: QuoteI would argue that for most of us, having a deep understanding of the tools is a waste of time. You don't need to understand how your GPS works to use it; You don't need to understand every intricacy of your cars to drive it or even to drive it well.To be successful, you just need to know how to deploy your limited resources (time, money and brain power) to where you add the most value and use others where you aren't as gifted (ie. specialization).The exception, of course, is if you are so exceptionally resourceful or gifted.QuoteHighly subjective and likely doubtful.

author: jancumps
author_rank: Unknown
timestamp: February 26, 2014, 05:30:56 pm
content: Quote from: mojo-chan on February 26, 2014, 11:22:24 amUnderstanding the compiler is essential if your job is dealing with situations where having an understanding of the compiler is essential.But in other situations i'd rather say: nice if you know it. Essential?

author: GiskardReventlov
author_rank: Frequent Contributor
timestamp: February 26, 2014, 06:46:19 pm
content: Quote from: Lukas on February 25, 2014, 09:21:44 pmAll your advice makes a lot of sense to me and I agree but the IDE is the best reason to use make and the command line. The last IDE I used for altera env. for FPGA was around 11GB! It was sluggish too.My complaint with linux toolchain is there are so many sites with info that it's a bit fractured but I'm new to mC and I just need information relevant to the HW I have. So far I found avrdude for actually talking to the chip, I have the chip's datasheet and I even managed to build binutils like avr-ar, etc. I built gcc for target=avr and now I'm stuck on building the libc as it can't find rules to make the .h files.

author: Neverther
author_rank: Regular Contributor
timestamp: February 26, 2014, 08:48:42 pm
content: Have you tried if your distro has prebuilt packages for them?avr-binutils, avr-gcc and avr-libc...If you want to compile them yourself, you could look build scripts from some distro.Arch has plaintext scripts that are pretty easy to read.If you continue with avr, try searching for "avr Makefile template", I use it and so far it has been good (my coding environment is nano).

author: GiskardReventlov
author_rank: Frequent Contributor
timestamp: February 26, 2014, 09:16:37 pm
content: Quote from: Neverther on February 26, 2014, 08:48:42 pmThe tar balls came with a build script but requires internet. The laptop can't get internet.I can't figure out why libc wants to build new .h when the tar balls came with what looks like all the .h that are needed.QuoteI see this is for the writing/compiling code stage. Good tip.

author: andyturk
author_rank: Frequent Contributor
timestamp: February 27, 2014, 08:12:12 am
content: Quote from: dannyf on February 25, 2014, 09:44:39 pmDepends on what you mean by "deep understanding", but I'd much rather work with someone who can maintain their own dev environment, than someone who's either dependent upon team members to fix stuff, or has to call tech support on a regular basis. There's probably little need to understand the inner workings of the compiler itself, but knowing how the overall build system works is often very important.For example, the nRF51 bluetooth/M0 chip requires some non-standard build steps to integrate Nordic's bluetooth code with the main application. It was easy to tackle with a Makefile, but (I think) it would be a real challenge for the IDE-only crowd.https://github.com/andyturk/nrf_blink/blob/master/Makefile

author: nctnico
author_rank: Super Contributor
timestamp: February 27, 2014, 09:53:59 am
content: Quote from: andyturk on February 27, 2014, 08:12:12 amI agree. It is one of the first things I show interns because schools never teach how and why a compiler/linker finds libraries and header files. It is something you need to know if you ever attempt to link against a seperate library (even when using an IDE).

author: dannyf
author_rank: Super Contributor
timestamp: February 27, 2014, 12:31:33 pm
content: QuoteI would rather have my cake and eat it all too,Seriously, I don't care how one gets his job done. I only care about getting the job done.QuoteIf we require a "deep understanding" before using anything, we have to die: we understand very little about human brains, for example.QuoteAbsolutely true. But if you have limited resources, is it more important than getting your job done?QuoteYou can always set up a question so that it is impossible to be achieved by the alternate: try to write a piece of code in your text editor by clicking mouse, for example. It doesn't substantiate the argument but the prejudices of the person presenting that argument.As to your specific example, what makes you think it would be a real challenge for the IDE-only crowd?

author: hans
author_rank: Super Contributor
timestamp: February 27, 2014, 01:26:08 pm
content: You make it sound like any software engineering or electronicsiswork. For me (and I guess many others here) it also a hobby (or 'therapy').Sure use the most preconfigured environment you can find where you only have to initialize a library and it does everything for you. Great, you got the application done in no-time. You have full bragging rights. 2 months later, a strange bugs arises and it's inside some library or closed module that you adopted. You don't know anything about how the program gets compiled on the particular platform, optimized, how the library exactly works, etc.As a a general rule: everything you integrate in your product is something you become responsible for maintaining & servicing, even it's a completely closed box to you. You're just screwed if a serious bug arises and you don't know much about it or better: you are not the person to solve it (because you don't have the source code/schematics). Hooray for dependencies.For example, at work we had this RF modem that locked up occasionally when we switched RF channels/protocol. Some customers were outrageous with our system. We communicated proactively with the manufacturer of the modem, and the response we got after 12-months of troubleshooting back-and-forth (with many stupid did-you-plug-it-in questions in between) was: we have problems with this RF broadband SoC which locks up, and the manufacturer of that chip is unable to fix their firmware problem. Unfortunately our HW does not have the RF SoC reset line connected to our uC.A deeper understanding will give more control and flexibility over your projects. I'm still not certain where you're going with this "I only care about getting the job done", in a thread that's clearly about setting up an environment for home/hobby projects, which IMO is about learning & experiencing.Back on topic:I'm also getting into Linux, and it seems like AVR & ARM have pretty good GCC toolchains. Microchip supplies a full IDE that runs on Linux, but the compilers are separate installation. I guess you could easily write your own makefiles for them , there is even a command-line debugger utility (not GDB though).However, for any toolchain I still prefer debug functionality , which especially handy for debugging device drivers. So I probably will try MCP and ARM (STM32F4) first.

author: westfw
author_rank: Super Contributor
timestamp: February 28, 2014, 01:11:57 am
content: QuoteStepping back from the raging debate, I'll go and say that MOST modern microcontrollers can be developed using good to great linux toolchains. Certainly anything that gcc supports, which is pretty much everything but the 8bit PICs (which have a linux compiler from Microchip) and 8051 (which has SDCC.)The main complicating factor is that you may have to search, work, and/or struggle to put together the various pieces into your particular flavor of "great." So you load up netbeans/eclipse/codeblocks as your IDE, and some version of gcc as your compiler, and some Nth-party bit of code that connects your hardware (which you may have to buy) to your debugger, and then you have to do all the configuration so that they work together. (Did I mention that half of those will have to be compiled from source, sending you down a deep OSSW dependency wormhole that can be ... very frustrating?)And then there's the whole window-compatibility layer that comes with linux. I run one of the PIC8 C compilers under wine on OSX, and that works fine (it doesn't seem to work with more complicated tools that have a "license manager" layer. At least, I haven't figured out how to make it work.)

author: andyturk
author_rank: Frequent Contributor
timestamp: February 28, 2014, 03:05:23 am
content: Quote from: dannyf on February 27, 2014, 12:31:33 pmWell, I've worked with some folks that are members of the "IDE-only crowd." These are very smart people with advanced EE degrees from top-notch schools--they can do math that would make my head explode. But they're helpless when it comes to fixing problems outside the scope of what the IDE does for them.Not everyone who uses an IDE falls into that category, but if you don't know how the underlying toolchain works (sufficiently well to use it directly), then you're probably going to be asking someone else for help on a regular basis.IMO, a good test is to give someone a blank machine (i.e., fresh OS install) and see if they can bootstrap their dev env without outside help. If they can download everything they need, and build the application given only the URL of the git repo, then they're in the "gets shit done" category, and those are the folks I want to work with.If you can "get shit done" with your IDE, that's totally cool too.

author: dannyf
author_rank: Super Contributor
timestamp: February 28, 2014, 11:54:22 am
content: QuoteThanks.I am still trying to find out what's so peculiar about the make file you posted that you think it would be a real challenge for the IDE-only crowd.Any help there would be greatly appreciated.

author: calin
author_rank: Regular Contributor
timestamp: March 01, 2014, 03:58:55 am
content: Here is a quick list what i use - hobby and serious work mostly open source stuff:AVR - avrgcc very good supportMSP430 - mspgcc very good supportARM - all flavors and manufacturers excellent support (google linaro gcc toolchain)8051 - supported so so byhttp://sdcc.sourceforge.net/. Only selected chips - for example the CC254x BLE from Texas need IAR to workPIC - sdcc frree but not for all PIC's and of course MPLAB (which is nothing than the Netbeans IDE with plugins from Microchip)Advice: Use the MAKEfile Luke !!! let the IDE on the dark side of the forceTake this from a software guy that writes code for the linux kernel and lives from writing device drivers. I use an modern IDE for editing but build is all based on makefiles .. nothing replaces the human brain (even if we don't really understand it)As for a guy that does programming and is not capable to build an executable without an IDE ... most likely he is working in the wrong field. I never saw a decent software developer or good engineer which is not capable to understand or write a makefile . Sorry for the rant .. but that is a FACT.

author: zapta
author_rank: Super Contributor
timestamp: March 01, 2014, 04:55:49 am
content: Quote from: calin on March 01, 2014, 03:58:55 amDoes this provide you easy jump from error messages file/line number to source code? What about auto completion, while-you-edit error marking, refactoring, etc? IDEs are not just for batch building of the program, they provide a major productivity boost.

author: calin
author_rank: Regular Contributor
timestamp: March 01, 2014, 05:41:29 am
content: Quote from: zapta on March 01, 2014, 04:55:49 amYes, you get all the benefits. I use now Netbeans C/C++ and used Eclipse .. just switched to netbeans about a year ago as I find it more civilized because it does not stick its nose in my work more than I need. You have code completion (code completion in a IDE is not a function of the build process it is actually the AST/abstract syntax structure which is created by all modern IDE's using clang or llvm) , also you have hoover based navigation and all kinds of other goodies like code re-factoring using AST. Jump to the error line is a simple console feature that is built into both eclipse and netbeans - just think errors are actually printed to stderr so is enough to get a line number out from an compiler error. Compiler error messages are somewhat standard for all compilers -- easy.Beleive me .. i do c by 20 years now and nothing replaces the fine control what you have in a makefile for the build process ... you spend more time scanning around a forest of checkboxes and drop downs scattered around a bunch of tabs than you will just type an 4-5 chars option in a makefile. All you need is to write a first Makefile and reuse ...

author: westfw
author_rank: Super Contributor
timestamp: March 01, 2014, 06:39:11 am
content: Makefiles always seem to expand in complexity till only a few people at a given organization really understand them, and they seem to be based on pretty much a crock of hack of a "language." (otherwise we wouldn't need automake, right?)

author: nctnico
author_rank: Super Contributor
timestamp: March 01, 2014, 10:46:18 am
content: Quote from: calin on March 01, 2014, 03:58:55 amAdd any 68k based controller (Freescale) and most Renesas controllers to that list.

author: westfw
author_rank: Super Contributor
timestamp: March 01, 2014, 11:56:18 am
content: Also PPC, MIPS, Sparc, and x86. Though I guess those don't show up as often as "microcontrollers" (excepting PIC32, which is MIPS.)(I keep expecting x86 microcontrollers to show up. But perhaps the tools and education advantages are too much advanced toward the very big CPUs.)

author: Marco
author_rank: Super Contributor
timestamp: March 01, 2014, 01:11:14 pm
content: I wouldn't call them microcontrollers, but Intel Quark is getting in the same range as the MMU ARMs.

author: dannyf
author_rank: Super Contributor
timestamp: March 01, 2014, 01:25:29 pm
content: QuoteAlternatively, you can click a button and let the IDE do its magic.

author: dannyf
author_rank: Super Contributor
timestamp: March 01, 2014, 01:27:07 pm
content: End of the day, it is your knowing where your value-add is and maximizing return on your investment (time and money and knowledge, etc.)

author: TerminalJack505
author_rank: Super Contributor
timestamp: March 01, 2014, 01:51:28 pm
content: It seems like you can always tell the hobbyist programmers from the professional developers by whether or not they know how to use makefiles.A hobbyist (or a professional who only works on small, rinky-dink projects) can get by building their software from the IDE.Once you have a big enough project that you have to automate the build process then you need makefiles. (Or a similar build mechanism.)No onebuilds using the IDE for automated builds.

author: dannyf
author_rank: Super Contributor
timestamp: March 01, 2014, 01:53:23 pm
content: QuoteA more accurate statement is probably this:Quote

author: andyturk
author_rank: Frequent Contributor
timestamp: March 01, 2014, 02:28:20 pm
content: Quote from: dannyf on March 01, 2014, 01:53:23 pmAlright, Mr. Contrary... Could you please regale us with a story of doing automated builds/continuous integration with one of those whiz-bang $5K/seat IDEs?

author: TerminalJack505
author_rank: Super Contributor
timestamp: March 01, 2014, 02:45:52 pm
content: I don't know why you would even want to use an IDE for automated builds. Automated builds don't really need the functionality that an IDE provides.Ideally, you wouldn't even need to have a monitor hooked-up to the build box. It would just sit there and run builds, as needed, and notify someone (via email, typically) when something noteworthy happens (the build fails, for example.)Automated builds do more than just compile code. They also retrieve code from version control and run unit tests, among other things.

author: dannyf
author_rank: Super Contributor
timestamp: March 01, 2014, 02:55:35 pm
content: QuoteRead the earlier posts and you will know.

author: nctnico
author_rank: Super Contributor
timestamp: March 01, 2014, 03:11:07 pm
content: Quote from: TerminalJack505 on March 01, 2014, 02:45:52 pmI agree. At some point it becomes messy to try and support several products with a shared code base using an IDE. Too many things can go wrong especially when working with multiple people.

author: zapta
author_rank: Super Contributor
timestamp: March 01, 2014, 03:29:13 pm
content: Quote from: TerminalJack505 on March 01, 2014, 01:51:28 pmDuring the day I am working on a ginormous multi language/platform/product code line with all the fancy shmancy tools and systems for automation, testing, analysis, collaboration, productivity, production management, you name it, and on top of it I have my own set of scripts/aliases to make things even easier (e.g. 'm' for 'make' and 'r' for 'run').Working in the evenings on small open source projects for fun I took a simpler approach, doing my avr/C++ work using the the Arduino IDE. The needs are different and having a simple development environment that other can easily setup and master makes my projects more open.Different strokes for different projects.

author: TerminalJack505
author_rank: Super Contributor
timestamp: March 01, 2014, 03:40:59 pm
content: Quote from: zapta on March 01, 2014, 03:29:13 pmI agree. One person projects rarely need a complicated build system. IDEs work fine for small, one person projects.You obviously know your way around a makefile, though, and realize that the IDE isn't always the end-all, be-all with regards to software development. And that's what I'm trying to say.

author: dannyf
author_rank: Super Contributor
timestamp: March 01, 2014, 03:47:08 pm
content: Quotemakefile / commandline [or anything you put here] isn't always the end-all, be-all with regards to software development.QuoteThat's the same thing the other side is saying too.

author: TerminalJack505
author_rank: Super Contributor
timestamp: March 01, 2014, 04:19:44 pm
content: I guess we're going to have to agree to disagree on the whole matter and leave it at that.Especially since it's completely off-topic to the original post.

author: calin
author_rank: Regular Contributor
timestamp: March 02, 2014, 02:11:08 am
content: OMG !!! I started a religious war... ultimately everyone uses what he thinks as being the appropriate "hammer" for the job.Yet I still reserve my right to not hire a C programmer that says does not know Make. Fair enough?

author: kshitij
author_rank: Newbie
timestamp: March 02, 2014, 04:47:54 am
content: All this fighting, when the guy simply asked for a list of embedded dev toolchains supported on the Linux platform. Definitely looks like an EE forum.R2D2, most toolchains supported on Linux either use GCC or vendor-supplied (aka, patched GCC source wrapped in a BSD-ish license) software. You can find most of the targets here:http://gcc.gnu.org/install/specific.htmlAssuming you are a beginner, just pick one with good documentation (this means actual documentation, for e.g. AVR-Libc, ARM, MSP, PIC etc. , not the GCC compiled docs) and nice forum support (PIC, AVR, MSP, some ARM vendors). Donotbother with the toolchains which go with the 'ask-our-mailing-list' routine.To make life easier, maybe start with a 8 or 16-bit device, before moving on to 32-bit. To avoid the command line, use the vendor's IDE (most of them are free). I can't guarantee that all IDE's support Linux, though most do, by using plugins for Eclipse/NetBeans.To have fun, post another thread asking for the best microcontroller on this forum.

author: andyturk
author_rank: Frequent Contributor
timestamp: March 02, 2014, 07:31:06 am
content: Quote from: kshitij on March 02, 2014, 04:47:54 amThis advice is pretty common around here, but I don't understand it.From a hardware perspective, many of the modern 32-bit mcus are super-simple. Give 'em 3 volts, maybe with a few decoupling caps, and you're good to go. Sure, you may have to learn how to solder a QFP, but that's a pretty low hurdle. From the software side, the most complicated thing is the reboot sequence, and that's almost always handled by vendor supplied code or an RTOS.Once your main() is running, the 8- and 16-bit processors are *harder* to program than a 32-bit mcu. One reason is because C works most naturally on architectures where the size of a pointer is the same as the size of an integer. Another is that the smaller mcus sometimes require bank switching gymnastics to address anything more than a trivial amount of memory. 32-bit architectures almost always have memory-mapped peripherals, so you don't have to mess around with assembly language instructions. In fact, on ARM Cortex, it's possible to boot the processor and run your application without requiring a single line of assembly code. That's very cool. And getting back to the topic of this thread, going with a 32-bit mcu means you can use GCC.IMO, beginners should start with 32-bits now unless they have a very specific reason to use a rinky-dink, legacy processor.

author: dannyf
author_rank: Super Contributor
timestamp: March 02, 2014, 11:30:23 am
content: QuoteTry to get the adc to work on earlier LM4F120 or those luminary chips; Or ethernet on those same luminary chips.You may lose hair, potentially lots of hair.

author: nctnico
author_rank: Super Contributor
timestamp: March 02, 2014, 12:55:50 pm
content: The STR700 series from ST is another fine example of a complete joke. Fortunately you don't have to use those. There are many good ARM controllers with proper documentation and libraries for USB, ethernet, etc.

author: jancumps
author_rank: Unknown
timestamp: March 02, 2014, 01:10:38 pm
content: Quote from: calin on March 02, 2014, 02:11:08 amif you have a say in who's hired: yes. You can do as you please.

author: zapta
author_rank: Super Contributor
timestamp: March 02, 2014, 07:53:03 pm
content: Quote from: calin on March 02, 2014, 02:11:08 amIf you want to give such a high importance to arcane and counter intuitive technologies like Unix Make it is your perogative. ;-)http://freecode.com/articles/what-is-wrong-with-makeCompare it for example with a more modern build system with a rich library of task oriented ruleshttp://ant.apache.org/manual/index.htmlBack to the topic: OP did you get the information you looked for? Which MCU family do you incline to use?

author: jancumps
author_rank: Unknown
timestamp: March 02, 2014, 08:53:26 pm
content: Quote from: zapta on March 02, 2014, 07:53:03 pmEver had a peek into the CONTRIBUTORS file in the root of your Ant installation?

author: suicidaleggroll
author_rank: Super Contributor
timestamp: March 02, 2014, 08:55:00 pm
content: Quote from: zapta on March 02, 2014, 07:53:03 pmYou're missing the point. While I can't speak for calin, I can speak for myself, and I have the same rule. It's not about testing whether or not they know make, make isn't the end-all of build tools, and any decent programmer should be able to adapt to whatever environment they're placed in. It's about testing their programming experience level and comfort with standard build tools. As I have found (and I assume calin has also found), most "programmers" who only know IDEs (and usually just one specific IDE) and have no experience with vi, emacs, make, gcc, etc. aren't actually programmers. They suck at algorithm development, troubleshooting, working through problems, etc. They google for a command, plug it in verbatim in the IDE, and when it doesn't work they run back to their supervisor to ask for help. It's like hiring a mathematician who needs to use a symbolic math tool to solve for 2x=4.

author: dannyf
author_rank: Super Contributor
timestamp: March 02, 2014, 09:06:26 pm
content: -While I can't speak for calin, I can speak for myself, and I have the same rule. -what's the point of having a rule or right if you don't get to exercise it?I for one care about getting shit done, not how someone gets it done.if I ever get a micro manager who insists on a way to do things, I will fire him or her on the spot - if a manager is so micro focused, he has no brain and has no vision. You will never learn anything from him or her so better move on now.-. As I have found (and I assume calin has also found), most "programmers" who only know IDEs (and usually just one specific IDE) and have no experience with vi, emacs, make, gcc, etc. aren't actually programmers. -I have to confess that that has never been my experience.this whole discussion boils down to where you think your most value add is.

author: Rigby
author_rank: Super Contributor
timestamp: March 03, 2014, 12:22:04 am
content: If they insist on a particular way to do something WITHOUT A GOOD REASON I think you mean. sometimes there's a very good reason the build process is the way it is.

author: andyturk
author_rank: Frequent Contributor
timestamp: March 03, 2014, 05:05:15 am
content: Quote from: dannyf on March 02, 2014, 11:30:23 amHeh. Most of my hair went years ago, and much of it to digging around in Eclipse/CCS. ;-)

author: andyturk
author_rank: Frequent Contributor
timestamp: March 03, 2014, 05:18:37 am
content: Quote from: zapta on March 02, 2014, 07:53:03 pmI've used both ANT and Make, but wouldn't really consider ANT for firmware builds because it pulls in a bunch of "moving parts" related to Java. ANT is great for server-side Java work though.The "What's wrong with Make" has a few good points--the tool ain't perfect. But if you can standardize on GNU make, it's possible to have makefiles that are fairly portable (if you're willing to dip into semi-obscure conditionals and functions). The biggest problem I've had with cross platform make is getting it to work well on Windows. Some ports of make will bring a Windows box to its knees while trying to figure out which rules to apply. Oddly enough, the one that comes bundled with TI's Code Composer Studio works pretty well.

author: calin
author_rank: Regular Contributor
timestamp: March 03, 2014, 05:56:49 am
content: Quote from: suicidaleggroll on March 02, 2014, 08:55:00 pmTrue ... i could not have said that better myself . How anyone can call himself a C or UNIX/Linux developer wen he is not able to write a makefile ? answer is simple .. the guy is giving you bull^@% for sure.And yes ... i have a say in the hire process; where I am now you pass by me and you are in. And I am not a manager, nor i ever behave like one now or in future .. just that i am decent at what I do and my say matters a lot. Lucky ..yes, make suks but still is the most used build tool for C/CPP by far; sooner or later you will have to "make" something no matter how much you dance around. ..use scons, cmake, .. use ant .. use whatever your heart likes.

author: Kjelt
author_rank: Super Contributor
timestamp: March 03, 2014, 08:04:26 am
content: Depends on the job, in our line of business we never hire a c programmer if he can't read and understand an electronic schematic, without electronics knowledge he is useless as a close to the hardware, embedded software programmer. Does not matter if he can make a makefile, enough other people to do that, as long as he can get his specific job done. I agree linux programmers are a different ballgame.

author: nctnico
author_rank: Super Contributor
timestamp: March 03, 2014, 10:56:27 am
content: About 2 decades ago I was asked to write a makefile as part of a test. After a bit of brain crunching I came up with this:Code:all:cc in.c -o in.exeIt was a bit frowned upon but they had to admit it would work O0 Today I'd still need to use a manual to put a makefile together if I want to use the more advanced option. Most of the software I encounter uses a (generated) makefile to build. Oh and I didn't take the job; I found something more interesting.

author: dannyf
author_rank: Super Contributor
timestamp: March 03, 2014, 12:32:16 pm
content: -our line of business we never hire a c programmer if he can't read and understand an electronic schematic, without electronics knowledge he is useless as a close to the hardware, embedded software programmer. -bingo!that's knowing what is important about ones value-add.make or not, I need a guy who can code to the job. Nothing else matters.

author: ve7xen
author_rank: Super Contributor
timestamp: March 03, 2014, 12:54:24 pm
content: Quote from: andyturk on March 02, 2014, 07:31:06 amNot sure I agree. Getting a simple LED blinker is much much more difficult on a small ARM than on AVR or PIC. To build code that will run at all, you need to write a linker script for your target. Depending on what libc functions you want to use, you may need to provide implementations of stubs like kill and putc. You need to initialize clock distribution, power management, possibly watchdogs and PLL to get full clock. The chips, and build environment are a lot more complicated to set up. Once set up, I agree, but as a hobbyist with a comp sci education it took me at least a day of hobby time to get it all working together the first time around, which was pretty close to giving up and using something I was familiar with already.Of course if you use the vendor's tools, you don't have to do any of that, or it will be mostly automatic.

author: dannyf
author_rank: Super Contributor
timestamp: March 03, 2014, 01:02:35 pm
content: - a simple LED blinker is much much more difficult on a small ARM than on AVR or PIC. -absolutely true. Getting the tools up, understanding the environment, going through library documents and chip documents and be familiar with the registers and having your own framework to coding are difficult for a newbie.-of course if you use the vendor's tools, you don't have to do any of that, or it will be mostly automatic. -equally challenging with a commercial tool.

author: GiskardReventlov
author_rank: Frequent Contributor
timestamp: March 04, 2014, 06:20:58 am
content: What 32-bit uC can plug directly into a breadboard? I did a quick look and don't find any. Don't know if that matters to the OP but it's worth considering. There are adapters, but they are expensive, that allow those packages to go into a breadboard. The drawback to those all-in-one demo boards is that it's a one-chip pony. Now there's a lot of technology in those chips so might keep you busy for a long time but it is a limitation.

author: ve7xen
author_rank: Super Contributor
timestamp: March 04, 2014, 07:09:53 am
content: Quote from: GiskardReventlov on March 04, 2014, 06:20:58 amhttp://www.nxp.com/products/microcontrollers/cortex_m0_m0/lpc1100/LPC1114FN28.htmlNot surewhythey'd choose to do that, but hey, it's pretty cool. About the same price as an ATmega8, programmed via UART with built-in bootloader. Haven't tried one yet, but pretty nifty, then you can easily migrate to another LPC111x for production in SMD.

author: Kjelt
author_rank: Super Contributor
timestamp: March 04, 2014, 08:09:58 am
content: Quote from: GiskardReventlov on March 04, 2014, 06:20:58 amembeddedartists.com and Olimex.com boards most of them have the standard 2,54mm headers on the sides, solder a row of pins in and you are ready to go. Not all signals are available though.ah misunderstood the question.

author: westfw
author_rank: Super Contributor
timestamp: March 04, 2014, 09:37:26 am
content: There are quite a few PIC32 chips in DIP28.And a bunch of modules for otherwise SMT chips.

author: ElektroQuark
author_rank: Unknown
timestamp: March 04, 2014, 09:47:43 am
content: Quote from: GiskardReventlov on March 04, 2014, 06:20:58 amSome of the PIC32 range.

author: nctnico
author_rank: Super Contributor
timestamp: March 04, 2014, 10:23:42 am
content: I'd go for a module if you need a dip layout. A high speed CPU in a DIP package is asking for power supply decoupling problems.

author: GiskardReventlov
author_rank: Frequent Contributor
timestamp: March 04, 2014, 06:52:09 pm
content: Quote from: ve7xen on March 04, 2014, 07:09:53 amThat is nifty, good find, very cheap!I only did a search for atmel and stm so didn't find any.

author: GiskardReventlov
author_rank: Frequent Contributor
timestamp: March 04, 2014, 07:12:33 pm
content: Quote from: westfw on March 04, 2014, 09:37:26 amOk, lots of options!Right now I want to avoid modules for two reasons, price and DIY. As a naive enthusiast it's hard to learn about the subtle aspects of this craft. I feel in my bones that when I buy pre-made I miss out on acquiring those little bits of knowledge you get from DIY that you might not get right away with pre-made.

author: GiskardReventlov
author_rank: Frequent Contributor
timestamp: March 04, 2014, 07:19:48 pm
content: Quote from: nctnico on March 04, 2014, 10:23:42 amI'm not sure what you are talking about. But here's what I think you mean. You're saying that due to the coarse nature of a breadboard that a chip operating at high frequencies might go too fast for the power supply to respond and thus introduce "craziness" into your breadboard circuit and thereby limit the usefulness of laying it out on a breadboard. i.e. a failure from the startAm I close?I guess the question becomes at what frequency does the breadboard become a hindrance? 50MHz?The atmega32 I have runs at 16MHz and I haven't done anything other than blinking LEDs.

author: nctnico
author_rank: Super Contributor
timestamp: March 04, 2014, 07:52:28 pm
content: Quote from: GiskardReventlov on March 04, 2014, 07:19:48 pmYes very close. You might get away with soldering a 100nf MLCC capacitor to the power supply pins directly but it's still far from ideal. You may end up chasing problems caused by using a breadboard.

author: Rigby
author_rank: Super Contributor
timestamp: March 04, 2014, 08:09:31 pm
content: Quote from: GiskardReventlov on March 04, 2014, 07:19:48 pmThis is where a pulse/function generator and an oscilloscope would come in handy. I don't remember where, but I seem to remember reading or hearing that breadboards are useless starting at around 1GHz. That seems high to me, and it might have only been 1MHz.If you have a function gen that can go to 1MHz or more, and an oscilloscope, you can test it. Pop a square wave on two adjacent channels on a breadboard, then, as far away as you can, and still be in that channel, hook up a scope probe. Put channel 2 as near to the function gen as you can. Then, I would put CH1, CH2, and the difference between CH1 & 2 on screen all at once. Observe as you turn up the frequency. When the squareness of CH1 goes away or the signal is attenuated by 3db or more, you've exceeded the bandwidth limit of the breadboard.I honestly don't know what frequency this would be. I'm going to test it tonight and see.

author: Rigby
author_rank: Super Contributor
timestamp: March 04, 2014, 08:09:55 pm
content: .. I think. Anyone correct me if I'm wrong on that measurement technique.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: March 05, 2014, 04:56:55 am
content: Quote from: Rigby on March 04, 2014, 08:09:31 pmIt's definitely higher than 1 MHz. I'm working on a programmable load that's currently breadboarded up, and the SPI link between the uC and the DAC/ADCs is running at 4 MHz without issue, even through a couple of daisy-chained 6" jumpers. The uC itself had no issues running at 16 MHz flipping a couple of pins, but once I added the display and started flipping entire ports at once I started to get some fluctuations in the power supply that kept the display from working properly. Some extra decoupling caps and moving the linear reg right next to the uC all but fixed it. I still get the occasional hiccup now, but it's running well enough to test and develop the firmware before moving to the final PCB.While the breadboard and DIP uC did complicate things a bit, it was by no means a dealbreaker.

author: GiskardReventlov
author_rank: Frequent Contributor
timestamp: March 07, 2014, 08:21:19 pm
content: Quote from: suicidaleggroll on March 05, 2014, 04:56:55 amCan you share a picture of your setup? I've heard they're worth a thousand words. You can consider I have just started using a breadboard within the last month so seeing different setups helps a lot.

author: dannyf
author_rank: Super Contributor
timestamp: March 07, 2014, 08:31:11 pm
content: QuoteI have breadboarded (digital) circuits running off 50Mhz oscillators.I think this side of 10Mhz is fairly easy. North of 32Mhz, you want to be careful with those wires.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: March 07, 2014, 09:29:40 pm
content: Quote from: GiskardReventlov on March 07, 2014, 08:21:19 pmPicture a rainbow-colored rats' nest with a 128x64 graphical lcd in the middle, and you're 95% of the way there. I typically don't bother cutting and trimming every wire to the exact length when I'm breadboarding, since it's just a temporary setup anyway, and I'm usually rearranging things pretty often.I'll see if I can grab a decent shot tonight.