|
|
Hi there, Cheers /peter |
|
|
Peter, Our stack roughly looks like this: />[Java code providing OSGi services] [JNI bindings] [Linux Kernel Drivers] [Hardware] At the lowest level, a new module plugging in shows up as a new device in the Linux kernel running on the BUGbase. Each module is basically a peripheral to the base. So all the code whether it be drivers or Java is stored on the based. The kernel is in the onboard flash memory, and everything else runs off the SD card. The BUGbase is running our Java & OSGi stack. OSGi is the magic that makes our whole modular strategy work by handling the life cycle issues of different services being available at different times due to different modules being plugged in or different applications installed. So when a new module is plugged in the new services start running in the OSGi server, and when it is unplugged those stop. The advantage of this approach over having each module have its own code is two fold. One, you don’t have to flash each module to upgrade their software. Two, there is a huge complexity savings of having each module being basically a peripheral vs each device being its own computer. Even when someday we have 100 modules it won’t be a problem for the BUGbase because you can only have 4 plugged in at a time, so the rest will just be code sitting on the disk not running since OSGi will only run what is necessary, and that code is not very large compared to the size of the SD card or the file system in general. |