In memory mapped io for the raspberry pi, does the cpu write to ram and doe the io device then read that section of ram the cpu wrote to using dma?
I'm getting this impression by looking at the diagram from the BCM2835 ARM Peripherals guide. Can someone please clear up any misconceptions I have.
Related
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.
Articles on this topic from 2012 for earlier RPi hardware extolling the virtues of using an external USB flash drive are now dated.
In 2015, using Raspberry Pi 2 hardware, is there still any advantage to moving the root file system and booting from an external USB flash drive instead of just using the default microSD card?
I'm not sure if the raspberry pi bootloader is even capable of booting from USB, but I could be mistaken (there might be a way to set up an SD card to act as an intermediate step in mounting the OS from USB).
Aside from that, I can't imagine you'll notice much of a speed difference between the micro sd and a USB 2 flash drive (as far as I'm aware, the rpi doesn't have usb 3 hardware). Both will have similar life span.
Other considerations: power consumption (I believe SD has an advantage here, especially since a card will have to be used anyway to boot), quality of either device (you can buy really bad SD cards and USB flash drives alike)
I would be interested in seeing some bench marks if you decide to run any tests to see if there's a difference.
My DriveSpeed benchmark measures speed of large and small file writes and reads, plus random writing and reading. RPi 2 results for SD and USB drives are here.
http://www.roylongbottom.org.uk/Raspberry%20Pi%20Benchmarks.htm#anchor21
For booting, you need to establish which performance feature is more important and it is not just large file data transfer speed. Anyway, it mainly depends on the drive hardware performance characteristics. My system SD card can be out performed by SD cards in a USB card reader.
We are doing research into running a server on a Pi, and communicating with it via a webapp (over a local network) to control 2-3 servos. It appears that the Rpi has only one hardware configured PWM pin, but this can be worked around via servoblaster. However, since Servoblaster utilizes the Rpi's DMA, will it interfere with the Pi's ability to operate a web server? I apologize if this question is unclear i am somewhat unfamiliar with the software/network concepts involved. Additionally, is there a good resource for understanding the DMA function further?
Thanks in advance for any help.
You can control Servos using Software PWM, which will not require any further hardware or using DMA
If you care about performance and want more powerful hardware consider ODROID-X, it has 1.4GHz processor and 1GB RAM and cost $130, it is the best value for the price.
For other alternatives check Small low cost linux pc's
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.
How to reset PC(motherboard) from FPGA on PCI board (without BIOS manipulations)
Subj.
You are probably not going to find a scheme that works with all motherboards, if you even find any. Intel and AMD do this differently too. If you're lucky to find a motherboard where the PCI reset signals are open drain you might be able to drive it and cause some bad stuff to happen and cause a reset. If the motherboard drives those signals then you are out of luck (you could damage the driver).
You could also try to crash the system that would cause a reset, although that's getting harder nowadays with PCIe. Operating systems seem to be able to survive bad PCI devices due to better error handling and timeouts, etc.
Is this to implement some sort of watchdog? Probably easier to do this using IPMI and some sort of heart beat.