I consider myself an interface between the hardware and software departments so I have most definitely read a datasheet and it is a common activity in my day. Really appreciate this course, thanks Mike.
@adse Linus believes that source debuggers are a crutch for the weak. ;-) His thought, as I interpreted it, is that if you don't know what to look for (so you could capture it in a printk), then you probably don't know enough about device drviers and the kernel to be effective as a developer in that space. Of course, printk's can increase latency in the kernel, that's why /proc or /sys is interesting. Only give the the info when I want it rather than any time the driver runs.
@luizcosta I've not seen a video course. PTR has discussed doing a video course in the past. But, the costs of production and distribution typically outweigh the benefit with a perishable code base like the Linux kernel (things chage pretty quickly, so the video would go out of date). But, PTR's training classes do give you the charts and the labs for you to run on your own system (our labs are written to run on our beagleboard-based systems).
@plung Unfortunately, the Arduino ATMega chips are way too small to run Linux. Even the Mega2560 only has 256KB of Flash and 8K of SRAM. The smallest Linux system I've worked on had 1MB of RAM. So, the Arduinos can be used as Linux peripherals, but they can run Linux directly.
@timd Hmm... Well it depends on the frequency of access. Doing the access in kernel space allows you to remove the trap transition from user to kernel space. But, most I2C devices are pretty slow. So, there may not be any significant benefit. But, the faster you access, the more likely it is that moving to kernel space will help. It can also help you better abstract the devices. This is the basis for how devices are handled in Android. They're all abstracted and presented to the user using one of the "flingers".
@Mike: I am using i2C to communicate to ADC's and Expantion IO hardware. Currently, all the software I have written runs in User-space, using ioctle, write, open functions. Would there be any benifit to creating seperate drivers for this hardware?
Michael - thanks for this course. It is a good reminder of the unix mideset. having worked with RTOSs and bare metal embedded systems this has been a fun exposure to some of the areas that I had not used in the past.
If you where to mount a file system on top of an existing directory anything in the original directory would be masked by the one you mount on top of it. There are also things called "fuse" mounts that allow entries in the base directory that don't exist in the overlay directory to be seen. This is used in /dev when we're running the udev hot-plug system.
So far, all of the interfaces we've talked about in these past couple of days are found in both 2.6 and 3.x kernels. It's really a matter of degree for many of these. 3.x kernels have more features for some of the services like ftrace and oprofile. But they exist in the kernel way back to 2.6.27.
@MIKE: let me rephrase my question with another. When you mount a filesystem to a directory, say /proc, all you see or have access to after that is what is in the filesystem. so, If you mount anything to /etc, it is my understandiing that everything in persistent space, can't be seen, until you unmount the fs. Is that accurate?
The config files for passwds and the like are all kept in /etc. They have persistence over boots because they're stored on the root file system. /proc and /sys dissappear twhen the system is shut down.
Kernel debugging is normally down by "systems programmers". These are the folks who port the operating system to a new platform. But, a manufacturer of a plug-in card could also develop their own driver for their hardware. I'd encourage then to open-source the driver so we could include it in the mainline kernel. But, that is not a requirement.
@Rob Spiegel: I just had an epiphany. Every time you ask a question, my audio breaks up, because both the chat and audio data are coming over the same 3G data connection and compete with one another. Not much you can do about that of course.
@caa028: the "leading zero" is a feature of the C programming language to indicate that the value is an octal constant. So for example, decimal 13 = hexadecimal 0xd = octal 015. In other words, 13, 0xd, and 015 all represent the same value to C.
JSP - just remember, all we sent to Mars was a few thousand bucks of materials. All the rest was paid to companies and folks back here on Earth. (And we get lots back in new technologies and inventions; don't need Mars-knowledge for payback...)
The streaming audio player will appear on this web page when the show starts at 2pm eastern today. Note however that some companies block live audio streams. If when the show starts you don't hear any audio, try refreshing your browser.
Engineers at Fuel Cell Energy have found a way to take advantage of a side reaction, unique to their carbonate fuel cell that has nothing to do with energy production, as a potential, cost-effective solution to capturing carbon from fossil fuel power plants.
To get to a trillion sensors in the IoT that we all look forward to, there are many challenges to commercialization that still remain, including interoperability, the lack of standards, and the issue of security, to name a few.
This is part one of an article discussing the University of Washington’s nationally ranked FSAE electric car (eCar) and combustible car (cCar). Stay tuned for part two, tomorrow, which will discuss the four unique PCBs used in both the eCar and cCars.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.