The subject that fascinated me was the idea of using genetics to create art …

I am very reluctant to say something is impossible, as that is just trying to predict the future, which in the world of technology is very foolish. Knowledgeable people have said some very stupid things:

“A vehicle accelerated up to 60mph would kill all passengers aboard.”

“I cannot imagine that anyone would need more than 640K of memory in their PC.”

“The worldwide market for computers will never exceed about a dozen units.”

OK, I have paraphrased and the speakers have usually qualified their statements later, but my point holds.

The story, that I heard, was that an artist had found a way to take some DNA – say a discarded hair – and extract the complete genetic code from it. Then they would use this information to make a mask – a sculpture, if you like – of the person’s face. There is more information and some images on her website.

My first thought was that this was a remarkable use of technology and an amazing fusion with art. My second thought was that it must be hoax.

I just do not believe that we have a sufficiently well-developed knowledge of the human genome that such an analysis would [yet] be possible. I think it very likely that we will at least get close to this capability in the future, but I just do not think that we are there yet. If we were, surely the police would be able to create accurate facial images of suspects, which would be a very powerful tool. To the best of my knowledge, it is not yet possible to even identify simpler characteristics from a DNA sequence: racial group, height, eye color etc. Also, archaeologists would love to be able to put a face on historical figures; currently they use artists who base their impression on skull shape.

A further issue I have is more a matter of logic. If this technique did work, and I gave the artist some of my DNA and she made an image of my face, would it be my physiognomy now, or when I was 20, or when I was born, or how I will be when [eventually] I am an old man? It seems odd that the artist seems to only produce contemporary images.

OK, I may be wrong and this technique might work as advertised. Another question would be the ethics of using genetic material in this way. I guess it is not too different from taking someone’s photo …

On a desktop computer, updates to system and application software seem to come thick and fast, giving vendors the opportunity to provide us with new features, fix old bugs and introduce new and interesting ones. For embedded systems, the matter is a little more complex …

Years ago, embedded system software [firmware] was burned into a PROM and inserted into a socket in the target system. Later changes to software simply involved the swapping of PROMs. I say “simply”, but it could be far from simple, as several pitfalls were possible:

• Getting the right PROMs in the right sockets [the right way around].
• Finding PROMs had been soldered on to the board to cut costs.
• The system has shipped to numerous customers …

Nowadays, matters are generally eased because the majority of embedded systems keep their code in flash memory, which can normally be reprogrammed in situ. There are broadly 3 ways that the updated code might be transferred to the device:

• Network
• Wireless
• USB

If the embedded device is connected to the Internet or even just to a LAN, there are a selection of possible ways to implement software updates. This is somewhat similar to the situation with desktop computers.

Wireless connectivity gives other options. If it is a network connection, the same opportunities are available as with a wired network. But there are also other possibilities. A set top box or video recorder might receive updates via TV transmissions. A spacecraft [on the surface of Mars, for example] might receive updates via the NASA Deep Space Network.

For those of us still on planet Earth, a common connectivity option is USB, topic that I have written on before. There is a USB device class called Device Firmware Upgrade [DFU], which defines a protocol for sending new firmware to a device.

The specification for DFU is freely and readily available and support is available in many embedded USB stacks – including Nucleus USB, of course.

The details of DFU operation are well documented and quite complex, but the basic principle is quite straightforward. If a device supports DFU, it advises the host of this fact during enumeration. The device then operates in two distinct modes: “normal” mode and DFU mode. When the device is connected to the host, it appears to be a normal peripheral. For example, a keyboard would appear to be a normal HID class device and be connected to the appropriate host driver. When the device enters DFU mode, it disconnects from the host, then reconnects as a DFU device and is associated with the host DFU driver, which manages the update transfer.

A small downside of DFU is that no standard Windows driver is provided. However, drivers are available from other sources.

We are also hearing every day about new uses for genetic knowledge. Although research into genetically related disease is very topical, I am particularly interested in two other applications of genetics and the issues raised by their use …

The first of the two genetic technologies to grab my interest was “genetic fingerprinting” [the other will wait for another day]. The idea is simple enough: just like we all have unique fingerprint patterns, everyone’s DNA is different. So, if you have a sample of DNA from a crime scene and you have a suspect, you can look for a DNA match, which would give evidence to say that, at least, they had been at the crime site.

The comparison technique used is relatively simple. There is no attempt to match DNA material gene by gene. Instead the DNA is “profiled”, which entails locating a number of well-defined markers in the DNA which characterize it. This essentially yields a number which is unique to that DNA [at least, the chances of another, different DNA sample yielding the same number is astronomic]. So this process is applied to the sample gathered at the crime scene and to the suspect’s DNA. A match is bad news for the suspect.

There is much debate about the retention of DNA profiles gathered from individuals, particularly if they are shown to be innocent. It seems that people feel that their privacy/freedom is being infringed. I fail to see how this is the case. The DNA profile is just a number and, despite many fantastical press reports, cannot be used for any purpose other than matching a sample. I would be very willing to have the authorities keep my profile on file. That way, if a crime is committed and I am even slightly suspected, I can be eliminated without even being troubled by a phone call. As I have no plans to commit any crimes, what have I got to lose?

This could also be applied to immigration. Instead of taking my fingerprints [sometimes] when I enter the US [which I find slightly degrading for some reason], I think that I would find being asked to provide some DNA a bit more satisfying: “Welcome to the United States Mr. Walls. Sorry for the interminable wait in the immigration line after your 11 hour flight. Would you care to spit here please …”

Broadly speaking, this is really a manifestation of what physicists call the Observer Effect. This effect refers to changes in a system that are caused by attempts to make measurements. This effect can be mitigated in various ways, but there is the possibility of eliminating intrusiveness all together …

