Doug Gibbs


Biography has not been added


's contributions
    • You are correct. You can disable the app installer, and lock down the system. Karim Yaghmour has a git repository with the display subsystem disabled. That way you can run a headless Android system. There is a whole lot of extra "stuff" in the system that is not used when you do this. My argument is not "could you" the question is "why would you". There are big gains to be had using an established framework like Android. If your application does not fit those requirements, why are would you want to use Android for a generic embedded system?

    • My last job attempted an embedded Android device. It did not succeed or fail, the project was abandoned via layoffs. Why use Android? Ask yourself these questions first. 1. Do you need to run apps developed by outside Android developers? 2. Your product will also run Angry Birds, and 372 horoscope apps, are you OK with that? 3. Does the product have a display? If it does not, why use a big Java display engine for your product. 4. Software is hard. Writing it in Java for Android does not really help. Will your app go on other devices, not just yours? Some things you get for free in Android. 1. App signatures, you can't run unsigned code. 2. The update infrastructure is included. 3. You can run other peoples applications. 4. All the tools and a nice development environment.

    • Interesting. XMPP has a similar publish subscribe mechanism. Is there an implementation for the Broker component that would live in the cloud. An app using XMPP can leverage the open source servers in the cloud that scale and are proven to be redundant, fail over and all the other good stuff. Please point to an app using the protocol, or a reference implementation.

    • You are really talking about specialization. Not every developer on the team can or should know about the processor, interrupts and hardware interface. They simply can not and should not. Not great to keep us all employed, but true. The abstraction provided by an RTOS is needed. Quality can not be maintained in a system of any size if every single person working on it has to understand the true real time workings and interrupt vector table. I also agree that there is not a one size fits all RTOS. Linux is great, but it is not the universal hammer for all nails. If you suggest "let's write our own" you are as wrong as someone who claims Linux for everything.

    • Two points. First the use of a struct can be a problem for porting the code. I have been burned by the way the compiler packs, or doesn't the memory mapped registers. When the hardware does not match the processor alignment (newer 32 bit ARM accessing legacy hardware) this is especially ugly. Second, what if there are multiple timers, and I want the code to be common? Can the init code be passed the device base address? Then the rest of the code can use multiple instances of the device hardware.

    • So I have a new Android phone. It does everything. My wife calls and the phone does not ring. Later, I will see there is a message. Am I the crazy one who wants to get calls on my phone. Loosing Bob Pease and Jim Williams was a shock. I have their books on the shelf. I figure someday, maybe one of my kids will wonder how things actually work, and they will be useful for me to answer their questions. We are seldom lucky enough to learn from folks like them.