EOS a.k.a. Epic Operating System

[Sanjin Jukic]

EOS a.k.a. Epic (Embedded) Operating System

I'm curious how Epic is working and what caused that famous bug.

What do you think to suggest RED about development of a custom embedded operating system that can be probably more efficient for the hunting bugs.

Also from the start up the third-party applications can be supported with SDK.

If iPhone has OS why EPIC shouldn't has one too.

Don't forget that any operating system or platform is much more than an ordinary firmware.

What you think?

 

[Lauri Kettunen]

what caused that famous bug.

Sanijn, guess you rather mean what is/are the symptoms of the bug.

Sometimes it's very difficult to trace the source of bugs, if the symptoms appear far from the origin of the problem. Typically the most time consuming debugging has to do with code developers' preassumptions or misreasoning as in such a case it takes time before anybody realizes to suspect things outside the code.

 

[Sanjin Jukic]

Lauri,

right,

but also when you have a controlled environment like an operating system it could be easy to locate and fix any bug, issue or problem.

 

[Wolfgang Woehl]

A custom OS is what RED's currently writing, that's for sure. They're building a platform and that scope doesn't allow for ad-hoc and device-specific code.

I don't think there's a chance in hell they'd call it EOS, though Or REDOS, for that matter.

I love hunting bugs and I bemoan the fact that we won't get a chance to take a peek. Squashing a deep bug is such a rush, I think, because it can teach you a lot about your (author of the bug) assumptions -- your model of the world.

 

[Robert Frank]

EOS a.k.a. Epic Operating System

What you think?

Sanjin. I really like your enthusiasm, but I think Canon might have a problem with RED calling it EOS.

 

[Elsie N]

A custom OS is what RED's currently writing, that's for sure. They're building a platform and that scope doesn't allow for ad-hoc and device-specific code.

I don't think there's a chance in hell they'd call it EOS, though Or REDOS, for that matter.

I love hunting bugs and I bemoan the fact that we won't get a chance to take a peek. Squashing a deep bug is such a rush, I think, because it can teach you a lot about your (author of the bug) assumptions -- your model of the world.

Know nothing about this sort of thing except that it must be like reading a mystery novel. Pity they can't use something like reverse fuzzy logic on it. That is, take the known problem outcome and go backwards until they find the incorrect assumptions that led them to the wrong conclusion. Or maybe that is what they are doing.

 

[Sanjin Jukic]

A custom OS is what RED's currently writing, that's for sure. They're building a platform and that scope doesn't allow for ad-hoc and device-specific code.

We haven't heard about it till today and only I can guess as the situation is right now that we will not hear about it in the future at all.

RED just closed a lot of future info because of the pressure and a sort of misuse of information about what RED is doing from the competition.

But anyway a serious written operating system like an EOS a.k.a. Epic Operating system or whatever it could be called is only a good thing for Epic project.

Don't forget that with any OS you make rules how the whole thing can work, get in and out, easy fix present or upcoming bug, etc,...

Any serious software engineer knows that pretty well...

 

[Steven Caesare]

Embedded systesm, of which the EPIC/Scarlet platforms are examples, is pretty involved and delicate stuff. There are a number of layers that must be coded: hardware firmware, specific ASIC code, higher-level platform code (i.e. the "OS"), and then modules that run atop of it all (i.e. camera GUI, REDCODE codec, debayer engine, audio handling, etc...).

To complicate matters, this is a design that incoroporates some dedicated hardware (the ASIC, A/D conversters, etc...) wherein code path execution may traverse may be handed off a umber of times.

To top it all off there are massive real-time I/O requirments, interace(s) for the system bus for additional modules, support of existing device interfaces (802.11b/g/n, ethernet, CF, SATA, SDI, HDMI, etc...)

There is definitely already an "OS" there... but it's mere presence doesn't make bug hunting "easy".

-sc

 

[PatrickW]

I think your impression of what the OS on future Red cameras is focused on what OSes like MAC OS X, and Windows are like.

Its unlikely that Red would develop an OS for the Red cameras that anyone could install apps on. The future Red Cameras will have limited functions based on the hardware within them, and the coded firmware. They have predifined functions to process images, accept user input, select settings etc, and an API for external modules to interact with the camera.

Red Cameras are embedded computer systems with high end optics sensors bolted on, designed for throughput preformance, you can't waste resources for silly things like an OS.

 

[Sanjin Jukic]

EPIC Operating System is Embedded Operating System (EOS)

EPIC Operating System is Embedded Operating System (EOS)

I think your impression of what the OS on future Red cameras is focused on what OSes like MAC OS X, and Windows are like.

Its unlikely that Red would develop an OS for the Red cameras that anyone could install apps on. The future Red Cameras will have limited functions based on the hardware within them, and the coded firmware. They have predifined functions to process images, accept user input, select settings etc, and an API for external modules to interact with the camera.

Red Cameras are embedded computer systems with high end optics sensors bolted on, designed for throughput preformance, you can't waste resources for silly things like an OS.

Of course that EPIC like a digital camera has "an embedded system that is a computer system designed to perform one or a few dedicated functions often with real-time computing constraints" (Link>>>).

But the main point of this discussion could be that EPIC is probably overloaded with many functions and that situation can cause a problem so often (bug) if they all run from a simple embedded system.

Epic probably should have a serious operating system that is able to handle complexity of so many functions and tasks simultaneously (in real-time).

