View Single Post
  #12  
Old 28th February 2017
Ricoh Ricoh is offline
Full member
 
Join Date: Apr 2014
Location: Lancashire
Posts: 5,756
Thanks: 592
Thanked 419 Times in 371 Posts
Likes: 786
Liked 1,910 Times in 1,138 Posts
Re: Lockups with the E-M1 Mark II?

Quote:
Originally Posted by pdk42 View Post
Having been a developer in real time embedded systems in my early career I can promise you all that the likely problem is software (firmware) bugs. Real time software (and your camera is a complex real time computer) has to deal with lots of hardware I/O, multiple threads, interrupts etc - and all done in a machine with limited memory and a lightweight OS. It's a much more demanding programming discipline than writing standard data processing apps on desktop or server computers.

It's very hard to test all the likely scenarios in the lab. Things like one thread or an interrupt handler dumping over a data structure that is being used by another thread (but only in certain hard-to-reproduce cases) is the sort of thing that happens. It mighty only happen one in 10000 times - and with a small test user base that might mean it's never really discovered. Sell the camera to tens of thousands of early users though and it'll happen once a day somewhere. Unfortunately, it becomes a statistical chance that it will happen and reproducing it on any one camera is very hard.

I'm sure Olympus were aware of the E-M1 crashes, as they will be of the mark II issues (although these seem at a much lower level) and I'd guess that they're running cameras with test users that have fancy logging added to drill down into the problems. They'll fix them - you'll just have to wait for a firmware update! It was that which fixed the issues with the E-M1 in its early days.
What's the phrase, something along the lines if you can't stand the heat get out of the kitchen.
What camera companys are attempting is difficult, but not impossible, however they shouldn't use the consumer to be part of the development team.
I've also written real time code and once had to use machine code to meet the exacting machine cycle budget and the available rom. But cameras can't be so extreme, and good structured s/w tools are available. And as you know, the system response is only as good as the requirement specification, the interface and timing specs, etc. Good or bad requirement specs can make or kill a product's development and it's widely acknowledged that the written language is not precise enough to express the needs adequately and unambiguously. How many times have I commented on a spec, saying great, but what if...
__________________
Steve

on flickr
Reply With Quote