Is ARM programming worth it ? - Page 1
Forum section: electronics / general

author: goldcoin
author_rank: Contributor
timestamp: July 17, 2015, 05:38:31 am
content: Is ARM cortex M4 programming worth learning ? Will it be a valuable skill in the foreseeable future ? Are there companies looking to hire such programmers ?

author: Kjelt
author_rank: Super Contributor
timestamp: July 17, 2015, 06:09:22 am
content: My two cents: its becoming harder to find an embedded sw job.Companies should develop their own platform for this micro andAlthough the Arm is a powerfull micro it still is Not so powerfull that it can handle as much as for instance an embedded linux platform. But other Arm micros can.If you like to develop for iot than i see the shift to standardized platforms such as emb linux because of the updates. Few Companies can handle regular firmware updates to keep for instance the security on par with the current threads.So my answer is twofold, it is important IMO to be able to write embedded c code but i would not focus on one controller and real jobs are scarce. if you want a job as an engineer for the Iot with a larger company i would now focus on embedded linux platforms.

author: Berni
author_rank: Super Contributor
timestamp: July 17, 2015, 06:16:35 am
content: ARM is very useful indeed. As soon as you start reaching past basic little MCUs there is a use for ARMs since they do make tiny ARM based MCUs. Then most stuff that has a large color LCD screen likely has an ARM hidden away inside it too.But its not like you specifically have to learn them. They will tend have more complex hardware peripherals, but apart from that its the same as any other processor out there when using high level languages like C. As long as you don't need to touch assembler its no different than anything else.Just go and give it a shot.

author: Jeroen3
author_rank: Super Contributor
timestamp: July 17, 2015, 06:29:15 am
content: Bonus to learning ARM Cortex M4, is that you also know the M3 and M0, they are only slightly different (in features they lack).Ahead comes Cortex A, on which you can run linux, which is created around the same concept.You can basically create code that isalmostbinary compatible across the entire ARM Cortex M family.Look at all the cores based on ARM:https://en.wikipedia.org/wiki/ARM_architecture#Cores

author: Rasz
author_rank: Super Contributor
timestamp: July 17, 2015, 06:47:30 am
content: Quote from: goldcoin on July 17, 2015, 05:38:31 amis there some special nonstandard way to program for those that I dont know about? Or did you mean experience with arm m4 in general? Good sw engineer shouldnt care what is under the hood, its just implementation details/semantics. What you should learn is CS in general, patterns, algos, data structures, few high level languages. Risc assembler(mips is a good simple clean start) if you are going to work with very embedded systems, but nowadays its possible to get away with C most of the time.

author: Howardlong
author_rank: Super Contributor
timestamp: July 17, 2015, 04:40:15 pm
content: Quote from: Rasz on July 17, 2015, 06:47:30 amIn general I would agree with that. While it is useful to be able toreadassembly and understand the basic architecture at a cursory level when debugging or performance tweaking, that is quite different to being able towriteassembly language especially in an efficient way.If you already have a background in programming in assembly language, you should be reasonably good in a few days if you have a juicy project you need to work on, at least that was my experience with M4F.I can't imagine ever writing an entire ARM implementation solely in assembly langauge, but there are a few places where it can make sense when you have pinch points in code. Before you do, it's always better first to analyse the code. Then you can optimise at the algorithm level, then the C code itself such as using inlining, then unroll loops, optimise and reorganise to make use of the limited number registers rather than hitting memory accesses, use compiler idioms and lastly builtins before hitting the assembler. I probably forgot some other things too. There are also implementation specific optimisations, such as organising code and data in separate memory areas and putting tight code into zero wait state memory areas.Once you're at the assembly language level, you need to consider how to avoid pipeline stalls, particularly avoiding instructions that make use of results of the previous instructions (often by interleaving logically functional operations), minimising memory access, and using load/store multiple instructions when you do access memory (which may mean reorganising your data structures), and making as many load and store operations adjacent as possible. Also be careful to avoid non-word aligned 32 bit instructions.All this jiggery pokery leads to fairly unreadable code, so I find myself using at least one comment per line of code.I learned all that mostly by doing over the period of a few days, but also with the help of the online ARM documentation, and a couple of pointers from others.Although I read assembly language most days in a debugger, it's far, far rarer that I actually need to write any.

