I was looking at some code for testing external memory devices recently, which motivated me to try to find some resources on how to properly test memory from software. I found a good article by Michael Barr (an expert author on embedded software topics) which recommends a test strategy and thorough set of tests, along with code examples.
My biggest takeaway from the article was, “… [T]he most common source of actual memory problems is the circuit board. Typical circuit board problems are problems with the wiring between the processor and memory device, missing memory chips, and improperly inserted memory chips.”
I was looking for a good refresher on memory technologies (e.g. NAND vs. NOR flash) today, and I came across the following “mini-course” (a set of slides with audio narration, 76 minutes long) provided by Numonyx: http://techonline.com/electrical-engineers/education-training/courses/4000348/Fundamentals-of-Memory
A fair amount of the material presented may be review for those with a computer engineering or electrical engineering background, but I still found it useful and interesting. It also contains an interesting overview of some future memory technologies.
I first came across Conway’s Game of Life randomly a few years ago on Wikipedia. I had heard of cellular automata before then, but hadn’t really understood what they were. Reading through the article, I was fascinated by how a collection of extremely simple “cells” (each having a binary state, “alive” or “dead”), when allowed to interact in an environment with extremely simple rules, can come to exhibit extremely complex behavior, even giving rise to “multicellular organisms”. Students of complex systems will find this phenomenon quite familiar, but for me at the time, it was new and mind-expanding.
Having worked on networked systems for the past few years, I can’t help but think Conway’s Game of Life is a great metaphor for how they behave. Each device in the system may be relatively simple, and its design and behavior relatively well understood. However, when allowed to interact with one another, such devices may exhibit behavior that’s very difficult to anticipate from the designs of the individual devices (and sometimes just plain baffling). It’s important to keep this in mind when estimating the workload and complexity of a project involving any sort of networking functionality.
I’m currently borrowing “Effective TCP/IP Programming: 44 Tips to Improve Your Network Programs” by Jon C. Snader (Amazon link) from a colleague. It’s got some really great advice on building robust and efficient networking application code, especially on top of TCP/IP and UDP/IP. I’ll probably be picking up my own copy soon.