People should always consider the old, but true saying - "you get what you pay for". For small jobs where your budget is very small these "free" software bundles make sense. As products / projects get more expensive, support becomes increasingly more important to control schedule. Great- you got the software, and found a bug - now YOU need to spend money (time) to find out what's wrong rather than the vendor. When the vendor does it - you're schedule isn't hit so hard.
Personally i am for the out house operating system. That way the application code does not meddle with the os code for some simple workarounds , else it allbecomes the spaghetti , fixes and workarounds in the os code to takecare of some application idiosynchrosies
openwrt is just a cut-down version of linux, it has no overlap with freertos, the latter one is for resourced limited chips such as MCUs, where linux does not fit at all. i'm curious on contiki os which is even smaller than FreeRTOS but better fit for extremely resource limited device such as IoT sensors, while contiki is tiny, it may win in quantity
While there may be an additional tool in the flow (in this case, HLS - high level synthesis, i.e., C to gates), being enabled to work at the C (C/C++, SystemC) level at a higher abstraction will speed up your design process and allow you to address larger scale problems. And you shouldn't just limit yourself to hardware, as some functions (if you decompose your application into multiple tasks) may be better off as software where you have FPGA's with embedded processors (Xilinx Zynq, Altera SoC FPGA). Just find the most optimal hardware and software partitioning to do your job.
Please take advantage of our Resources page at Space Codesign, with links to information on the subject (ESL, SystemC, HLS, HW/SW co-design) including some case studies that we have presented at recent conferences. (usual disclaimers)
Technically speaking, WiFi and BLE are not a competing technology. They serve different purposes. WiFi serves high bandwidth demand application such as video stream, online gaming. BLE serves accessory connectivity market such as earpieces, speakers. The bandwidth difference are hundred Mbps vs 1Mbps. Although they can be put into the same chart to understand how well they penetrate the market individually, they shouldn't be compared.
Having said that, I believe the growth of BLE will be a lot more substantial in the coming years. In average, every household of 4 people needs 1 WiFi router and 4 smartphones, 4 tablets and 4 laptops. All these 4 people may have 1 fitbits each, 1 or 2 earpieces, 1 or 2 portable speakers. In addition, the household may have 1 or 2 remote controllers, console game remote controllers, smart smoke detector, smart thermostat. As IoT grows, the demand of BLE solution is going to grow.
One of the biggest hurdles of building an embedded system is device driver. I wonder how well FreeRTOS supports various devices. Well! Unless it is one of the linux variety
I wonder how popular OpenWRT is. There are variety of device drivers support to the platform. In addition, you can pretty much change your home WiFi router into an OpenWRT enabled WiFi router with a couple simple steps. Information is widely available online. It's one of the linux varieties. So, any linux guru can get around the device and start doing some personal touch to the router. In addition, GNU gcc is well supported and any popular opensources applications, you name it; you can build it by simply choosing an option under 'make menuconfig'.
I haven't ever tried them myself. "C-to-gates" looks like it could do a good job with certain kinds of FPGA applications, specifically implementing high-performance DSP algorithms.
From the little I've seen, it seems to me that they usually convert to C to Verilog or VHDL, and then use the vendor's tool chain. If this is true, "C-to-gates" doesn't help me since it adds an additional tool to design loop, and makes it even harder for me to see how my source code maps into actual logic.
When I design an FPGA, I have my hardware designer hat on and I have a very clear idea what hardware I want to end up with. Then I have to figure out which Verilog templates to use so that the synthesizer generates the hardware I've already visualized. I'm perfectly happy to have the synthesizer do logic minimization for me, since that's tedious and error-prone to do manually. But I want to have control over when I use LUTs as RAMs or shift registers, and it's annoying to keep checking the synthesis report to determine that it did what I wanted.
betajet: what about c-to-gates tools ? what's your opinion on them? and are they catching up with pro's and non fpga pros ?
And maybe the reason it takes more time to synthesize - is that the chips and designs are more complex , so synthesis time should grow exponetialy with this complexity , but smarter synthesis algorithms reduce it to 2x ?
Yes, I hear you, there has been lots of horror stories in the embedded software world along with clever workarounds.
" An in-house OS only has to support the features needed for the product. An in-house OS may be as simple as a single main thread plus interrupt service routines, with no preëmptive multi-tasking and little or no memory management."
I think this is a bit myopic. Rarely are all features known up front for the life of the product. Customer requirements change. That is why you want something that can grow with you as your product evolves and eliminates lots of expensive development and maintenance. Often developers think they can do this but almost all post mortems will show that thi is was not the best overall choice.
The other thing is that with the right software and the right APIs, you make your application portable to a variety of OS platforms. Now you can develop a better richer application which offers customers more and is easily maintainable. These are hidden benefits - after all the project manager for the first build rarely is the manager for the later versions and he or she is not evaluated on the lack of maintenance costs or the foresight for portability.
rick merritt wrote: Your comment on the FPGA tools is interesting...can you document or is it a subjective impression?
Mostly subjective, though I could probably document it. My recollection is that Xilinx ISE 10.1 (I think) took almost twice as long to synthesize as 5.2, but I'd have to run a test to be sure. I didn't find it that surprising, because logic synthesis is similar to an optimizing compiler, and each new technique (such as being more clever at finding common sub-expressions) adds time.
When I write Verilog, I try to anticipate what the synthesizer is going to do and write my code to make synthesis easier. So my logic tends to produce a good result even if the synthesizer isn't using the most advanced techniques. This means the longer run times of the later version don't produce improved results.
I like to synthesize a lot so that I can immediately see if a logic change I made requires an unexpectedly large number of look-up tables. If I make a bunch of changes and the LUT count jumps, I don't know which change(s) are responsible. This is another problem I have with the tools -- I don't think there's a practical way to review what the synthesizer did. With CPLDs, the tools show you the synthesized logic equations. With FPGAs, they give you a set of automatically-generated schematics which I find useless once the logic reaches a modest level of complexity.
I don't know if FPGA tools are doing a good job with incrementals techniques yet, i.e., keeping as much of the previous result as possible they don't have to repeat unnecessary work. This has the potential of huge speed-ups, particularly in place and route. However, since I still hear of hours long place-and-route of complex FPGAs I assume this speedup hasn't happened yet. I'll be glad to hear comments from others.
Replay available now: A handful of emerging network technologies are competing to be the preferred wide-area connection for the Internet of Things. All claim lower costs and power use than cellular but none have wide deployment yet. Listen in as proponents of leading contenders make their case to be the metro or national IoT network of the future. Rick Merritt, EE Times Silicon Valley Bureau Chief, moderators this discussion. Join in and ask his guests questions.