author: Berni
author_rank: Super Contributor
timestamp: July 17, 2015, 05:15:04 pm
content: Quote from: Howardlong on July 17, 2015, 04:40:15 pmYeah explaining better to the compiler what to do is better than writing assembler yourself. But occasionally there is a point where you might be forced to use assembler. Some compilers might not magicaly implement an interrupt handler for you so you might need assembler there. Some chips have a lock where you need to do an "ASM dance" of writing to a register with cycle accurate timing to unlock. Or sometimes you might be tweaking an RTOS to run on your particular chip where parts of it must be in assembler.But those are mostly just special cases, usually assembler just involves reading it in the debugger to figure out what the compiler came up with or if you have a really weird bug.With 32bit knowing how exactly assembler works is less important tho. On 8bit MCUs its very useful to know about the CPUs capabilities in order to write efficient C code.

author: Jeroen3
author_rank: Super Contributor
timestamp: July 17, 2015, 06:38:06 pm
content: Knowing the special instructions available in a cortex m4 can get you a really fast routine.The Cortex M4 has some fancy saturating and parallel arithmetics. Same goes for endian swapping. The compiler won't use those for you.rtfm

author: westfw
author_rank: Super Contributor
timestamp: July 18, 2015, 01:54:23 am
content: I'll side with the "there is no such thing as "ARM PROGRAMMING"" people. Embedded programming principles span architectures, ARM chip peripherals are vendor-dependent (so being familiar with "NXP ARM peripherals and libraries" is not very applicable to "Atmel ARM chips"), AND "ARM" has become so broad a term as to not be very useful (Programming an STM CM0 embedded chip being much different from programming programming a multi-core 64bit ARM with Mali Graphics accelerator (and the latter being divided up into applications, os, libraries, and bare metal...))Education-wise, you would be better off taking an "embedded programming" class that isn't caught up in pretending to to teach the latest chip technology. Or several; covering more than one architecture. As a prospective interviewer, I'd be happy if an interviewee could explain differences between AVR, 8051, and ARM, rather than having an deeper knowledge of one of those... (An impressive class-level project would be something like "I ported the Arduino XXX library from Uno to a Freescale Freedom board.")All that said, learning "ARM Programming" would be better than learning some legacy architecture (like 8051 or PIC18.) (It's not that those aren't useful chips; it's just ... interviewers aren't immune to "latest and greatest" either.)(On the final hand, employers are sometimes in a "to hell with general knowledge; I need someone who has made I2C slave mode work on an STM32F030 chip, and I need them yesterday!" mode. In which case, if you happen to have done exactly that you look great, and if you haven't, then general knowledge probably won't help.)

author: Kjelt
author_rank: Super Contributor
timestamp: July 18, 2015, 06:46:52 am
content: Strange employer that requests such specific knowledge, then probably it is a very specialistic limited time job.

