|
Oh, I've been doing this for over 20 years. Perhaps not as long as some, but I've used a wee little system or two. I'd wager to say that if you treat C++ as nothing more than C with encapsulation and support for true RAII semantics, you're way WAY ahead of the ANSI C game, and those features don't take any more overhead than their equivalent C implementations (essentially none). Remember, C++ generally doesn't add any overhead that you wouldn't get from implementing an equivalent system in C--it just allows you to implement much more complex systems without really realizing it. Anyway, as for putting together your own toolchain, getting it all linking right is going to be the real meat of the work.
|
#
?
Dec 2, 2014 07:35
|
|
|
|
| # ? May 11, 2024 12:06 |
|
|
Just getting started with an STM32 board. Is there a way to program it without having to use the ridiculous web-based Mbed compiler?
|
|
#
?
Dec 2, 2014 14:55
|
|
|
JawnV6 posted:Not yet. This has the air of painful learnings ahead. Why not just use GCC? It just works and it's easy to install.
|
|
#
?
Dec 2, 2014 16:38
|
|
|
That's where I got last night, if nothing else clang is still relying on gcc's linker. Got the install off launchpad, have it working in cygwin up til some missing symbols. I should probably be looking at the plentiful examples of working gcc chains instead of banging on the Cube's generated output. I'm wary of GCC because I've seen it take missing semicolons and use Boost to turn that into pages and pages of template errors. e: got it working with gcc, thanks for the tips! JawnV6 fucked around with this message at 19:19 on Dec 2, 2014 |
|
#
?
Dec 2, 2014 17:11
|
|
|
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
|
|
|
Crossposting this bit: A while back in this thread or the blue smoke one, someone posted a link to a blog where a guy was doing ridiculously fine-grained power measurements on a UART device. It was a little counterintuitve, since going into the deeper sleep mode meant the uart peripheral took longer to lock and had the device awake longer. Deeper sleep burned more power. Anyone know what I'm talking about and can pull up the link?evensevenone posted: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). This does bring up another niche holy war: where's the line between "embedded" and "firmware"? I've been using "an OS" or "RAM chip" as crude lines between the two, if the solution is complex enough to require those you're out of "firmware" and in "embedded".
|
|
#
?
Dec 3, 2014 23:05
|
|
|
JawnV6 posted:This does bring up another niche holy war: where's the line between "embedded" and "firmware"? I've been using "an OS" or "RAM chip" as crude lines between the two, if the solution is complex enough to require those you're out of "firmware" and in "embedded". Pretty much every router firmware is a is an is image. Linux/vxworks. To me, firmware only makes sense as some flavor of software that runs hardware in the background, or is not particularly easy to change. It doesn't really need to be embedded as such. Even the controllers that run thimgs like a computer cd/dvd/bluray/HD have firmware. Embedded has the connotations of adding computer controls to a thing particularly things that have not traditionally been computer controlled, or the hardware that enables that. So, you can have embedded processors, embedded systems, etc. I would say most (all?) embedded systems have firmware, I'd argue that even programs in mask Rom count.
|
|
#
?
Dec 4, 2014 03:41
|
|
|
In my experience in the industry pretty much any software that runs on a system to which the end user does not have direct access is called "firmware." "Embedded" I would say is just the engineering of such systems, so I guess you could say in my experience embedded engineers always write firmware. Just my observation from what I see other engineers say, and I usually do the same.
|
|
#
?
Dec 4, 2014 03:51
|
|
|
Secret santa at the office. I want to get a buddy into micro controllers and stuff. I am afraid if I get him just an arduino he'll never use it because not knowing a lot about the other stuff (leds, caps, etc) it can be intimidating to buy. I'd rather buy him a kit with a few projects to get him started. He's a web programmer so the issuue isn't with the code. Could someone recommend a kit that has a few projects and a micro controllers or arduino for <$35? Ideally something robotic, even if it's simple.
|
|
#
?
Dec 4, 2014 06:43
|
|
|
Tiger.Bomb posted:Secret santa at the office. I want to get a buddy into micro controllers and stuff. I am afraid if I get him just an arduino he'll never use it because not knowing a lot about the other stuff (leds, caps, etc) it can be intimidating to buy. I'd rather buy him a kit with a few projects to get him started. He's a web programmer so the issuue isn't with the code. Could someone recommend a kit that has a few projects and a micro controllers or arduino for <$35? Ideally something robotic, even if it's simple. The normal retail price of an Arduino Uno is usually somewhere between $25 and $30, so you're not likely to find a kit for under $50 that actually has a genuine Arduino (both adafruit and sparkfun have kits at that price, though). Just an Arduino and a tolerable servo is likely to run you more than $35 after shipping. If that's a hard price limit, you're probably either going to be looking at unlicensed imports or a lower scale microcontroller system like the Trinket Pro or Teensy 3.1. You can look at the components in a kit and often pick out similar items from a part supplier for cheaper since you're not paying for the labor of putting together the kit.
|
|
#
?
Dec 4, 2014 07:04
|
|
|
I'd recommend buying your coworker a Raspberry Pi or a BeagleBone if they're familiar at all with a Linux environment, they will probably feel more comfortable than on "bare metal". But then you've spent all your money on the platform and have no cash left for hardware to control. If you think they'll be ok without an OS, then get them an MSP430-based dev kit (http://www.ti.com/ww/en/launchpad/launchpads-msp430.html) and use the piles of leftover cash for peripherals. In the middle of the spectrum, I'd recommend a Cypress PSoC (or similar arch and environment) dev kit. I used one of these in school and you can use a GUI to configure most peripherals, including GPIOs, the onboard ADC, UARTs, etc. It's not as intimidating to control peripherals as the MSP430 but it doesn't have all the good stuff you get with embedded Linux. Unfortunately I'm pretty new at all of this, so I don't know a lot more than those several platforms. Maybe somebody else can chime in. I've used C++ in embedded systems for one project and enjoyed it. We weren't using a heap or stdlib, so I would characterize it as C with embedded accents than real C++. However, we took advantage of lightweight C++ constructs like references, abstract base classes/inheritance, namespaces and constructors/destructors (and I'm forgetting some other things). It was pretty easy and worked well on our target, where we were constrained to about 128 kB code and 8 kB in RAM. I'd recommend it just for objects and namespaces.
|
|
#
?
Dec 4, 2014 08:40
|
|
|
JawnV6 posted:where's the line between "embedded" and "firmware"? In my experience (EE university and the flight controls industry) 'firmware' is reserved for VHDL and Verilog, everything running on a processor is called software. But all of the software we produce is firmware to our customers (in the other sense): bootloaders, BSPs, low level drivers, etc.
|
|
#
?
Dec 4, 2014 15:08
|
|
|
meatpotato posted:If you think they'll be ok without an OS, then get them an MSP430-based dev kit (http://www.ti.com/ww/en/launchpad/launchpads-msp430.html) and use the piles of leftover cash for peripherals. Worth mentioning- MSP430s have Energia, an equivalent to the Arduino IDE. (Or 4e4th if you think your coworker might like Forth). You could easily combine a launchpad board with a "booster pack" expansion board that gives you a display or sensors or get a bunch of basic components for $35 or so.
|
|
#
?
Dec 4, 2014 15:57
|
|
|
Tiger.Bomb posted:Could someone recommend a kit that has a few projects and a micro controllers or arduino for <$35? Ideally something robotic, even if it's simple. Well, Dash (http://dashrobotics.com/) would hit the mark but it's a little over your asking price and not expecting to ship the next rev until September 2015.
|
|
#
?
Dec 4, 2014 18:51
|
|
|
So I got him a double edge razor instead lol... Thanks for the advice, though, guys. That robot looks cool and I might buy it now just so that I am pleasantly surprised when it arrives 9 months from now.
|
|
#
?
Dec 8, 2014 01:30
|
|
|
Out of curiosity, those of you doing this for a living, what kinds of things are you writing code for?
|
|
#
?
Dec 8, 2014 10:16
|
|
|
Without going into NDA-restricted details, I work for a company that's designs consumer fitness trackers (pedometers that sync with your smart phone). We don't market or manufacture the product, we just design the product and provide tools and support for factory production. I'm part of a very small team. A senior embedded engineer and I write firmware and a different senior engineer (he's only part-time on this particular project) writes software for the smartphone side of things. The company contracts a local layout engineer to design prototype hardware, he'll come in a few hours every month. When we have a stable platform, our client modifies the design to fit their refined requirements and then we test/develop on the new hardware for a while until we have something that can be sold. Most days I'm writing C but often I need to script some build-related processes in bash or sometimes python. I ought to learn Ruby soon, it seems nice for that kind of stuff. This is my first job out of college and I've been working here for 1.5 years, but I performed whitebox testing for the first six months and later upgraded to a developer.
|
|
#
?
Dec 8, 2014 20:06
|
|
|
My big project this year was a remote sensing unit. It does some capacitive readings to determine water levels, connects to the GSM network to upload results periodically, and has to last 5+ years. Every little microamp counts, I have 16kb total nonvolatile storage. When's the last time you wrote a program that had an expected runtime longer than a week? More than that is the testing/qualifying code. There's unit tests for each module, integration tests for the whole thing, production line test code to make sure the PCBA isn't broken, and PC software to talk to the test firmware and track units during mass production. JawnV6 fucked around with this message at 21:54 on Dec 8, 2014 |
|
#
?
Dec 8, 2014 20:45
|
|
|
I'm writing firmware for pressure and temperature instruments - gauges, transducers, calibrators, etc. I have some friends and acquaintances in the area that work on medical devices.
|
|
#
?
Dec 8, 2014 20:50
|
|
|
Satellites.
|
|
#
?
Dec 8, 2014 21:52
|
|
|
I write C for battery powered thermal weapon sights and night vision goggles.
|
|
#
?
Dec 9, 2014 00:15
|
|
|
JawnV6 posted:When's the last time you wrote a program that had an expected runtime longer than a week? In the past, auto industry -- some nodes lifetime is only limited by whenever you happen to swap out the vehicle battery, or it drops out of regulation. Nowadays it's all secret stuff.
|
|
#
?
Dec 9, 2014 00:20
|
|
|
Controls group for cyclotrons.
|
|
#
?
Dec 9, 2014 01:41
|
|
|
Avionics systems for smaller commercial fleets. Somewhat cumbersome from a regulatory standpoint, but still pretty fun.
|
|
#
?
Dec 9, 2014 08:06
|
|
|
evensevenone posted:Satellites. Hello Space buddy  I currently work on a mass memory for a Earth observation satellite. Everything in C with a poo poo load of testing of all kinds.
|
|
#
?
Dec 9, 2014 08:14
|
|
|
Le0 posted:Hello Space buddy I am also writing code for <REDACTED> and <REDACTED> but all the ground based stuff not FOC
|
|
#
?
Dec 9, 2014 11:17
|
|
|
Primarily writing embedded code for life science payloads destined for the ISS, but there are other commercial and government contracts thrown in, as well. Almost everything's C or C++ on embedded.
|
|
#
?
Dec 9, 2014 13:33
|
|
|
Radio transceivers. Also compilers/VMs.
|
|
#
?
Dec 9, 2014 16:41
|
|
|
It doesn't quite constitute a "living" yet (I'm a graduate student but a lot of my dev work is for contract pay), but I mostly make equipment for visual psychophysics testing. It's becoming more and more clear to me that I'm outgrowing the Arduino platform. Does anyone have any suggested reading for best practices for making microcontrollers talk to one another (preferably in a fashion that allows them to be modular)? I'd like to start fairly simple by moving user I/O away from timing-sensitive functions and while I'm fairly sure I know how to start, I'd prefer to start with good practices.
|
|
#
?
Dec 10, 2014 03:48
|
|
|
If you have a low data rate, you could use I2C worth multiple masters if needed. For higher data rates you could use a multidrop UART, but that really needs a single master to avoid collisions.
|
|
#
?
Dec 10, 2014 14:18
|
|
|
Hadlock posted:Out of curiosity, those of you doing this for a living, what kinds of things are you writing code for? My company makes wearable hardware, and I help out on the algorithms side of things (lots and lots of fixed point math).
|
|
#
?
Dec 10, 2014 17:07
|
|
|
Mr. Powers posted:If you have a low data rate, you could use I2C worth multiple masters if needed. For higher data rates you could use a multidrop UART, but that really needs a single master to avoid collisions. I should clarify. I have a small amount of experience interfacing uCs to one another (I prefer I2C when possible) but I'm looking for guidelines for best practices (both in hardware and in coding) to make modular circuits that can be changed by the user or quickly reconfigured to the user's specification. I'd like to eventually be able to produce hardware that can be purchased piecemeal so someone can buy the master units (which would be used individually) that they want (with highly specialized hardware) and then hook up whatever peripheral slave units they prefer with a minimum of hassle. That way, for example, someone could choose between a rotary encoder or a cap-touch interface for some adjustment or swap out different probes for whatever they're testing and the master could automatically identify what's attached and what options should be enabled/disabled. I'm fairly sure I could figure out how to do it, but I'd like to do it well in the hopes that it's more maintainable and more readily standardized (and I know my current coding and circuit design practices are by no means best practices).
|
|
#
?
Dec 11, 2014 01:16
|
|
|
Mr. Powers posted:If you have a low data rate, you could use I2C worth multiple masters if needed. For higher data rates you could use a multidrop UART, but that really needs a single master to avoid collisions. Do you have actual experience with multi-master I2C? I swear everyone claims their poo poo will play nice in a multi-master environment, but nobody ever loving validates that. Looking at you Xilinx.
|
|
#
?
Dec 11, 2014 02:54
|
|
|
movax posted:Do you have actual experience with multi-master I2C? I swear everyone claims their poo poo will play nice in a multi-master environment, but nobody ever loving validates that. Looking at you Xilinx. At the time I suggested it, I was under the impression that each module would be developed by poeticoddity and would be a microcontroller network under their control. I wouldn't suggest it if you're mixing and matching micro vendors or adding third party I2C devices to the bus. I basically thought it was the frictionless spherical chickens in a vacuum scenario where everything is controlled and it becomes easy.
|
|
#
?
Dec 11, 2014 05:32
|
|
|
Alright, further clarification: I build vision testing equipment (at the moment for lab use, but eventually I'm hoping to get into clinical equipment). I build the equipment myself (so it's not getting interfaced into existing prototypes or off-the-shelf hardware) so I have as full control over specifications as possible. Each device has something that's very specialized to that particular device (usually at least the actual generation of the visual target) but also has a lot of generalizable components attached to it (LCDs, knobs, buttons, etc.). I would like to start moving the generalizable components to their own microcontrollers instead of running everything from one overtaxed microcontroller. If it makes any difference, I'm using Arduinos at the moment, but I'm quickly outgrowing them and the code is more and more just straight AVR-C, so I'll likely be transitioning away from the Arduino platform in the next few years. My hope is that eventually people could say "I want specialized device 1 and specialized device 2, but only want this one control panel, so I'll move it back and forth between these devices as I use them" and also be able to say, "I like using general device A in this circumstance and general device B in this circumstance, and I'd like to be able to hook up one, the other, or both to this specialized piece of equipment at my discretion without having to reconfigure a lot of stuff manually". Assume I have complete control over the code base and the hardware design. I'm looking for best practices, design guidelines, common standards, etc. for having systems with a single master uC and one or more slave uCs (and probably some slave ICs that aren't uCs) be as modular as possible. Hot-swappable is ideal, but not necessary. I understand in abstract how to do this, but I would prefer to start with best practices rather than try to fix them later.
|
|
#
?
Dec 11, 2014 20:48
|
|
|
poeticoddity posted:Alright, further clarification: I'd say you're going to have to pay even more than the usual amount of attention to the total capacitance of your bus. Especially if you're doing something hot-swappable, you'll have to choose your connectors carefully and watch your trace lengths. I2C, for example, specifies a maximum bus capacitance of 400pF I believe. With good impedance matching in your connectors and proper termination, you might be able to push this a bit, but I wouldn't if you're looking to produce anything high reliability. If price is less of a concern (which I imagine is probably the case for specialized gear like this), liberal use of bidirectional buffers can mostly solve this issue (something like this: http://www.ti.com/lit/ds/symlink/p82b96.pdf). Obviously you can always trade bandwidth for robustness here; operate your bus at a lower clock rate and you can get away with higher capacitance and worse impedance matching. Also, there's the basic stuff like making sure there's no bus address conflicts among the parts you choose. EDIT: This is assuming your whole setup is all relatively tightly packed together. If you're talking about separation between your devices on the order of feet, you'll be looking into totally different kinds of connectivity. Pan Et Circenses fucked around with this message at 21:39 on Dec 11, 2014 |
|
#
?
Dec 11, 2014 21:00
|
|
|
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
|
|
|
Hadlock posted:Out of curiosity, those of you doing this for a living, what kinds of things are you writing code for? The company has a few different areas of focus as regards what the FPGAs are used for: cryptography, bioinformatics, image processing, modeling and simulation, security, machine learning, etc. Lately, I write less code than I'd ideally like to, but I wear a lot of different hats depending on what needs attention.
|
|
#
?
Dec 12, 2014 01:52
|
|
|
Pan Et Circenses posted:I'd say you're going to have to pay even more than the usual amount of attention to the total capacitance of your bus. Especially if you're doing something hot-swappable, you'll have to choose your connectors carefully and watch your trace lengths. I2C, for example, specifies a maximum bus capacitance of 400pF I believe. With good impedance matching in your connectors and proper termination, you might be able to push this a bit, but I wouldn't if you're looking to produce anything high reliability. That bidirectional buffer looks fantastic and the price isn't nearly as bad as I'd thought. I may be building equipment this spring semester with LEDs that are over a $100 a piece, so dropping <$4 on a buffer that lets me move something across the room is of no problem. Currently, as terrible as this probably is, when I've needed to send signals out on modular equipment, I've used USB cables or ethernet cables (almost entirely because they're easy to source if someone runs one over with an office chair or if one gets bent and breaks), but if you have any better suggestions for something that's not terribly expensive or hard to source, I'm interested. I don't have to send a lot of data (usually under 10 bytes at a time and generally at least double-digit milliseconds between transmissions) but it does need to move quickly. On some things, the time sensitive stuff could be moved around if I have a good way to sync a time reference between uCs. Some stuff can be restricted to a few feet, but with other peripherals I need at least two yards of cable. I know higher voltages can help with this issue, but I'd prefer to avoid having to run past the current 5V systems I'm using. evensevenone posted: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. I actually do have hard realtime requirements that are very time sensitive in some functions. I know I'm eventually going to have to branch into a PC base or an ARM base eventually because I'm rolling a design around in my head that'll require computer vision to work properly, but a lot of the precision LED driving and reaction timing stuff isn't really well suited to anything but uCs at the moment. I may be getting a Raspi and camera for xmas (and if not I'll be ordering a kit afterward) to try branching out a bit.
|
|
#
?
Dec 13, 2014 00:30
|
|
|
|
| # ? May 11, 2024 12:06 |
|
|
poeticoddity posted:That bidirectional buffer looks fantastic and the price isn't nearly as bad as I'd thought. I may be building equipment this spring semester with LEDs that are over a $100 a piece, so dropping <$4 on a buffer that lets me move something across the room is of no problem. I've seen people with spaghetti wire going everywhere on their projects, and I always always suggest ethernet. It's ubiquitous, cheap, easy to terminate, the connectors lock into the sockets, and if you need to send fast signals long distance, that is literally what cat 6 is designed to do.
|
|
#
?
Dec 13, 2014 02:02
|
|