Ah - I'm not assuming anything! You are clearly not one of the lucky ones for whom the operating system will sort everthing!

The things you mention - safety, guaranteed response times - are some of the case where we need to step outside of that. Would you be able to deliver, or contribute to, a presentation on some of the "difficult" requirements when it comes to multi-processing?

I will be doing my best to assemble a track which will cover how others are doing it but your personal experience sounds very interesting and well worth listening to.

Hmm, "the OS will take control of everything"...so you'd assume in doing multithread work I'll never encounter a global HW buffer, or allocated memory, or have to write my own OS? That doesn't sound much like the "embedded" programming I'm familiar with! Of course I've spent a lot of time doing safety-critical work (mostly on the systems side lately) where the reqs are so tight we virtually have to guarantee a deterministic response time for ALL processing, so highly complex OSes become difficult to impossible to justify, and in that world under the very strictest rules we're probably at least several years from being allowed to even consider OO programming let alone multithread, but even so it'll be coming someday, but look what I'm talking about is embedded programming TOO, and even now it would be educational for me to llearn how "everyone else" is solving these issues (if in fact in the future I can just rely on an OS that will take control of everything, and not have to think these things through myself, that still bothers me at some level).

Thanks for your input, Jeff. I agree that multicore/multithreaded development is a big bugbear for a lot of people right now. Many more of us are having to come to terms with developing on multicore platforms and it isn't easy! For many, the OS will take control of everything but that isn't always the case.

I will certainly be looking out for submissions on this. At previous ESC events, Rob Oshana has contributed several session on this so he's definitely a name to look out for this time.

Perhaps I could encourage you to look at submitting somwehing yourself describing the issues you have with current tools, languages and methodologies? I think something like that could spark some very useful discussion.

On the IoT angle, there is a co-located summit on IoT engineering on the Wednesday of EELive which specifically mentions security in the brief (http://www.eeliveshow.com/sanjose/conference/). I think that could be worth checking out.

You ask what keeps me awake at night? I think it's the huge learning curve which the embedded industry is going through at the moment. We have multicore platforms, HMP everywhere, ever-increasing demands on battery life, FPGA devices etc. There is some really exciting hardware emerging and the software community has its work cut out to get the best out of it. EELive is a great part of helping with that.

OK, we've got all this emphasis on multicore hardware, how come there are so few languages that we would want to use that actually support multithreaded applications to the extent that they have available tools THAT WORK to show whether a particular application is threadsafe AND that have a "reasonable" set of choices for automatic memory management (possibly including garbage collection, why would you want to do multithread if you needed to reinvent memory management for each program you write? what's the point of writing multithread libraries for languages that "happen" to be used a lot if they stymie the correct systems approach for complex applications and DON'T offer such tools?) already BUILT INTO the language? Or the next-generation tools that help us by assisting our efforts to partition our program into threads by assessing per-processor load at runtime, and maybe automatically coding the thread separation for us? Should we be spending more effort evaluating a more "GPU-like" approach to multithreading (like CUDA)? Where are the next-generation OSes written in these new environments that we can write our next-generation programs on top of? Oh yeah, and where's our security model for IoT? I mean that's all that keeps ME up at night, what bothers you?

I agree that the whole "Internet of Things" is currently associated with a lot of FUD. There are a lot of competing architectures, standards and protocols and nothing clear seems to have emerged so far.

I will certainly have a good look at the submissions I receive and see what can be included to cover what you're looking for.

Indeed...you could consider submitting yourself along the lines of a case study into how the whole field looks from your perspective?

Chris - Congratulations on your new status as a track chair. I hope it pays well. :-) With regard to your question about what keeps engineers up at night, I'm hearing a lot about the challengs associated with connected devices. Elecia White, Founder of Logical Elegance, summarizes it here: "I've had to learn Javascript, HTML5 (and CSS), server-side programming (PHP), how TCP/IP works, and how to use Wireshark (it's not as trivial as it sounds). I like to learn new things, but I admit to wanting to strangle an Internet-enabled stuffed animal I was working on when a vendor suggested that Ajax had just the functionality that I needed, and that I should learn it. Gee,thanks." So perhaps a session on all that other stuff??

In conjunction with unveiling of EE Times’ Silicon 60 list, journalist & Silicon 60 researcher Peter Clarke hosts a conversation on startups in the electronics industry. One of Silicon Valley's great contributions to the world has been the demonstration of how the application of entrepreneurship and venture capital to electronics and semiconductor hardware can create wealth with developments in semiconductors, displays, design automation, MEMS and across the breadth of hardware developments. But in recent years concerns have been raised that traditional venture capital has turned its back on hardware-related startups in favor of software and Internet applications and services. Panelists from incubators join Peter Clarke in debate.