author: westfw
author_rank: Super Contributor
timestamp: July 18, 2015, 08:12:00 am
content: QuoteYes, they could be a jerk of a company and get rid of you as soon as the specific task is done. But there are always new problems, and the "this is what we need done now, and if you do an acceptable job then there will be more work for you to do" is a VERY common scenario (assuming, of course, that you're not a one-trick pony that can only do (or only wants to do) that first task.)

author: Kjelt
author_rank: Super Contributor
timestamp: July 18, 2015, 08:52:18 am
content: Might differ with different companies. The one I work for just gives the task to the SW engineer that has no task at the moment to sort it out. In this job you keep on learning never be able to rely on old knowledge, the last 5 years we changed brand microcontrollers four times and you just change with it. It can be very demanding, i sometimes envy the old craftmanships of the past. Learn till 20 as apprentice and then become a master at 30 and keep on doing it. On the other hand i am a very curious person never stop to experiment so i like challenges and new stuff. So IMO better be a master in C programming and apprentice on some type of uC then a master in a specific uC and apprentice in C.

author: Berni
author_rank: Super Contributor
timestamp: July 18, 2015, 09:55:41 am
content: Quote from: Kjelt on July 18, 2015, 06:46:52 amIt can start off like that. I was asked before by a tiny company to do some small task involving an obscure MCU since i had experience with it, gave it a shot and later on i ended up designing an entire product freelance.Needing a specialist might make them want you at first, but if you turn out to be useful you can expect them to try and use you for all sorts of things. Its difficult to quickly find someone that you can trust to get the job done.

author: Howardlong
author_rank: Super Contributor
timestamp: July 18, 2015, 11:01:13 am
content: I reviewed a job spec just the other day, it was so specific on the required skillsets that my response was that any applicant who claimed such expertise had either (a) already worked at the company in the exact role or (b) was a bullshitter. It's a bit like finding the perfect partner ot the perfect abode, neither exist, you have to be realistic and compromise, and be prepared to soften your requirements to desirables instead.Similarly though, on the other side of the fence in the past a perfect job has came up where I felt I was absolutely the perfectly round peg in the perfectly round hole, but the agency wouldn't put my CV/resume forward. In the end I found out who the job was with, put forward my details through someone I knew who worked there (nice referral bonus for them too) and got offered the job. Turned out the HR dept told the agency they could only put forward two candidates, which begs the question over the perceived value of agencies and HR departments, but let's not go there!Back to the OP, in general if you can write assembly language for a few devices already then I doubt there's much value in learning a particular flavour on the off chance something will come along. On the basis that you can convert to a reasonable skill level in a few days, then make the effort at that stage.If, however, you don't have any assembly language skills, then by all means it is worth learning at least one implementation, and Cortex M4 is not a bad start although tomsimplify things you might want to start at M0. Make sure you have a project in mind rather than just reading a book, there is a world of difference between reading and doing. Having knowledge of more than one architecture gives you an open mind as to how others might work too, and will make it easier if someone suddenly asks you to take a look at, say, MIPS. I remember trying to move from General Instrument LP8000 to Nat Semi SC/MP nearly 40 years ago, I just didn't understand that there can be quite fundamental archtectural differences, but I was pretty young then.There is also quite a sense of achievement in beating the compiler at its own game. The project on M4F I did recently yielded a four fold improvement on a bare unoptimized C implementation, but this wasn't just using assembly language, it was all the other stuff I mentioned too in my earlier post.

author: westfw
author_rank: Super Contributor
timestamp: July 18, 2015, 07:56:56 pm
content: Quote

author: Howardlong
author_rank: Super Contributor
timestamp: July 18, 2015, 08:15:02 pm
content: Quote from: westfw on July 18, 2015, 07:56:56 pmI think there is likely some truth in this, although in this case I think it was just one of the joys of centralised HR commanding the process. All this is kinda interesting as the outfit that asked me to review the job spec simply phone me up when they want me to backfill in for a few weeks, there's not even a tendering process, just a chat for a couple of minutes over the phone on availability and rates. It's not unusual for those few weeks of back fill to turn into several months either, while they scuffle about trying to find those elusive candidates.

author: lod
author_rank: Contributor
timestamp: July 19, 2015, 06:45:17 am
content: Quote from: blueskull on July 18, 2015, 08:47:37 pmExperience.I am never going to know everything that somebody else knows, it is an obviously unachievable goal. However I have experience in related fields which I can use for new projects.As others have already said, programming an ARM is 99% just normal C. Over the last few years I have done projects on big and little ARMs without significant difficulties. I have experience working with small micros and experience writing PC code, the ARM space is an interesting intersection of them both. The remaining 1% is reading the processor notes for chip specific optimisations.

author: Howardlong
author_rank: Super Contributor
timestamp: July 19, 2015, 09:02:48 am
content: Quote from: blueskull on July 18, 2015, 08:47:37 pmAs I mentioned before, if you already have a reasonable amount of assembly language experience, preferably across more than one platform, then picking up a new architecture and being able to write efficient code for it is no more than a few days' effort, involving reading, doing and having a relevant project to work on, probably one that uses the more esoteric instructions too.A reasonable employer should know that. But just knowing M4 is only part of the battle. In many cases an employer will already be using a particular vendor's chip, and a particular development environment. Knowing those in detail is more time consuming than just learning Cortex M4.(If I may draw a parallel, knowing C and C++ does not mean you will be able to pick up Java to a reasonably productive level in a couple of days. The language itself is easy, but knowing your way around all the Java baggage to be productive, such as libraries not to mention just the acronyms, is a whole different ball game.)

author: nctnico
author_rank: Super Contributor
timestamp: July 19, 2015, 12:31:08 pm
content: Quote from: Howardlong on July 19, 2015, 09:02:48 amI tend to agree. The basics of assembly is in knowing how a CPU executes instructions and what is involved with it (accumulator, flags, stack and on more modern CPUs things like special registers). With that knowledge you can program in assembly language on any CPU.

author: jnz
author_rank: Frequent Contributor
timestamp: July 19, 2015, 10:47:55 pm
content: Quote from: Howardlong on July 19, 2015, 09:02:48 amThat's putting it mildly. I really hate Java anymore. Between C on embedded and Python when I need to get something done dirty, I just have no time for Java.Just like everyone else said... This is no "Arm Programming" but... There are definite quirks with all micros, and knowing those per platform is valuable imo. I'm transitioning from PIC to ARM and other than "new-everything" it's going really well. I was days in and doing things on ARM I could never do on PIC.So, if you want to read the reference manual on Cortex parts, get some dev boards, go nuts.... But really knowing how to process a problem and what needs to happen for a solution (CS, logic) is more important than the code to solve the problem / specific micro architecture you are using.I'm glad I have a super-solid job and don't need to compete with you guys in an agency, interview, HR, contract work, bla bla bla game... Sounds exhausting!Edit: Now... If the title was is learning FPGA "worth it" (not sure what that means unless you're expelling things from your brain in order to make room for that knowledge)... Well, that would be a more interesting discussion.

