I've been reading some of Don Box's blog entries, one in particular caught my eye - http://www.gotdotnet.com/team/dbox/default.aspx?month=2004-04
This article talks about giving Administrators and Developers the ability to do their jobs without needing to know and understand the inner workings of the network or development environment - the trend to abstract developers away from the underlying operating system is quite apparent when you look at the productivity gains when programming using the .NET Framework rather than raw Win32 API's - even within an embedded operating system an abstraction layer exists so that application developers don't need to know or care (for the most part) about the underlying hardware - an applicaiton developer that wants to write some data out to the serial port simply calls CreateFile( ); on “COM1:”, then WriteFile( ) to write some data, then CloseHandle( ) to close the transaction - the application developer doesn't need to know or care about the underlying hardware - the device drivers within the o/s take care of this.
For Embedded systems there are perhaps two levels of abstraction that need to take place, the first is within the operating system, the second is on the final device - let's take a look at both.
Embedded developers are being put under an increasing amount of pressure to get devices to market quicker and with more features than before - increasingly developers are looking to save time in devleopment - why would an embedded developer spend time writing a TCP/IP stack when this already exists in operating systems such as Windows CE or Windows XP Embedded? - the embedded developer should be focused on adding value to the final device through the addition of a custom shell, external peripherals and applications that provide the functionality needed for the final device. Operating system vendors should be making this process as easy as possible, giving the embedded developer access to the underlying technologies needed to ship their device without the developer needing to spend time on learning the inner workings of the o/s, right ?
The second level to this process is the final device - embedded developers should be thinking about their customers, many of which don't know or understand the technologies included in the device, how many end users really understand technologies such as TCP/IP, HTTP, POP3, DHCP etc... - end users shouldn't need to know about the technologies (and should never see a message box on screen that mentions these technologies) - as embedded engineers we need to make it easier for the end customer to configure and use the devices we build.