I am researching TinyOS for a school assignment and read that the "core OS is 400 bytes", and another source saying "The footprint of TinyOS is 400 bytes" What exactly does this mean? Is it the actual space it occupies on harddrive?
How big ia a "traditional" OS such as windows?
The answers I have found of what "footprint" actually means is confusing too. Because it seems to mean both actual physical space and memory/disk space.
Just to explain a bit of background, the authors of TinyOS themselves have explained that TinyOS isn't really an operating system:
TinyOS has a component-based programming model, codified by the
nesC language, a dialect of C. TinyOS is not an OS in the traditional
sense; it is a programming framework for embedded systems and set of
components that enable building an application-specific OS into
each application. A typical application is about 15K in size, of which
the base OS is about 400 bytes; the largest application, a
database-like query system, is about 64K bytes.
TinyOS is a software build system designed to allow software engineers to more easily build software for really tiny devices (like this wireless sensor), which do not have a harddrive. Instead, the program is typically stored inside the microcontroller of the device - the device I linked to for example has 48k bytes of flash memory (small embedded devices like these often use flash memory to store their program). 48k of code isn't very much, so it's really important that when you're making software to load onto the device, it takes up as little space as possible.
So, the 'base footprint of 400 bytes' means that, on top of the code that you (the software engineer) write to do whatever your tiny device needs to do, the TinyOS framework (which supports and provides services for your code) only adds an extra 400 bytes (which is really amazing!) to your program code which will actually be loaded onto the device's flash memory. However, this isn't the only overhead - depending on the device, TinyOS may also include various different supporting drivers for whatever chips and components exist on that device.
See figure 6 in this paper for some examples of actual program sizes.
Because of this I have found that building the same application for different devices using TinyOS can yield very different results. For example if I build a really simple program for the MicaZ wireless sensor I get:
compiled NullAppC to build/micaz/main.exe
610 bytes in ROM
4 bytes in RAM
Which means that the total program code, plus the base OS (400 bytes) is 610 bytes (the program will also use 4 bytes of RAM). However if I build the same program for TelosB:
compiled NullAppC to build/telosb/main.exe
1328 bytes in ROM
6 bytes in RAM
1328 bytes! Clearly TelosB requires a lot more additional software, presumably because the components on the TelosB require more complicated additional driver software.
Related
I'm curious about how the drivers work out of the box in x86 motherboards, like display, USB controllers etc.
For example :
Booting a toy custom kernel in x86 can display to screen without doing any extra work on the drivers space, however for an Android phone which is an embedded system, it seems almost impossible to display to screen with my own toy custom kernel (as there is information out there available about the memory map of the device and how the display is interfaced with the device).
Why is that I/O works out of the box in x86 motherboards and doesn't on embedded computers?
x86 PC firmware has standard software interfaces (a lot like system calls), either modern UEFI or legacy BIOS int 0x10 and other interrupts.
The key point is that it's not just bare-metal x86, it's IBM PC-compatible which means software and even emulated legacy hardware like a PS/2 port, VGA, and even legacy interrupt controller.
If you didn't have all this help from firmware (for the benefit of bootloaders and toy OSes), you'd have a much harder job, e.g. needing at least a basic USB-hid and USB host-controller driver to get keyboard input. The lowest level function to handle a user input
Why is that I/O works out of the box in x86 motherboards and doesn't on embedded computers?
That's not your real question. Embedded machines have working I/O hardware, they just don't come with portable software APIs/ABIs wrapped around drivers as part of the firmware.
I think most vendor's SDK comes with functions to access the I/O hardware (after maybe doing some fiddling to get it into a usable state). i.e. to write your own driver for it.
Embedded doesn't need this in firmware because it's expected that the kernel will be customized for the hardware.
Wouldn't it be better to have a BIOS or UEFI for maximum portability? Does it have any drawbacks to include one?
Yes: code size in the boot ROM, and someone has to write + debug that code. This costs time and developer salary.
No point in booting up what's nearly an OS (a UEFI environment) just to load a kernel which is going to take over the HW anyway.
Also a downside in boot time: any code that runs other than loading the kernel where it wants to be is wasted CPU time that slows down the boot. Having a very lightweight interface that just lets you get your kernel loaded, and leaving all the I/O to it, makes sense for this.
Unlike x86 PCs, there's no expectation that you can use this hardware with an OS install disc / image you downloaded that isn't specifically customized for this hardware.
It's not intended to be easy for hobbyists to play with using training-wheels APIs. Real OSes on this hardware won't use such APIs so why provide them in the first place?
All I know is It helps in initializing processor hardware and operating system.
First I need to know what is a firmware and how it works.
Probably showing a list of firmware and what they do can be a good idea for explanation.
Typically, microprocessors performa start up process that usually takes the form of "begin execution of the code that is found starting at a specific address" or "look for a multibyte code at a pinpointed location and jump to the indicated locale to begin execution"
Since the introduction of IC ROM, with its many variants, including, but not limited to mask programmed ROMs, and programmable ROMs, and EPROMs. Since this time, firmware boot programs were shipped and isntalled on computers. Then the introduction of an external ROM was an italian telephone switching elaborator, called "Gruppi Speciali".
When a computer's turned off, it's software remains stored on nonvolatile data devices such as HDDs CDs DVDs SD cards, USBs, floppies, etc. WHen the computer's powere don, it doen't have an operating system or its lloader in RAM, it first of all executes a relatively small program stored in ROM, along with a small amount of needed data to access the nonvolatile device or devices from which the operating system programs the data and can be uploaded into RAM, this small program being known as a bootstrap loader.
Does the OS get this information from the BIOS or does it scan the buses on its own to detect what hardware is installed on the system. Having looked around online different sources say different things. Some saying the BIOS detects the hardware and then stores it in memory which the OS then reads, others saying the OS scans buses (e.g pci) to learn of the hardware.
I would have thought with modern OSs it would ignore the BIOS and do it itself.
Any help would be appreciated.
Thanks.
Generally speaking, most modern OSes (Windows and Linux) will re-scan the detected hardware as part of the boot sequence. Trusting the BIOS to detect everything and have it setup properly has proven to be unreliable.
In a typical x86 PC, there are a combination of techniques used to detect attached hardware.
PCI and PCI Express busses has a standard mechanism called Configuration Space that you can scan to get a list of attached devices. This includes devices installed in a PCI/PCIe slot, and also the controller(s) in the chipset (Video Controller, SATA, etc).
If an IDE or SATA controller is detected, the OS/BIOS must talk to the controller to get a list of attached drives.
If a USB controller is detected, the OS/BIOS loaded a USB protocol stack, and then enumerates the attached hubs and devices.
For "legacy" ISA devices, things are a little more complicated. Even if your motherboard does not have an ISA slot on it, you typically still have a number of "ISA" devices in the system (Serial Ports, Parallel Ports, etc). These devices typically lack a truly standardized auto-detection method. To detect these devices, there are 2 options:
Probe known addresses - Serial Ports are usually at 0x3F8, 0x2F8, 0x3E8, 0x2E8, so read from those addresses and see if there is something there that looks like a serial port UART. This is far from perfect. You may have a serial port at a non-standard address that are not scanned. You may also have a non-serial port device at one of those addresses that does not respond well to being probed. Remember how Windows 95 and 98 used to lock up a lot when detecting hardware during installation?
ISA Plug-n-Play - This standard was popular for a hot minute as ISA was phased out in favor of PCI. You probably will not encounter many devices that support this. I believe ISA PnP is disabled by default in Windows Vista and later, but I am struggling to find a source for that right now.
ACPI Enumeration - The OS can rely on the BIOS to describe these devices in ASL code. (See below.)
Additionally, there may be a number of non-PnP devices in the system at semi-fixed addresses, such as a TPM chip, HPET, or those "special" buttons on laptop keyboards. For these devices to be explained to the OS, the standard method is to use ACPI.
The BIOS ACPI tables should provide a list of on-motherboard devices to the OS. These tables are written in a language called ASL (or AML for the compiled form). At boot time, the OS reads in the ACPI tables and enumerates any described devices. Note that for this to work, the motherboard manufacturer must have written their ASL code correctly. This is not always the case.
And of course, if all of the auto-detection methods fail you, you may be forced to manually install a driver. You do this through the Add New Hardware Wizard in Windows. (The exact procedure varies depending on the Windows version you have installed.)
I see a lot of info about system hardware, except for memory ,one of the main important part besides the cpu, which funnily isn't really mentioned as well.
This is fair because perhaps there's so many things to enumerate, you kind of lose sight of the forest through the trees.
For memory on x86/64 platforms you will want to query either BIOS or EFI for a memory map. for BIOS this is int 0x15 handle 0xe820. EFI has it's own mechanism which provides similar information.
This will show you which memory ranges are reserved by hardware etc. in order for your OS to know to leave them alone. (ok you have to built that part too of course ;D)
For other platforms, often the OS will be configured for a fixed memory size, like in embedded platforms. There is no BIOS for you, and performing a sort of bruteforce on memory is unreliable at best. (as far as i know! - not much experience outside of x86/64!!!)
For the CPU you will definitely want to look into MSRs, control registers and CPUID functions to enumerate the CPU and see what it's capable of. you can query if for example 64 bit mode is supported, and some other features which might not be present on all cpus.
For other hardware like pci etc, i would recommend like myron-semack said to look into PCI specification, pci-express, and importantly ACPI as implementing that will make you handle hardware and powermanagement a . bit more generically / according to newer standards.
As far as I understand it, any program gets compiled to a series of assembly instructions for the architecture it is running on. What I fail to understand is how the operating system interacts with peripherals such as a video card. Isn't the driver itself a series of assembly instructions for the CPU?
The only thing I can think think of is that it uses regions of memory that is then monitored by the peripheral or it uses the BUS to communicate operations and receive results. Is there a simple explanation to this process.
Sorry if this question is too general, it's something that's been bothering me.
You're basically right in your guess. Depending on the CPU architecture, peripherals might respond to "memory-mapped I/O" (where they watch for reads and writes to specific memory addresses), or to other specific I/O instructions (such as the x86 IN and OUT instructions).
Device drivers are OS-specific software, and provide an interface between the OS and the hardware.
A specific physical device either has hardware that knows how to respond to whatever signals from the CPU it monitors, or it has its own CPU and software that is often called firmware. The firmware of a device is not specific to any operating system and is usually stored in persistent memory on the device even after it is powered off. However, some peripherals might have firmware that is loaded by the device driver when the OS boots.
There are simple explanations and there are truthfull explanations - choose one!
I'll try a simple one: Along the assembly instructions, there are some, that are specialized to talk to peripherials. The hardware interprets them not by e.g. adding values in registers oder writing something to RAM, but by moving some data from a register or a region in RAM to a peripherial (or the other way round).
Inside the OS, the e.g. the sound driver is responsible for assembling some sound data along with some command data in RAM, and the OS then invokes the bus driver to issue these special instructions to move the command and data to the soundcard. The soundcard hardware will (hopefully) understand the command and interpret the data as sound it should play.
I want to know the feasibility of these things:
1) Is it possible to download 200MB audio files to our application?
2) How much RAM can be accessed from an iPhone app? What is the largest amount of RAM an app can expect to use?
Anyone's help in this regard is deeply appreciated.
Thanks to all,
Monish
1) Yes, although you might make users angry who are not on Wifi + fast DSL. Also you will need to handle interrupted downloads.
2) No, since ARM is a 32bit processor a maximum of 4GB RAM can be addressed. Anyhow, iDevices have a maximum of 512MB right now (iPad 2). Your application will get killed by iOS if your app takes about 75% or so of the available RAM which means in reality you shouldn't use more than, say, 80MB of RAM. And if you need to address 8GB then your design is totally flawed to begin with.
There are always ways to work with a lot less (e. g. either by using better algorithms and/or by caching to disk). On the disk, you are only limited by the available space left on the device. So if you have an iDevice with just 8GB you're naturally out of luck as the system itself and other apps/data are reducing the available space. Same if you're on a 64GB iDevice which is packed with movies. You will need to be able to work with the space that is available. You can, for example, try to "reserve" the necessary space by creating a file and making it as big as you need it (via a seek and a write) but be prepared for angry customers.