Even using LTTng, as I discussed before, does have a very small impact on the performance of the system that is being debugged. For most applications, the impact is negligible and may be ignored. However, there are occasions when the real time behavior of a system is absolutely critical. It may not be the case for all aspects of a system, but if just part of it exhibits such time criticality, it is a safe bet that you will need to debug that area.

There are two ways to approach this problem. First is to consider simulation. This is a low cost way to run a system in a potentially cycles-accurate way, even if it is not at full speed. If that is not viable – because you really need to run at full speed to interact with other systems – some appropriate instrumentation is required.

Historically, very high speed probes, that enable a system to be monitored at full speed, have suffered from three drawbacks:

• Cost – they tended to be very expensive
• Capacity – trace buffer size was never quite enough
• Usability – the user interface was typically unfamiliar to the developer

The good news is that all three of these issues have been addressed to the point that this approach is viable for many development teams. Mentor Embedded announced the integration of Ashling’s excellent Vitra-XD with the Sourcery CodeBench environment. This gives the developer the opportunity to seamlessly move from debugging/analyzing code on a real target or under simulation to operating with a state of the art trace probe.

I always marvel at the complexity of biological systems – how everything fits together to make elegant, efficient, self-maintaining machines. I sometimes have to catch myself, when I have the thought: “That is a cool design.” I did that recently when looking at the semi-circular canals in our ears that give us a sense of balance. Of course, design does not come into it. These amazing systems are the result of evolution by natural selection, which is such an astounding process that I do not need to invent a “designer” to explain matters.

I guess the pinnacle of evolutionary development is the human brain …

The brain is a computer; in many ways it is similar to the machines that we use every day. The evolution of the brain is certainly analogous to that of the computer. Over millions of years, brains have evolved from just a few cells to the billion or so inside your head. Compare this with computers which have gone from hundreds of transistors to hundreds of thousands to the billion or so in a modern PC’s CPU.

So, how is the brain going to evolve? We can look at how computers are moving forward. Although processors are getting bigger, more complex and more powerful, the big movement is towards multi-processing. It is already very common for desktop computers to sport a quad-core CPU; modern supercomputers use vast arrays of processors to perform massively parallel processing tasks.

The human brain can already perform multiple actions simultaneously – I am not going to discuss the possibility that one sex may be better than the other at multi-tasking! On a larger scale, the brain has two, semi-autonomous hemispheres. Long ago, I wrote about how the brain solves problems. But where next?

Let’s try a thought experiment. Put a person in a room alone and ask them a dozen questions which have basic, factual answers. Do this twice – once in 1963 and again in 2013. How would the results compare? You might think that there would be little to choose between them, but, if you took no particular precautions, the 21st Century man would always win. His smart phone or tablet would give him immediate, efficient access to the world’s knowledge, so how could he lose?

IMHO, this is the answer. The next step in human brain evolution is the Internet. Many of us already take it for granted that any information we need will be at our fingertips. This has become easier over the last few years, as tablets and smart phones have made access so convenient and immediate. This is great, but you ain’t seen nothing yet!

There has been much talk about Google Glass lately and the idea of “wearable computing” seems to have arrived. The possibility that a device can use access to the Internet to simply augment our ordinary experiences is the stuff of science fiction, but that possibility is being realized [almost]. I have only seen one person wearing Google Glass so far – I have to say that he did look rather distrait …

The next logical step is a more direct connection from our brains to the Internet, cutting out the inefficiencies of typing, talking, reading etc. I visualize a world where you would only have to think “What was the population of Hong Kong in 1929?” or “What is the next train due at this station?” and you would instantly know the answer. I am not sure whether this is scary or exciting, but I have a feeling that it is inevitable.

A while ago, I wrote about incorporating a Web server [HTTP server actually] into an embedded device so that information might be displayed on any connected Web browser. Along the same lines, I have been thinking about using email …

When I talked about adding a Web server to an embedded device, I was not suggesting that the device in question actually hosted a publicly accessible website. The idea was to simply leverage Web technology. Web pages – HTML etc. – is easy enough to use to create a user interface; the HTTP protocol is straightforward to handle; Web server software is readily available for most real time operating systems, including Nucleus, of course. The result is a powerful and readily maintainable UI solution with minimal coding.

We can apply the same philosophy to the use of email. I am not, of course, suggesting that a device have an email account so that it can keep in touch with its friends and relations. I am talking about the leveraging of technology. Imagine a device that needs to periodically send [and/or perhaps receive] modest amounts of data to a remote location and it is connected [at least some of the time] to the Internet. A possible example might be a WiFi enabled vital signs monitor worn at all times by a chronically ill patient; it might send a set or readings to the hospital periodically or when there is a significant change.

Although there are a number email protocols in use, Simple Mail Transfer Protocol [SMTP] is very common and widely understood, as it has been in use since the earliest days of the Internet. SMTP is normally only used for sending emails – the sender needs to have SMTP client software and the mailer server will have an SMTP server. Other email protocols in use include Post Office Protocol [POP3], which is complementary to SMTP and used to receive email, and the Internet Message Access Protocol [IMAP], which provides more sophisticated capabilities.

SMTP is a simple, text based protocol, which really only uses 3 types of message [MAIL, RCPT and DATA]. It is, therefore, easy to apply and monitor/debug. An SMTP client can be [and usually is] very light weight and readily available for many popular RTOSes, like Nucleus. The simplicity is attractive because it minimizes development time. The small size is useful for many embedded devices where memory is at a premium, but is also a benefit for applications [like medical devices] where certification is required – less code = cheaper certification.