What would be important concept to learn for micro-controller development? - Page 1
Forum section: electronics / general

author: asgard20032
author_rank: Regular Contributor
timestamp: April 16, 2015, 09:43:09 pm
content: What would be important concept to learn for micro-controller development?- Interrupt- State machine- De-bouncing- DMAWhat else?

author: ruffy91
author_rank: Regular Contributor
timestamp: April 16, 2015, 09:44:41 pm
content: Methodology (modularising, testing)

author: nctnico
author_rank: Super Contributor
timestamp: April 16, 2015, 09:59:55 pm
content: Most important is to use a structured method to convert a problem into a software solution before starting to write a program.

author: Rick Law
author_rank: Super Contributor
timestamp: April 16, 2015, 10:45:37 pm
content: Quote from: asgard20032 on April 16, 2015, 09:43:09 pmIt depends on your goals and your current level and knowledge and skill.Cheshire the Cat and Alice in Wonderland had a similar Q&A:Alice: Would you tell me, please, which way I ought to go from here?Cheshire the Cat: That depends a good deal on where you want to get to.Alice: I don't much care where.Cheshire the Cat: Then it doesn't much matter which way you go.MCU can take you anywhere. So to get the most useful answer, you have to first decide what is your goal.

author: jmole
author_rank: Regular Contributor
timestamp: April 16, 2015, 10:50:07 pm
content: Quote from: nctnico on April 16, 2015, 09:59:55 pm+1, although with the caveat that a lot of the techniques mentioned (DMA, interrupts, etc) will only become apparently necessary after some initial playing around and testing.Your best bet is to find some kind of problem or project to tackle. Implementations are always boring when detached from reality, and begin to feel like schoolwork. Learn as you go.

author: asgard20032
author_rank: Regular Contributor
timestamp: April 17, 2015, 03:53:57 am
content: Quote from: nctnico on April 16, 2015, 09:59:55 pmQuote from: ruffy91 on April 16, 2015, 09:44:41 pmIts exactly sort of thing i am asking here : which method, methodology shall someone on the road to become firmware engineer/embedded system developer should learn/master. Is there some particular design pattern, algorithm, method/methodology, data structure etcTo put it more in context, i am verry good at programming, and i can make my way on mcu. Already worked on AVR (few hour), MSP430 and some PIC. I am helping some of my friend (other student) to learn the basic of mcu. But im trying to figure out what to show them that will most help them out on embedded system.

author: hamster_nz
author_rank: Super Contributor
timestamp: April 17, 2015, 04:53:46 am
content: Event driven programming (e.g. Finite State Machines) rates pretty high on a list from me - pretty much how to convert something into non-blocking code.

author: ruffy91
author_rank: Regular Contributor
timestamp: April 17, 2015, 05:05:22 am
content: Yes. For small MCUs state-event is the right thing. Learn him drawing state machines and event tables. If you draw a good diagram you can almost program it 1:1 as drawn.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: April 17, 2015, 05:14:47 am
content: Read datasheets meticulously. To do so, you will need to know the nature of the underlying architecture: RTL (register transfer level logic), the way that flip-flops (latches, registers..) and gates (general logic, adders, etc.) connect to realize peripherals (timers, UARTs, GPIOs, interrupt generators, etc.) and how they connect to internal buses, and ultimately to the processor core.A level lower than this isn't really necessary (i.e., how the logic is actually constructed, from elemental gates or transistors), but can be helpful to keep in mind where logic meets analog -- at the pins. A simple pin model (equivalent circuit) can be expressed with just a couple transistors and diodes, helpful to know if you're going to do funky things with the GPIO (or ADC/DAC, or anything) pins, like how fast they go, how many loads you can tie onto them (and what kinds of loads -- boring CMOS logic, or whatever kind of circuit you might happen to cook up).On the highest level, you will also need to know programming structure, the division of code into files and supporting information (headers, libraries..), and their contents ("functions" / "methods"). Drawing out the program flow using flow charts and UML diagrams can be immensely helpful. Or you can prod away, one line of code at a time (and refactor it later... or just leave it that way..).Finally, to connect the two, you need a language of choice. Almost always C, or some variant of it (Arduino code is plain C, dressed up with "wrapper" functions for all the hardware operations). The basic syntax is pretty reasonable, but there's a lot of subtle things to know about syntax, operators, compiler directives, preprocessing directives (defines, putting stuff in headers, etc..), and despite the high-level promises, sooner or later you will get into "implementation-dependent" statements.And for that, it's always useful to understand assembler, if even just to check the compiler's output. You probably shouldn't code directly in assembly (it's very tedious, and generally not easy to structure), but you may also encounter a situation where you need to optimize a key piece of code, and in that infrequent case, some heroic assembly can save the day.Learning all of these things, in complete depth, would probably take six months of focused study; and years to master (hopefully, spread around a range of platforms, reinforcing the information that's common to all, and diversifying your scope of solutions so you have a good idea what might be most suitable for a given problem). If you want to become an expert in the field, you absolutely can, and you will have no trouble whatsoever securing lucrative development projects with that kind of talent!But not to intimidate: you absolutely can do real projects with just a little study, especially with the simplest platforms like Arduino. Look up some examples, rewrite them a bit, see what works and what doesn't. If you're getting confused over what statements don't work together -- or how they're failing when they should be able to do something reasonably obvious -- you can read a bit more depth, on the functions themselves, on the underlying processor hardware, whatever -- and keep pushing your knowledge a little bit at a time. Often, the casual programmer is more skilled and knowledgeable than the college graduate!Tim