author: Berni
author_rank: Super Contributor
timestamp: July 20, 2015, 10:58:56 am
content: Quote from: jnz on July 19, 2015, 10:47:55 pmExactly. Both a PIC and a ARM is thingy that runs pretty much identical C code. But when you get to FPGAs its a whole new can of worms. At that point be prepared to basically throw away all previous programming knowledge and start from scratch. So it takes a large investment of time and effort to learn it while a lot of employers might not use FPGAs at all, this makes it sort of less worth it. But a lot of employers will want you to be good at C so its kinda more worth it.But C is not the only common language. For things that run linux or for PC development other languages are a lot more common than just boring old C. That's where Java, Pyhton, Ruby etc are useful. I personally like to use .net for writing PC software. But for almost all things that have a CPU but don't run an OS you will be throwing C code at them.

author: Jeroen3
author_rank: Super Contributor
timestamp: July 20, 2015, 11:16:48 am
content: An FPGA is fundamentally different because you don't give an FGPA a series of programmed instructions to execute.You use Hardware Description Language (HDL) and not a Programming Language such as ASM.There are parts of both realms on the market. You can also get HDL ARM cores.So you can use small bits of logic to streamline your software. A bit like writing your own peripherals.Or vice-versa.

author: funkathustra
author_rank: Regular Contributor
timestamp: July 21, 2015, 07:47:41 am
content: Quote from: westfw on July 18, 2015, 01:54:23 amTotally agree. I'm a C programmer who avoids assembly like the plague (sorry, don't want to relive my C5000 DSP assembly programming days), so it's all basically the same to me. You basically just end up learning peripherals -- both when you're switching between ARM MCUs, and when you're switching between ARM and 8/16 bit architectures.And actually, I think ARM is easier to learn C programming on than most 8-bit architectures -- especially when using ARM MCUs with really simplistic peripherals.Other than the AVR stuff, (nice core, but really shitty chips), most 8-bit MCUs have quite a few peculiarities that come up rather quickly when writing C. I just started playing around with Silicon Labs' new EFM8 MCUs (which uses the ancient 8051 architecture) and about 15 minutes into programming, I was out of RAM. "Huh? How?" Oh, because on 8051, you only get 256bytesof fast IRAM -- everything else must be explicitly placed in XRAM (at least when compiling with Keil's C51 compiler, which I assume must be good, because it's $2200).On ARM, you just write C code and compile it and it just works, and it doesn't do anything screwy.Now, onto which ARM microcontroller you should learn. Anyone who's read my posts knows I'm a hardcore Freescale Kinetis fanboy -- I love the peripherals, and my pocketbook loves the prices. Kinetis Design Studio is beautiful, and Kinetis SDK gives you the same low-level control you get with CMSIS, without being nearly as verbose. And MQX is a really wonderful RTOS that's highly underrated....Having said all that, ironically, while a lot of people give NXP shit for not being a friendly platform for beginners, I think NXP's Cortex-M0 stuff is a great "first platform" for people looking to get into ARM. Having never touched their stuff before, it took me all of 15 minutes to get Code Red (err, "LPCXpresso IDE") downloaded, installed, and configured. In another 15 minutes, I imported their peripheral library and wrote a SysTick-based blinky project from scratch that I was debugging off-chip to an LPC1114 (in a DIP package!). 15 minutes after that, I got the UART printing "hello, world." Granted, I know my way around ARM MCUs, but there was not a single "gotcha" -- which is rare, even in this day and age! I didn't even have to crack open the datasheet or reference manual, or read the peripheral library documentation to figure out how to use it (you gotta love peripheral libraries that take more time to learn how to use then just writing your own HAL from scratch -- "wait, do I call gpio_init() before I pass the config structure to gpio_set_config()? What is gpio_start()? Does the GPIO library control the peripheral clock gating, or do I have to use the timer library to do that?")While I'd never use NXP's stuff in a commercial project (shitty pricing), I think I'd probably recommend it to a beginner if asked.