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.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
Using Siemens NX software, a team of engineering students from the University of Michigan built an electric vehicle and raced in the 2013 Bridgestone World Solar Challenge. One of those students blogged for Design News throughout the race.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.