author: Psi
author_rank: Super Contributor
timestamp: April 17, 2015, 06:41:46 am
content: I agree about learning event driven coding.Learn how to make the MCU do a lot of tasks without blocking others using timer ticks to fire events.Learn about storing function pointers in arrays/structs to make callbacks when events occur

author: daflory
author_rank: Contributor
timestamp: April 17, 2015, 11:23:10 am
content: I agree with T3sl4co1l. Pick an architecture that appeals to you, and study datasheets, application notes, etc. I use PIC's in part because Microchip's datasheets are very thorough, as are their application notes and architecture handbooks. PIC's and other microcontrollers often have extensive internal peripherals available, and using them effectively requires studying the specific hardware.

author: 22swg
author_rank: Frequent Contributor
timestamp: April 17, 2015, 07:11:38 pm
content: Don't forget the hardware interface get this wrong and the software aint going anywhere...

author: westfw
author_rank: Super Contributor
timestamp: April 17, 2015, 07:22:04 pm
content: I wouldn't put DMA on the list. Many microcontrollers don't even have DMA."Methods for multitasking" should be added. (Interrupts and state machines are both tools in that direction.)

author: Psi
author_rank: Super Contributor
timestamp: April 17, 2015, 11:57:19 pm
content: yep, if you use delay_ms() you fail at microcontrollering

author: nctnico
author_rank: Super Contributor
timestamp: April 18, 2015, 12:18:21 am
content: I wouldn't get too anal about waiting. Sometimes the process can deal with a delay or making something multi-threading (like doing an I2C or SPI transfer) is just too much fuss for no gain.

author: Psi
author_rank: Super Contributor
timestamp: April 18, 2015, 03:20:10 am
content: Quote from: nctnico on April 18, 2015, 12:18:21 amDelay_us() is ok if you have a good reason. Delay_ms() not so much

author: SL4P
author_rank: Super Contributor
timestamp: April 18, 2015, 05:10:17 am
content: OK - I'm hooked.. !What level of discovery are you looking for?Hardware - schematic / supply / isolation / PCB development...Processor preferences - PIC / Atmel / Freescale... etcInterfaces - serial / analog / digital...Software - you seem to have that under controlOptimisation & DebuggingTick the ones you need help with and there'll be 10 responses to each - and a few more.

author: 0b01010011
author_rank: Regular Contributor
timestamp: April 18, 2015, 06:50:13 am
content: If your experience is only with Object Oriented languages like C#, VB.NET, etc., then you'll need to adjust to procedural languages, assuming you're going to do development in C or ASM.Some of the concepts are similar, you can have structures similar to classes in C; interrupts are like events etc...

author: westfw
author_rank: Super Contributor
timestamp: April 18, 2015, 07:03:52 am
content: The other thing that I've seen confuse a lot of people is the different types of memory and how they get used: "My Arduino has 32k of memory, but this tiny program that only has 4k of strings says it doesn't fit." "can I connect an external memory chip to my AVR to get more data/program memory?" "How can I get the compiler to use this SPI RAM chip for additional data?" "Why can't I do virtual memory stuff on my PIC?" "Why do I need to use PROGMEM on my AVR but not on my MSP430?" And so on...

author: 0b01010011
author_rank: Regular Contributor
timestamp: April 18, 2015, 09:27:14 am
content: Also if you're starting a new project, start with the very basics... get a 1hz flashing led going to prove your toolchain works and that you have oscillation etc. Then build from there bit by bit.

author: nctnico
author_rank: Super Contributor
timestamp: April 18, 2015, 10:56:29 am
content: And keep the blinking LED on every project. It is a very handy field service tool. Every product I make has a blinking LED to show whether the microcontroller is running. It has proven handy again and again and...

author: zapta
author_rank: Super Contributor
timestamp: April 18, 2015, 04:03:55 pm
content: Quote from: nctnico on April 18, 2015, 10:56:29 am"If a MCU runs without a LED, does it really run?"My take on things to learn1. Setting up the environment, hello world / blinky, debug printing, etc. Hardware debugger is optional.2. Multi tasking using a single thread. State machines, event driven / polling, etc.3. Drivers and I/O, registers, interrupts, etc. You can start with existing drivers (e.g. mbed) and then replace some of them with your own.4. Working with external peripherals, sensors, displays, buttons (debouncing), etc.#1 and #2 is architecture specific. #2 and #4 are more general.

author: nctnico
author_rank: Super Contributor
timestamp: April 18, 2015, 04:48:52 pm
content: Quote from: zapta on April 18, 2015, 04:03:55 pmYou never know. I've seen it many times with people who didn't include some simple way to test whether a device is doing something (or even has power). The field service engineer calls with the question 'How can I check the device is running?'. Without a blinking LED it often gets quiet for a long time before some obfustigated method (usually) involving a multimeter is whipped up. Then it turns out the field service engineer isn't very handy with using a multimeter or measures the wrong points. In the end someone from the R&D department has to go on site to plug the mains cord back into the outlet.