What's going on with the AF_BUS Linux kernel patches, and my D-Bus in the kernel work based on my trip last week.
148 plus ones
Shared publicly•View activity
View 57 previous comments
If there are real-time constraints, an RTOS has to be used, not Linux. OSEK is as an example of an open automotive RTOS, which is able to cope with hundreds of messages coming from buses in real-time manner and which is widely used.
The current automotive 'multimedia' ECUs (camera systems , satnavs, not head units), usually consist of a 'host' processor and a 'main' processor. The host processor is connected to CAN bus, running an RTOS (OSEK) and offloads handling of all real-time events, the main processor does the actual job.
The number of messages passed to the main processor can be still high - steering angle, speed or PDC distance (4 sensors+) could be updated every 40-50ms, plus a lot of internal events - new camera frames, data from GPS, gyroscopes, RDS etc.
Linux is not in a bad position as it might seem here. The complexity of our SW has grown enormously during the last few years, as well as the networking topology in cars and I feel that the way, how I have designed applications so far, is not possible any more. The fact that RTOSes mostly use only threads, sharing the same memory space without any protection, is a source of many delivery delays. A solution is to use a mature operating system and where it makes sense to split the application into isolated parts (processes).
I would need to handle ~400 events per second in time frame <~250us, the rest are interrupt driven things and given the architecture and the speed of processors planned for future projects, Linux can do that and a suitably designed messaging system would help a lot.
Anyway, time to move on something else.Feb 18, 2013
Heterogeneous SoCs sharing the same memory are just a pain. I would prefer N x A9 with NEON + GPU with OpenCL any time ...Feb 18, 2013
- Feb 27, 2013
- , please don't say things like: "If there are real-time constraints, an RTOS has to be used, not Linux", because it doesn't mean anything and perpetuates the idea that only something like RTOS or QNX is suitable for "proper real-time".
The thing is, when you buy into QNX, for example, you get a nice fluffy promise and no specifics. How many teams measure the latency for all the hardware and drivers they need to see if they behave deterministically, before slapping their application on top? In my experience, they simply buy the vendor's promise and trust that the vendor will hold their hand when the time comes.
In Linux land, there's no generic promise of all things to all people. Instead, we say things like: "it will probably work, but if it doesn't work you can always fix it yourself", or "it will probably work, but you need to look carefully at your exact requirements", or worst of all: "you probably need <another product>".
This isn't what people want to hear when they're short on time, short on skills, don't understand the exact requirements and are generally trying to minimise risk. The person who makes the decision doesn't want to see or touch code, they want a product that "works" and for someone to tell them that it will all be OK.
For many of these cases, Linux will be better than OK once the hand-holding problem is solved.May 1, 2013
- In some previous posts here netlink has been mentioned. Why is dbus in the kernel a good idea, when there is already netlink? Netlink provides one to one communication, and also broadcasts.
Maybe it's because I'm not aware on how things work in detail, but please can you explain when dbus is doing things better than netlink. Thanks in advance,
Stef BonJun 6, 2013
- as far as I understand, netlink needs a port to idetify a service, whereas dbus has a string idetifier representation.Sep 2, 2013