|
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
|
|
|
|
| # ? May 10, 2024 01:47 |
|
|
Every RTOS I've used came with a configuration tool that enabled/disabled huge chunks of it and only compiled the bare necessities. So yes, they'll have the option to manage a filesystem or virtual memory, but unless you ask for it they're not costing you anything by existing.
|
|
#
?
Sep 6, 2013 19:01
|
|
|
Uh, all that hardware doesn't make an RTOS unnecessary, and a MMU is not required when you only have one process (and have need for a few global variables). The project I'm working on right now has several threads, which vastly simplifies scheduling. And I don't know why you'd say a superloop is unnecessary. Unless you're doing something extremely boring, it's generally the simplest and most modifiable format. Sure, you could go balls-to-the-wall retarded with only state machines, but you'd probably only do that if you were an obsolete greybeard that is making an industrial controller that does something intimately uninteresting.
|
|
#
?
Sep 6, 2013 19:08
|
|
|
Martytoof posted:Question: I'm kind of fuzzy on the PIC infrastructure. How much do the optimization limitations of their free compiler actually affect you guys? I am imagining scenarios where you really only start to see it if you have some crazy large firmware you've designed and for like 99% of users out there their free implementation is probably fine? It kind of depends on what you're doing. The free version of XC8 will bloat the code needlessly, for example, you'd expect this C code: code:code:code:Also, C just isn't really a good fit for the 8-bit architecture. So you'll probably eventually run into problems with pointers not doing what you think they should, strange problems that you'll have to look into the asm to solve, etc. XC16 for PIC24/dsPIC is a lot more decent, and I've had less problems with it. The space constraint on a 16 bit part is a lot less important, too. isr fucked around with this message at 20:08 on Sep 6, 2013 |
|
#
?
Sep 6, 2013 20:01
|
|
|
Slanderer posted:Uh, all that hardware doesn't make an RTOS unnecessary, and a MMU is not required when you only have one process (and have need for a few global variables). The project I'm working on right now has several threads, which vastly simplifies scheduling. dsPICs specifically were designed for things like switched mode power supplies, and motor control. Speed was maximized at the expense of other things, like power consumption. You can certainly run an RTOS on a dsPIC, but in most cases you can't afford to lose the processing overhead to an RTOS unless you absolutely need to, the preference would be to get the processing tasks done as quickly as possible and goto sleep.
|
|
#
?
Sep 6, 2013 20:15
|
|
|
isr posted:It kind of depends on what you're doing. The free version of XC8 will bloat the code needlessly, for example, you'd expect this C code: Hmm. Thanks for this. All my experience right now is using AVRs where I can be fairly confident that GCC won't gently caress me needlessly for code size, but I have no way of judging how efficient it is. I /THINK/ Atmel Studio just relies on GCC so it's probably fine, but I dunno. I was hoping to just dick around with PICs for a day or so, so I may try it regardless. Can't hurt to have your hands in more than one architecture. At the end of the day it's just flipping different registers so it can't be all that different 
|
|
#
?
Sep 6, 2013 20:51
|
|
|
You can use the pro version for a limited evaluation period, and switch between pro/free in the project settings to compare. Knowing where to look for the gotcha's is most of the work, getting around them isn't quite as bad.
|
|
#
?
Sep 6, 2013 21:00
|
|
|
Martytoof posted:Question: I'm kind of fuzzy on the PIC infrastructure. How much do the optimization limitations of their free compiler actually affect you guys? I am imagining scenarios where you really only start to see it if you have some crazy large firmware you've designed and for like 99% of users out there their free implementation is probably fine? When I'm writing PIC firmware I'm usually doing something relatively simple on a larger dsPIC or similar, lots of 10-15 instruction basic blocks that usually move a piece of data and do a small amount of arithmetic. These blocks usually reside in interrupts, although sometimes I set flags/wake up in the interrupts and do data processing in a superloop. Either way, I don't think there is a whole lot of room for optimizations and I don't think I've ever gotten close to the rom size limits on these parts. Sometimes I will write code in a very verbose way and there are probably some trivial optimizations there, but for the most part it seems okay without. I've also done timing by counting instructions (  ) and I hate to think what optimizing compilers would do to that technique.
|
|
#
?
Sep 6, 2013 21:18
|
|
|
Martytoof posted:I /THINK/ Atmel Studio just relies on GCC so it's probably fine, but I dunno. Yup, Atmel Studio's toolchains are all GCC based, and aren't restricted in any way. I'm still astonished people voluntarily choose 8-bit PICs with an intentionally borked toolchain, when AVRs have an open one that's free. Not only is the code slower but it's larger too so you end up paying more for a device with sufficient flash to store the code. In the 32-bit space things are a bit different, and even I don't think Atmel has the best offerings (although they're decent). However, the SAM3/SAM4 devices have a crapload of features and can be used in Atmel Studio (low learning curve). The new SAM D20 is Cortex M0+ - meaning dirt cheap since they're supposed to complete against the 8-bit and 16-bit space - but isn't so newbie friendly given the core design which hardfaults on unaligned access or other issues.
|
|
#
?
Sep 6, 2013 21:41
|
|
|
I'd love to hear more about alternatives to superloops...I mean, you need a while(1) somewhere, right? I mean, my code generally looks like:code:
|
|
#
?
Sep 6, 2013 22:29
|
|
|
I've always been a superloop person - really the options are: a) Pure interrupts (main loop just sleeps) b) Superloop and interrupts c) Superloop, all hardware polled I've used variants of all three. Until recently I discounted RTOSes since I was working exclusively with 8-bit AVRs - but now I'm working with the SAM D20 we've started deploying FreeRTOS and I...don't mind it. It's kind of refreshing to be able to make a driver that does one thing only in isolation with all the appropriate timings and synchronization, then just bang it into your app and have it work. Apart from the easier development I've found it also helps with cross-team development (no need to worry about a coworker upsetting your module's timings, modules can be developed in parallel) and lowers overall power consumption since the RTOS can manage the sleeping and wake ups for you based on the current thread state(s). Also, FreeRTOS with Perceptio tracing (http://percepio.com/docs/manual/) is goddam magical.
|
|
#
?
Sep 6, 2013 22:36
|
|
|
One super-loop alternative that's not an RTOS is statemachines. There's an interesting book called "Practical UML statecharts in c/c++" by Miro Samek. Most of the book's examples use his statechart software, licensed at a reasonable fee of course. All of the concepts are described and explained very well, so you could also write your own if you wanted to. The basic idea is that of active objects. Active objects pass messages back and forth to each other, a scheduler selects which object gets to read it's messages and when. When an AO is dispatched it pop's its message from it's queue, sends messages to other objects, and runs to completion. So if you use his framework, you get a nice UML statechart entry software interface in which you tie to your libraries, and off it goes. isr fucked around with this message at 22:46 on Sep 6, 2013 |
|
#
?
Sep 6, 2013 22:42
|
|
|
isr posted:The basic idea is that of active objects. Active objects pass messages back and forth to each other, a scheduler selects which object gets to read it's messages and when. When an AO is dispatched it pop's its message from it's queue, sends messages to other objects, and runs to completion. This sounds like a DIY version of the infrastructure that an RTOS provides for you, with (ideally) shared-nothing tasks that communicate with each other by sending messages via queues, and an efficient preemptive priority scheduler. I've read and modified/extended state machine based firmware, but never written anything substantial that way from a blank slate. While I'm not a fan of UML per se I will admit that state machine diagrams are somewhat useful in communicating with the marketing guys who have taken to calling it a "spaghetti and meatballs diagram" (in the RTOS based firmware I'm currently working on, I implemented the menu system as a state machine. In retrospect I wouldn't do it that way again for reasons I won't go into here, but when the menu tree was small it was great). I do the diagrams up in Visio, but I can see how something that auto-generated the diagram from the code and left room for annotations would be useful.
|
|
#
?
Sep 7, 2013 01:51
|
|
|
EpicCodeMonkey posted:Also, FreeRTOS with Perceptio tracing (http://percepio.com/docs/manual/) is goddam magical. Hot dang this looks nifty.
|
|
#
?
Sep 7, 2013 01:52
|
|
|
Otto Skorzeny posted:This sounds like a DIY version of the infrastructure that an RTOS provides for you, with (ideally) shared-nothing tasks that communicate with each other by sending messages via queues, and an efficient preemptive priority scheduler. Is it FreeRTOS that switches tasks with 2 instructions? Pop off the stack, jump to it? I've worked with it, eCos, and a commercial solution and they're starting to blur together. Otto Skorzeny posted:Hot dang this looks nifty.
|
|
#
?
Sep 7, 2013 01:58
|
|
|
code:Someone write a peephole optimizer, quick!
|
|
#
?
Sep 7, 2013 02:37
|
|
|
Not until writing embedded code had I ever written something purely procedural long enough to make me truly experience the reasons for further developments in computer science. 
|
|
#
?
Sep 7, 2013 02:58
|
|
|
Otto Skorzeny posted:This sounds like a DIY version of the infrastructure that an RTOS provides for you, with (ideally) shared-nothing tasks that communicate with each other by sending messages via queues, and an efficient preemptive priority scheduler. Yeah, at the end of the day you're locked into a very specific way of writing code, it doesn't do anything you can't do with an RTOS, but hey you get to generate it all from UML diagrams!!!  State machines are great for designing and implementing protocols and drivers and things, and usually the hardware does a good job of keeping state on its own. I think most of you all work with much more advanced processors/systems than I do... I can get what I need done with interrupts, polling, and peripherals that trigger each other. isr fucked around with this message at 03:55 on Sep 7, 2013 |
|
#
?
Sep 7, 2013 03:20
|
|
|
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
|
|
|
evensevenone posted: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. RTOS literally exist to provide real-time guarantees. It's half of the name. They offer easy hooks for writing ISR's and enforcing guarantees between them. I really don't know which ones you've worked with, but if you think they somehow enforce dynamic memory or a stack frame I'm not sure what to say. Most of them compile down to a static system you can inspect without much trouble if you've got that much skepticism about it.
|
|
#
?
Sep 7, 2013 07:09
|
|
|
JawnV6 posted:RTOS literally exist to provide real-time guarantees. It's half of the name. They offer easy hooks for writing ISR's and enforcing guarantees between them. I really don't know which ones you've worked with, but if you think they somehow enforce dynamic memory or a stack frame I'm not sure what to say. Most of them compile down to a static system you can inspect without much trouble if you've got that much skepticism about it. Stupid question: if you need hard realtime guarantees why go with an rtos on a uc over an fpga where you implement your algorithm in logic? Cost, complexity, validation? I think there are some fpga with hard procs embedded too for convenience.
|
|
#
?
Sep 7, 2013 08:59
|
|
|
JawnV6 posted:Imagine what the paid tools in this space do That's a paid tool, but the free version works pretty well too (you lose custom events, but the core tracing and stuff works still). Like I said, it's magical to get graphs of how full queues are/were, which threads ran when and why, the whole nine yards.
|
|
#
?
Sep 7, 2013 09:00
|
|
|
Malcolm XML posted:Stupid question: if you need hard realtime guarantees why go with an rtos on a uc over an fpga where you implement your algorithm in logic? Cost, complexity, validation? I think there are some fpga with hard procs embedded too for convenience. Yeah, cost/complexity/validation. An RTOS can take a collection of C functions and run on a $0.50 part. The sheer count of folks who can write C over HDL makes that cheaper even ignoring the HW side. Embedded libraries are also more plentiful. Try sourcing an software QR code reader, then find one in hardware. I've always thought the fpga's with hard procs were for SoC development. I've never used one though, just pure fpgas. As a side note, any firmware programmers in the Bay looking for work (lol as if) I know a few companies looking (consumer electronics, electric vehicles, etc.) feel free to shoot me a resume.
|
|
#
?
Sep 7, 2013 15:38
|
|
|
isr posted:One super-loop alternative that's not an RTOS is statemachines. There's an interesting book called "Practical UML statecharts in c/c++" by Miro Samek. Most of the book's examples use his statechart software, licensed at a reasonable fee of course. All of the concepts are described and explained very well, so you could also write your own if you wanted to. I read that book recently. It's a really neat application of state machines; the hierarchical nature gives a ton of flexibility and power. It's nice not having to handle every event in every state; when unrecognized events occur, they can bubble up the hierarchy until they get handled. That said, it was used for a C++ app that ran on a relatively powerful computer (64K was not a lot) so the overhead worry was negligible.
|
|
#
?
Sep 9, 2013 17:06
|
|
|
Delta-Wye posted:I read that book recently. It's a really neat application of state machines; the hierarchical nature gives a ton of flexibility and power. It's nice not having to handle every event in every state; when unrecognized events occur, they can bubble up the hierarchy until they get handled. That said, it was used for a C++ app that ran on a relatively powerful computer (64K was not a lot) so the overhead worry was negligible. I'm going to borrow that from one of the guy's here at work, our senior software guys curse at superloops and I want to learn more about the alternatives. Seems like it's got some real good advantages for safety-critical / other fault-sensitive/tolerant applications, though I can't say I saw too much of that in the auto industry.
|
|
#
?
Sep 9, 2013 18:07
|
|
|
If you wanted a free TI Coupon code: National-1yr Valid until 30-September. If you order 2 your total comes to like $1, shipped depending on where you live. I knew I read hack-a-day for a reason. edit: Their site is super hosed right now though. As if their entire order system was running off one Stellaris board. edit2: I just ordered a Tiva and a MSP430 Launchpad. Always wanted to try that platform 
some kinda jackal fucked around with this message at 20:59 on Sep 18, 2013 |
|
#
?
Sep 18, 2013 20:29
|
|
|
EpicCodeMonkey posted:Also, FreeRTOS with Perceptio tracing (http://percepio.com/docs/manual/) is goddam magical. It's awesome to see this get some mention on the forums, I went to school with a guy who works on it at Percepio. It is pretty damned magical.
|
|
#
?
Sep 18, 2013 22:48
|
|
|
EpicCodeMonkey posted:Also, FreeRTOS with Perceptio tracing (http://percepio.com/docs/manual/) is goddam magical. this does look pretty interesting. i have yet to venture into RTOS land but it's on the list. what kind of system size are we talking about where it starts to make sense?
|
|
#
?
Sep 20, 2013 15:01
|
|
|
Pretty Cool Name posted:It's awesome to see this get some mention on the forums, I went to school with a guy who works on it at Percepio. It is pretty damned magical. It's cool - but now tell him to make it work with the latest FreeRTOS and tickless; I just get a generic error when I try to open the trace dump. Older FreeRTOS and Trace library/software works so I've reverted to that. double riveting posted:this does look pretty interesting. i have yet to venture into RTOS land but it's on the list. what kind of system size are we talking about where it starts to make sense? I'm using it on the Atmel SAM D20 (Cortex M0+) devices, which are 32-bit, 48MHz. Really while it's usable on small 8-bit devices I still prefer super-loops for those just due to the limited clock speeds, RAM and slow context switching times, so I'd say 32-bit would be the minimum where it really makes sense. With the tiny devices generally you can keep the entire system design in your head anyway, so the RTOS doesn't give much benefit.
|
|
#
?
Sep 22, 2013 15:48
|
|
|
More of a hardware question, but has anyone had problems running a uC programmer off a laptop? My AVRmkII programmer works like a champ when plugged into my desktop, but when I try to run it off my laptop the programmer LEDs blink and I don't get any errors in the IDE but the new code only seems to transfer over to the chip about 20% of the time. The other 80% of the time the chip just resets and runs whatever old code was present like nothing happened. I'd assume that the physical interface must be optoisolated, so the power supply of the laptop floating slightly relative to the dev board shouldn't be an issue, right? Maybe the laptop USB port can't supply enough power to run the programmer?
|
|
#
?
Sep 22, 2013 23:18
|
|
|
PDP-1 posted:I'd assume that the physical interface must be optoisolated, so the power supply of the laptop floating slightly relative to the dev board shouldn't be an issue, right? Maybe the laptop USB port can't supply enough power to run the programmer? This is what I would guess. Flashing can be a bit of a current hog. I wouldn't have guessed it would have been enough to reset everything, but who knows. So, all of this talk about superloops and RTOS's has gotten me thinking about a design pattern I used to use that always made me uneasy. When doing power sensitive applications on the MSP430 platform, making interrupts fast and efficient so the cpu can go back to sleep is important. Removing an instruction here or there can add weeks of runtime, if not months. I would usually set it up so that the processor is dormant almost all of the time waiting for an interrupt to wake it up. If the interrupt required more than a tiny bit of processing, I would often have it set a flag and the main loop would process it before going back to sleep. In rough psuedocode: code:I never had a situation where this issue really mattered, but I feel like there is probably a better solution out there for achieving the behavior I want without this issue. I found it nice to be able to separate the processing from the interrupts. It makes interrupt priority easier, I think, and makes managing relatively long computations all interleaved by random interrupts a lot easier. Any ideas on a way of working around the race condition? I may just need to abandon this approach for things where missing an interrupt would be a problem.
|
|
#
?
Sep 22, 2013 23:42
|
|
|
Delta-Wye posted:This is what I would guess. Flashing can be a bit of a current hog. I wouldn't have guessed it would have been enough to reset everything, but who knows. I checked the specs on the programmer and it can draw up to 200mA, so that might well be the issue. The next step would be to try to dig up a powered USB hub and route things through that to see if it works. One thing I don't get however is that it seems like not having enough power to flash properly should return some kind of error - either the programmer would get corrupted data parroted back on the MISO line or the chip's memory would be corrupted. Neither of these things happen though, the IDE doesn't report any programming errors and when the chip doesn't update its code the old code continues to run just fine. 
|
|
#
?
Sep 23, 2013 01:44
|
|
|
Delta-Wye posted:
You should investigate the MSP430 docs more. For example, on the AVR, the instruction following a sei (global interrupt enable) is guaranteed to execute before any interrupts can fire. Thus it's possible to disable interrupts, check the flag, and then if you want to sleep, setup the sleep, re-enable interrupts and immediately sleep. It's guaranteed that no ISR will occur in between. I can only imagine that MSP430 has some similar capability. Alternatively, a 'main loop' is just wasted cycles really, all that setting & testing flags & branching & function calls. Unless you must handle re-entrant interrupts while still 'processing' data from a previous one, you should just do everything in the ISR. If you need only handle higher-priority different interrupts during your ISR, just re-enable interrupts once you're past the critical section, and then do your processing while letting other interrupts run. Unless the SAME interrupt can fire again, it's fine.
|
|
#
?
Sep 23, 2013 03:55
|
|
|
Martytoof posted:If you wanted a free TI "You are no longer allowed to use this coupon."
|
|
#
?
Sep 24, 2013 01:57
|
|
|
Well I wondered how many free $25 devkits they would ship out before axing this
|
|
#
?
Sep 24, 2013 02:31
|
|
|
According to fedex I have two waiting for me at home
|
|
#
?
Sep 24, 2013 23:17
|
|
|
According to TI's site, my poo poo is still "Processing" 
|
|
#
?
Sep 24, 2013 23:19
|
|
|
They seem pretty cool. I wish they just set you up with a gnu tool chain instead of forcing their crapware (and registration) on us.
|
|
#
?
Sep 26, 2013 05:01
|
|
|
Not sure where else this would go. I'm dicking around with one of these things: http://www.carymart.com/mobile-phone-smartphone-wifi-controller-for-android-or-ios-%E2%80%93-8-channel-relay-output-p-1579.html I've a bunch of it figured out in terms of how to trigger events/controls, various modes, etc. What I'm wondering is if it's possible to hack the network side to work with outside connections instead of those restricted to devices currently connected to it. Right now the way the thing works is a wireless device (e.g. my tablet) gets within range, connects on a reserved subnet (10.10.x.y) and then can mess around with the little built in web server (called "m2m web server" which I can't find dick all about). What I'd like to be able to do is access it from WAN instead of WLAN but there's no settings in the M2M server app (it's basically like a router page, set IP, SSID, GHz range, etc.) and my programming ref is all about sending electricity to the relay ports to handle hardware. Any of you guys have any exposure to hardware like this or the 'm2m web server'? EDIT-Maybe a different network stack or something? I can pop the case and find the specific wifi chip if that'll help This is the manufactuer: http://www.tcp232.net/serial-ttl-rs232-to-802.11-bgn-converter-Embedded-WiFi-Module.html Double Edit- Made some progress on this. These guys: http://propellerpowered.com/forum/index.php?topic=230.0 Have managed it with a propeller board, but they're connecting via serial to issue AT commands to get the TCPB listener going. There's no external serial port on this device so I'm going to crack it open and see if there's one inside. LAST EDIT-Aaand figured it out. Now to automate w/ setup script. Scaramouche fucked around with this message at 20:42 on Oct 2, 2013 |
|
#
?
Sep 30, 2013 19:47
|
|
|
|
| # ? May 10, 2024 01:47 |
|
|
Has anyone worked with the MPR121 capacitive touch sensor chip? I'm building something based on it. I have the arduino library for it and converted those calls to a real platform. It's working great just with aluminum tape. Now I'm having to tune the sensitivity to put a dielectric between it and the actual touch point on the device. I'm going to dive into the datasheet shortly, but any pointers on working with this or other capacitive sensors would be much appreciated.
|
|
#
?
Oct 3, 2013 17:51
|
|