Bernard Cole

image
Site Editor/Newsletter Editor

Bernard Cole is the site editor for Embedded.com and a technical writer for TechRite Associates.

Bernard Cole

's contributions
Articles
Comments
    • The many spurious noise, ESD and EMI "ghosts" that can wreak havoc in an embedded design are still with us and getting worse as we push the limits of design and application. How will we deal with the challenges ahead in a ubiquitously connected world?

    • Embedded industry product and technology news stories for this week from ESC/ EELive! and Freescale Technology Forum as well as Cavium, Connect Blue, GrammaTech, Intersil, Microchip, Micrium, Qualcomm, and Texas Instruments

    • To speed web service deployment on its Internet of Things devices, Freescale showed off at its Technology Forum this week an IoT Gateway One Box Platform to support the secure delivery of IoT services

    • The Linux operating system is now a mainstream embedded OS. But for how long? Will the demands for extreme security and small memory footprint on the Internet of Things displace its monolithic kernel with more flexible lightweight alternatives?

    • I agree with you Nanonical!!! Even with the hardware description languages such as Verilog, VHDL, and SystemC - each of which are based on different software languages (C, Ada and C++) - place much more emphasis on the "engineering" aspects such as verification, validation, simulation, optimization, metrics than their software antecedents. And now with the emergence of common hw/sw development platforms from companies such as Mentor Graphics and Synopsys, software developers and programmers will be able to do a lot more performance analysis, what-ifs and fine grained inspection of where the bottlenecks are. But there will be a price for that. And that is where software developers and hardware engineers will have to decide which way to go. And it is likely that software developers will have to bend and accept more rigorous methodologies, not the other way around.

    • I agree. The IoT designation reminds me of the 'high concept" descriptor's that Hollywood screen writers had to come up with to sell a script to a Hollywood studio executive - catchy enough to grab the most un-initiated and least knowledgeable and make them invest in a new film - but so devoid of meaning as to be useful in understanding what is actually in the script. The script is about increasing ubiquity of connected wired and wireless embedded devices, something that has been going on for at least a decade since IPv6 and 6LoWPAN was introduced. The only common assumption in all segments where IoT is discussed the common underlying assumption is that all devices will be IP (as in IPv6) connected. First all devices will not need full TCP/Ip capabilities and in some cases will get in the way of their tasks. Second, it assumes that IPv6 will be enabled everywhere. It has been more than ten years since IPv6 was released and used by embedded developers and other than major network companies or web firms, such as google it is not widely adopted even yet. Most local Internet Service provides in the US at least have not moved from IPv4 because of costs and so a say - home or consume IoT device that uses the ubiquity of IPv6 and other enhancements not available in IPv4 ISP connetions will not work.

    • I enjoy the commentary that results after I put together a package on topics like modeling tools almost as much as I do the initial work. This time especially I have found all of your comments useful in giving me more ideas about what to do on the site not only about C specifically, but other approaches to modeling as well. Thanks for your contributions here.

    • Re Rust's ability to interact directly with C/++ code, Adacore just recently (http://www.embedded.com/electronics-news/4427979/Adacore-updates-its-ADA-static-and-dynamic-code-analysis-tools) said with reference to its update of its code analysis tools: "...Version 1.2 can not only be used for the for the upcoming SPARK 2014 revision but includes Beta support for C code development."

    • re ciscy. point noted.i should have said a "much more ciscy insrtuction set" and will make the change. not all that impressed about 16 bit either. but they were included because in my regular searches for design articles on google scholar, ieee digital and acm digital library there are just as many 16-bit mcus as 8 bit mcus used in variety of m2m, zigbee, sensor, 6lowpan (ie iot in today's terminology) as 32 bit. 16 bit may not be your cup of tea (nor mine either) but a lot of people out there are using them instead of 32 bitters.

    • on the wired side, industrial control uses a modification of TCP/IP in their Embedded Ethernet protocols to regain real time determinism. Same is true of building control networks such as bacnet and lonworks which use a subset of the full TCP/IP (udp) to get the determinism they need. Same is true of some of the wireless protocols used in industrial control currently such as WirelessHART based on the Highway Addressable Remote Transducer Protocol (HART) and defined to mesh with the requirements of wired process field device networks.

    • right. i wrote about inferno and solicited and received several articles from the developers in the late 90s at EETimes defunct In Focus sections and wrote about them in a book on netcentric computing in earlu 2000s. Interestingly most of the inferno guys are over at Google and you can see their footprints all over the place.

    • Re Luis Sanchez, from my regular cruising of various forums both company and noncompany related I am constantly seeing pleas of help about driver problems - finding one, making it work, etc. Most recent one I saw was on Embedded.com's forum titled: "Developing Embbeded Driver board for ATIK314L+"

    • SPLatman - Thanks for sending me the comment. It is something i can now use as ammunition to get them to fix or rethink. It irritates me as well and I am supposed to be managing the site.