|
Is there a good general book on embedded programming design patterns? I feel like I always do things certain ways that are probably sub-optimal, at least compared to what smarter people come up with. I read libraries but a lot of the time they are either crap or else super duper arcane and tough to learn from. I feel like there's also a lot of little tricks that I just don't know and wouldn't figure out on my own or by reading code. Probably something focused more towards smaller micros and bare-metal stuff. Not so interested in embedded OSes right now. I guess some the big topic I would like are developing rock-solid serial drivers and protocols. But there's probably a whole bunch of other stuff.
|
#
¿
Feb 19, 2013 21:04
|
|
|
|
| # ¿ Apr 28, 2024 00:16 |
|
|
Funny, that's on my amazon wishlist along with this: http://www.amazon.com/Making-Embedded-Systems-Patterns-Software/dp/1449302149/ref=wl_mb_hu_m_2_dp I never know with O'Reilly books tough. Some are awesome and some are total duds.
|
|
#
¿
Feb 19, 2013 21:22
|
|
|
Victor posted:STM32F4xx goons: Would you care to describe your experience so far with the STM32F4xx? Hey great idea! I haven't used an STM32 yet, but I just got a job where it looks like I'll be doing quite a bit (so far I've just worked with smaller micros, AVR and PIC). I was thinking of picking up one of those dev boards, either a Discovery or the Chinese boards (or maybe both) to play with on my off time. I'll try to add resources as I learn about them. Does anyone have suggestion about using a discovery with a breadboard? The dual headers look a little annoying. There's also this but I'm not sure what I'd be giving up.
|
|
#
¿
Mar 24, 2013 23:29
|
|
|
Martytoof posted:Dual headers: Very annoying Yeah, I'm just going to buy one of these for now. http://www.digikey.com/product-search/en?mpart=STM32F0DISCOVERY&vendor=497 Actually I'll probably just buy both and figure out how to deal with the dual headers later.
|
|
#
¿
Mar 25, 2013 20:20
|
|
|
Martytoof posted:That's pretty much it. There's no way to plug it into a breadboard without shorting each pair of pins. At least with single headers you can either use one breadboard (admittedly a little cramped), or two separate breadboards with lots of room to grow. This is like the best of neither and the worst of both. The worst thing is that there aren't holes for standoffs and the header the pins are longer on the bottom than the top, so it would be perfect it you could just snap it into a breadboard. It's a really ridiculous number of pins, too. I don't have a soldering station at home right now so it really limits me in terms of what kind of adapters I can cobble together, too.
|
|
#
¿
Mar 25, 2013 22:08
|
|
|
That doesn't sound like an IDE issue. Studio 6 just uses avr-gcc which should be pretty solid. Not sure what EWARM uses. As for your issue, there shouldn't be a whole lot to it. Have enabled interrupts with sei()? Have you written a handler with ISR() ? Is the interrupt itself disabled somehow?
|
|
#
¿
Apr 9, 2013 08:38
|
|
|
Oops, you're probably talking about ARM. I don't actually know. For the AVR 8-bit micros, everyone uses either Studio or a gcc toolchain with avr-gcc and avrdude. At work we use STM ARM and we just use gcc-arm-embedded, but we're 100% linux and just use gcc/make/etc rather than the fancy proprietary packages. But I didn't set up the toolchain and we have our own bootloaders and flashing tools. I would think something similar would be possible for the AVR stuff.
|
|
#
¿
Apr 9, 2013 17:08
|
|
|
There's only one formula for PID. I would think for a thermal system it shouldn't be too hard to find gains that work for a variety of conditions. You don't really need to bother modeling anything to use PID, you just tweak the gains.
|
|
#
¿
Apr 25, 2013 06:41
|
|
|
Uh you never have multiple cores and rarely have multiple threads (unless you are using some kind of crazy RTOS). An ISR needs to be a super-fast little thing that just does something like copy the value into a buffer and return. Then your regular code can read the buffer on its own time. As long as you keep your ISRs fast, it's like they're happening in the background but they really aren't.
|
|
#
¿
May 11, 2013 16:41
|
|
|
Yeah, exactly. What happens is that it takes 20 usec or whatever to read the ADC, and you get an interrupt when a new value is in. So you can do the read and wait in your main code, or you can do the first read on init, and have an ISR that takes the results and puts them somewhere and starts the next read or switches channels or whatever. Then the the main code just reads the results from memory. The ISR is just two or three instructions and it doesn't fire until the data is ready so it doesn't add much overhead. If you want even lower overhead or a certain precise sampling rate you can put the read requests on a timer (although usually timers are much more of a limited resource than cycles).
|
|
#
¿
May 11, 2013 17:18
|
|
|
What I don't get about this whole argument is that there already is a LGPL library (libopencm3) for STM32 with support for I2C, SPI, USART etc, and a complete gcc toolchain maintained by ARM. I think you can even hardware debug with gdb on the $15 dev boards.
|
|
#
¿
May 12, 2013 16:40
|
|
|
I think the trick with using C++ embedded is to start with a good understanding of C, and only incorporate those features from C++ that aren't too complex and that let you avoid dynamic allocation. If you just read a C++ book and start trying to use std:vector, you're headed for trouble. You certainly aren't going to get full OOP paradigm.
|
|
#
¿
May 15, 2013 16:23
|
|
|
I'm developing for STM 32 with gcc-arm, libopencm3 and sublime and the sublime-clang plugin and debugging via st-link using stlink as a gdb server, although our system is built up enough with comms libraries that I almost never touch gdb. It's pretty awesome, I don't really know what else I'd want. Sublime-clang is amazeballs. I'd think the vim clang would be similarly awesome but less pretty.
|
|
#
¿
May 16, 2013 04:34
|
|
|
Don't waste your time. An arduino/arduino clone is under $20. They're called BASIC stamps because they literally run BASIC. I don't think there has been much improvement on them in 8-10 years, and you won't be able to find accessories or much help on them besides websites from 2005 and old entry-level books that just tell you how to blink LEDs. Whereas Arduino is basically C and will let you transition to bare Atmega or a million other things easily.
|
|
#
¿
May 22, 2013 15:59
|
|
|
You can use the ST-Link with this: https://github.com/texane/stlink and just use gdb. Also, the Discovery boards from ST actually have an ST-Link on them, so if you get those to start out with you don't actually need a programmer.
|
|
#
¿
Jun 9, 2013 19:26
|
|
|
Victor posted:I'd rather you not mischaracterize me, either; I wasn't 'freaking out'. What annoys me is when I know something can be done better—including faster—and isn't. If I know there currently exist no better solutions and I can't think of how I would implement better solutions, I'm not going to complain. Hey, maybe you saw this already (or are the one behind it  ) but this just popped up on the libopencm3 mailing list: http://libopencm3.org/wiki/Run_From_RAMSo actually, it looks like it's 100% possible.
|
|
#
¿
Jun 11, 2013 04:17
|
|
|
Does anyone have an experience with MRAM? Was thinking of using some for a project because it has some really nice advantages over Flash, but it seems like it's kind of a new technology--the only commercial vendor seems to be Everspin, and it's their only product. Would probably be using the SPI verson. http://www.everspin.com/overview.php
|
|
#
¿
Jun 16, 2013 05:32
|
|
|
It's going to replace a larger flash that gets used for logging/daq. But the idea is that the speed, extra write cycles, and byte-addressable writes will let me use a more efficient data structures and just simpler code overall to make up for the smaller size.
|
|
#
¿
Jun 16, 2013 20:49
|
|
|
You should be able to get that kind of performance out of USB 2.0, but programming reliable high speed USB drivers can be pretty tricky from what I understand. I haven't done it myself but a coworker just finished a project where he was doing something similar and ran into a few surprises, despite being a guy who really knows his poo poo about comms.
|
|
#
¿
Jun 22, 2013 15:55
|
|
|
It depends on the micro, they have varying levels of USB support. With smaller micros, you usually connect a USART to an FTDI chip that takes care of all the USB-related trickiness and just makes your device look like a serial device. On STM32 it pretty much has full USB support built in, you might need a level shifter depending what voltages you are using.
|
|
#
¿
Jun 30, 2013 16:55
|
|
|
What kind of strategies do people use for sticking things like serial numbers in a binary? I'm using gcc, which produces elfs. I had assumed that if I just made a global variable, it would be easy to find a tool that would let me edit the .elf file in some sort of scriptable way, but amazingly there doesn't seem to be anything. The only thing I've found so far is making a .hex file and using the symbol table to figure out what offset to edit. I also tried writing my own tool using libelf, but for some reason the elf file I get is half the size of the original and the libelf docs are pretty bad.
|
|
#
¿
Jul 23, 2013 07:48
|
|
|
Pan Et Circenses posted:Run it again and it prints "v1.1". Use a simple bash script or whatever to customize the process to your heart's content. Just make sure you have a string that's sure to be unique in your executable file. Did I get the question right I hope? Yeah, I thought about doing that but it seemed a little dicey. Instead I made a linker section, put the variable in that section (something gcc does support), and then made a script that gets the offset of that section in the binary and and changes that location. That also let me put the data in a specific location in flash, which might be handy for debugging.
|
|
#
¿
Jul 29, 2013 16:48
|
|
|
I like AVR because at least you're using gcc. At work we use STM32 which I think has a decent open-source toolchain with arm-none-eabi, libopencm3 and stlink, but holy gently caress there is way too much going on for it to be enjoyable as a hobby project. If I didn't have way smarter people around to ask questions, and a big codebase to look through I would never be able to figure out how to configure the timers, much less the things that are actually tricky like USB.
|
|
#
¿
Sep 5, 2013 07:53
|
|
|
First, those are two completely different architectures separated by about 15 years. Second, both are still around. 68000 for various low power embedded type things--the "Dragonball" chips used in Palm devices were 68k based, and now god knows what still used.them but you can certainly buy them. I would guess that there's a few in your car or household appliances. As for PowerPC, http://www-03.ibm.com/systems/power/hardware/. You can get a system with several 16-core 5ghz POWER7s. Or several hundred.
|
|
#
¿
Sep 5, 2013 10:37
|
|
|
I wouldn't bother with an RTOS unless you need a networking stack or USB devices or something equally gnarly and annoying. The point of microcontrollers is that they have a whole lot of hardware that makes an OS unnecessary (lots of UARTS, hardware timers and interrupts, other peripherals like RTCs, and memory-mapped flash), and don't have a lot of the hardware that you need to make a modern OS like MMUs. Use the hardware! OSes also serve a lot of functions that you are unlikely to need or are impossible on a uC, like loading programs into RAM, managing filesystems, dynamic memory allocation, as well as introducing a ton of state. State is pretty much the enemy of reliable embedded design. Even a superloop is rarely necessary and a lot of people get off on the wrong foot by using them.
|
|
#
¿
Sep 6, 2013 18:52
|
|
|
Yeah, the the point of state machines is that you can write provably reliable code that runs forever. With an RTOS you're always kind of hoping that your stack won't eventually overflow or that your heap won't become so fragmented that you can't malloc. If you use an interrupt-style architecture, you can literally have 100% static allocation, and a stack with only a single frame at a time. And you can make explicit performance guarantees rather than trying to worry about your scheduler and thread switching time and preemption and all that poo poo. It just depends what you are doing. If it's a fairly high level task, an OS might make sense. The lower you go, and the more you need something that does one thing reliably, the more state machines or loops make sense. To say they're just for greybeards who don't understand OOP is just hilariously wrong.
|
|
#
¿
Sep 7, 2013 05:56
|
|
|
My work uses stm32 and gcc-arm. Our app is about 100k (binary) and uses basically every i/o channel on the chip. I almost never use a debugger, and I would trade a debugger for a bus pirate or saleae any day of the week. A lot if it is because our app was architected really well so there aren't a ton of surprises and its fairly easy to debug things programatically. I also do a ton of unit testing so any sort of higher level complicated logic is ironed out before I start trying to run it on the chip. Our application is pretty comms heavy and generally interrupt driven though so that kind of makes things not so hard, there just isn't a ton of complexity in most places. If we had an RTOS or 11,000 global variables or something I might feel differently.
|
|
#
¿
Nov 15, 2013 06:50
|
|
|
I kinda think that if your workflow requires that you spend a lot of time pressing F7 and watching numbers change in a watch window to figure out what your code does, you must have some pretty shoddy development practices.
|
|
#
¿
Nov 15, 2013 22:03
|
|
|
You can totally skip the arduino editor and libraries and just write bare metal code. You basically have a working board with a USB port, a bootloader, and tons of peripherals, it's not that bad a deal. If you're in windows you can even use Atmel Studio, which uses VS, and set it up to use the arduino flash tool. The chip manufacturers have cheaper dev boards because they sell them below cost, but there's less community support.
|
|
#
¿
Jan 4, 2014 20:53
|
|
|
Luigi Thirty posted:
Probably not. Can you give a link to the LCD board? There's a bunch of them.
|
|
#
¿
Jan 5, 2014 00:19
|
|
|
JawnV6 posted:
|
|
#
¿
Jan 5, 2014 04:38
|
|
I really doubt his choice of IDE is affecting the electrical connectivity all that much?
|
I think it depends a lot on the code you're talking about. For example, I recently wrote a logger that logged to a NAND flash chip. It had a ton of code because it had to deal with variable size entries, so I needed to maintain a sort of table-of-contents so we could do things like search by timestamps, clear old entries after reading without deleting new entries, etc. For that, I just wrote a mock flash driver and a buttload of unit tests. These didn't test anything related to the driver or the micro-controller, and they ran natively on my dev machine (luckily I'm using a 32-bit microcontroller). The flash device was just represented 4mb char array in memory, and I mocked out functions that accessed it and had the same erasure rules as my device. The driver code on the other hand I didn't really unit test. This was because it was mostly code that shipped bytes around and sent commands to hardware, and it would have been an order of magnitude harder to write unit tests in the conventional sense. However, I did write a low-level interface to the driver code and a bunch of test scripts that communicated with my micro over USB. This let me make sure I understood the flash device correctly and that my mock code would match the driver code's fairly well. As a result of all this, I didn't have to debug any of the "business logic" on the device itself, which would have been really difficult. What errors I did find were mostly minor timing issues or spots where I had misunderstood the data sheet. Plus, when I went back to add stuff much later, I could be fairly certain I wasn't loving things up due to me not remembering details of the (probably overly complex) high-level logic. At a minimum, I would aim for some level of automated testing. User testing is incredibly time-intensive and you will miss stuff. You really need to be writing tests incrementally as you develop code and running them constantly--whether that is unit tests or test scripts that talk to the device directly. evensevenone fucked around with this message at 05:57 on Jan 31, 2014 |
|
#
¿
Jan 31, 2014 05:55
|
|
|
Arduinos are just normal atmega processors with a bootloader, and a bunch of (lovely) C libraries and a terrible IDE. But you don't have to use the libraries or the IDE. avrdude supports the arduino bootloader even.
|
|
#
¿
Sep 4, 2014 17:41
|
|
|
I've used libopencm3 quite a bit, it's pretty nice especially if you get code completion set up in your editor, although most of the drivers are pretty low-level. I've never heard of anyone using clang, but GCC's error messages have gotten quite a bit better in 4.8/4.9. I can't really imagine embedded c++ being at all enjoyable. Our main project (in C) doesn't even use dynamic allocation and that's a pretty standard practice, and serious embedded requirements are even more strict (no recursion etc). https://github.com/blacksphere/blackmagic is a pretty cool open-source alternative debugger; the big difference is that it just implements the gdb server on the debugger hardware itself, so you don't need openOCD, which can be a bit flaky.
|
|
#
¿
Dec 3, 2014 19:36
|
|
|
Satellites.
|
|
#
¿
Dec 8, 2014 21:52
|
|
|
I would really consider using something like a BeagleBone Black or even a cheap laptop as the master, and just make all of your devices be USB devices. Unless you have hard realtime requirements >100hz or something. Then you can have a decent number of devices on a single bus, devices can be far away, enumeration etc is handled automatically. Lots of micros have USB support with DFU, so you can even update firmware etc via USB.
|
|
#
¿
Dec 12, 2014 00:37
|
|
|
Yeah, you need a build of gcc that is set up for cross-compiling. gcc-arm-none-eabi is the correct thing there. Then you will build with "arm-none-eabi-gcc", debug with "arm-none-eabi-gcc" etc. You'll need to look into how a Raspberry Pi actually boots. My guess is that it has a bootloader stored in ROM somewhere that knows just enough to get the external RAM and SD card running, and reads a bootloader stored in a file with a predefined name on SD-card that eventually loads Linux. So you probably can get away just replacing that file with your FreeRTOS image. I'd recommend getting JTAG going as well, it'll probably be a fair bit of work before you even have a serial port up and running so having a hardware debugger is pretty useful: http://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/
|
|
#
¿
Jan 7, 2015 09:34
|
|
|
This might be stretching the limits of this thread, but anyone have any experience with Yocto or similar "embedded" Linux distributions? My work has a fairly decent-sized project that runs on what have become basically headless linux boxes that run Debian, but I'd like to further automate the process of building install images (right now we just install everything to the physical device and dd the boot drive, then install to other devices off that, but it's kinda time consuming). I'd like to get it to a point where building the image could be 100% automated and hooked into CI.
|
|
#
¿
Mar 1, 2015 21:51
|
|
|
Also watch out, because flash can only be erased on a sector by sector basis, and i'm guessing that the AVR only has the three sectors (bootload, application, and program data) and they aren't subdivided further. So you can write, but if you want to change anything, you need to erase the whole thing.
|
|
#
¿
Mar 5, 2015 02:30
|
|
|
|
| # ¿ Apr 28, 2024 00:16 |
|
|
feedmegin posted:I'm kind of surprised noone's ever tried to reverse engineer the commercial ones and come up with something better, to be honest.
|
|
#
¿
Jan 9, 2016 21:04
|
|