A common configuration for very-high-volume embedded systems is the system on a chip (SoC) which contains a complete system consisting of multiple processors, multipliers, caches and interfaces on a single chip.
SoCs can be implemented as an application-specific integrated circuit (ASIC) or using a field-programmable gate array (FPGA).

EPIC needs Tools:

- An embedded system may have its own special language or design tool, or add enhancements to an existing language such as Forth or Basic.
- Another alternative is to add a real-time operating system or embedded operating system EOS, which may have DSP capabilities like DSPnano RTOS.

EPIC needs Debugging

- Embedded debugging may be performed at different levels, depending on the facilities available. From simplest to most sophisticated they can be roughly grouped into the following areas:
Interactive resident debugging, using the simple shell provided by the embedded operating system (e.g. Forth and Basic)

- External debugging using logging or serial port output to trace operation using either a monitor in flash or using a debug server like the Remedy Debugger which even works for heterogeneous multicore systems.

- An in-circuit debugger (ICD), a hardware device that connects to the microprocessor via a JTAG or Nexus interface.
This allows the operation of the microprocessor to be controlled externally, but is typically restricted to specific debugging capabilities in the processor.

- An in-circuit emulator replaces the microprocessor with a simulated equivalent, providing full control over all aspects of the microprocessor.

- A complete emulator provides a simulation of all aspects of the hardware, allowing all of it to be controlled and modified, and allowing debugging on a normal PC.

- Unless restricted to external debugging, the programmer can typically load and run software through the tools, view the code running in the processor, and start or stop its operation.
The view of the code may be as assembly code or source-code.
Because an embedded system is often composed of a wide variety of elements, the debugging strategy may vary. For instance, debugging a software- (and microprocessor-) centric embedded system
is different from debugging an embedded system where most of the processing is performed by peripherals (DSP, FPGA, co-processor).
An increasing number of embedded systems today use more than one single processor core.

- A common problem with multi-core development is the proper synchronization of software execution.
In such a case, the embedded system design may wish to check the data traffic on the busses between the processor cores,
which requires very low-level debugging, at signal/bus level, with a logic analyzer, for instance.

LINK>>>

 

[Jeff Kilgroe]

Sanjin, I really don't understand what you think you're asking for or talking about here. EPIC already has it's own custom operating system on top of the customized ASICs and embedded processors.

You're saying EPIC needs lots of things and yet none of us know just what the internal workings of EPIC are. So I'm not sure how any of this helps anyone.

I would imagine that most everything on your list is present to some degree. And even with that, this is a complicated process and even with the best development and debug tools, there is no guaranty of how fast (or slow) the development process will be.

Also hate to say it, but it reads just like you're clipping statements about common development tools from other places on the web. Have you ever done any software or firmware development for embedded or customized systems? Ever written an OS for a custom device?

 

[Sanjin Jukic]

Sanjin,... Have you ever done any software or firmware development for embedded or customized systems? Ever written an OS for a custom device?

Jeff,

not at all, I'm not a software engineer.

My intention was to open finally a sort of discussion about something that could get to understand more and maybe even help to solve Epic bug.

Then I've got an idea about (embedded) operating system that every sort of similar device has it.

Also I thought if the bug is taking longer time to be solved that it could be maybe something wrong with that existing

(embedded) operating system. Also some other RED users (supposed to be specialists...) could jump here in this discussion,

then they could try out to put more light on that issue and make for everybody more understanding what is going on actually.

Jim already mentioned here that they will stay open as much as possible...??!!

How far they are able to be open to talk about that could be easy shawn in that sort of a bug discussion.

And just because other sort of discussions here about Epic or Scarlet release dates, etc,... are more or less totally senseless, even counterproductive,...and already have got a bit boring...

Also I think that is fair to know for the future EPIC/Scarlet users what happened during development process with a bit more details explained and would help them

later to have a right approach with any further issue and also more understanding for the acquisition system they are going to buy.

That's about a way or an image how RED wanted to show us that they are different than other brands in the whole industry.

This could be only a free thinking RED user sort of analysis (that's always limited) with putting more light on that bug and nothing more than that.

 

[Jeff Kilgroe]

No worries, Sanjin. I know you're trying to help.

The point was that RED has not and will not divulge intimate technical details of the EPIC / DSMC cameras, so such discussion is wildly speculative. And a lot of people may take some of what you posted to mean that EPIC does not have certain features or abilities when viewed from a technical or developer point of view.

Lots of us want to help, but I'm confident RED knows what they are doing and have the best people working on it. Sometimes ironing out bugs takes a lot of time. Lots of bugs will pop up during the firmware development process. I'm sure several have come and gone, this particular one must be significant for Jim to talk about it.

 

[Sanjin Jukic]

Jeff,

I can understand all that and probably is not making any sense to discuss about the things that we absolutely do not now anything about.

For sure that Epic has a sort of embedded operating system and again I can understand that the information about

that is under the protection of RED Digital Cinema Company secrets that we can't talk or even discuss it.

We could only virtually talk about something similar but that doesn't make any sense now.

 

[Michael Hastings]

Not to jump on Sanjin, but I agree with Jeff - I wondered what the point of this was as soon as i saw it a few days ago, but didn't post. Since obviously Epic does have its own operating system, this doesn't seem to be helpful in any way and probably should be closed.

 

[Jason Sinclair]

Sanjin was giving an idea to help as he always does. There's no harm in that.