Continuing on my path down the Python language, I am continually plagued by the wondering question of whether Python would be useful in an embedded development environment. Having spent most of my programming life in the trenches with C, GNU cross-compilers, and device register sets, I am very aware of how manual and arcane the development toolset for working directly with devices. We're not even approaching talking about having GUIs. At best, the command-line is what you would get to invoke C routines from the vxWorks shell. The nice thing about the shell is that you can dynamically load your pre-linked object file into your running system. At worst, you have to write a dummy routine to call your test. You then re-link your entire system, download to the target and restart the target. Like I mentioned in a previous article, this entire process can be very time intensive.
In my travels in Python, I have come across many articles relating to task in working on Unix servers. Some of these occasionally appear in The Linux Magazine. Slowly there has been some interest from the desktop development side with Microsoft Windows. That is why I am pleasantly surprised to come across a paper published from the Python 10 proceedings dealing with embedded development. Grendel: A Python Interface to an 802.11a Wireless LAN Chipset
This is interesting reading if you've ever spent some time in the embedded software world. "bit-twiddling", as I affectionately call it, makes up the majority of the work. God forbid if the first prototype hardware doesn't work like it was designed. I remember working with the first article ASIC for the Com21 DOCSIS cable modem. My part was just supposed to be providing tests for the ethernet filtering engine of the ASIC. As it turns out, if you deal with a particular hardware device at all... you end up owning and being responsible for the entire software base that deals with it.
but that's history....
I have been using Python for about 6 months now and I do believe that it is a fairly good language to grasp on if you care about Rapid Development and Object Oriented structures in computer languages. I have done C for about 10 years and C++ for 4. C++ was a pleasure to work with after having to grapple with self-made object oriented C constructs for years. Having worked with the Microsoft MFC world for a while, I learned to appreciate the higher level constructs provided by having a class library infrastructure. Coming from an embedded development background with WindRiver's vxWorks, I thought that working with a structured class library was a godsend.
MFC was great at allowing to make the User Interface behave the way you wanted to. But then there are also many 3rd party code (ActiveX) that you can rely on also. I began to dive into a couple of controls and realize that many of them returned a datatype called VARIANT. Ok, it's a Visual Basic data type and after struggling a little, I managed to make a little bit of it work by calling it from an MFC application. However, data transfers between the ActiveX component and C++ through VARIANTs remained cumbersome and involved a lot of Microsoft type-casting code. Gradually, I came to realize that the majority of ActiveX controls out there are made for Visual Basic. If I wanted to better utilize them, I better learn Visual Basic.
I struggled with the "spaghetti-ness" of Visual Basic and gradually gave up on it. That is when I came across Python. It is a relatively unknown language that has been around for over 10 years. It is mainly used in the Unix community and its library support is quite vast (although increasing slowly). The Python shell reminds me of the vxWorks shell which (in my mind) was the single greatest invention for rapid development (see footnote 1). Adding to that the more solid support for internet protocols as well as the fact that it is free made me recognize that I MUST learn Python.
I must say that the Python road is a less traveled one. In some ways I am glad because the reading material I have come across from other people who travel this path are rather good. I am glad to be learning from smart people (or at least people who are smarter than me). This is when I arrive at GUI development. The unfortunate part is that Python has its roots in Unix. Support for command-line type programming is beyond compare. However, there is ZERO attention to GUI. Yes, there is tkInter and other GUI framework... but none of it was standard to the x86/windows platform. To be honest, I haven't dived into Mark Hammond's Idle support for COM yet either (the GUI area is very fragmented still). The comparison of Python GUI frameworks should be delayed to another time.
After looking at some various frameworks, I came about trying PythonCard. PythonCard abstracts the wxWindows library for people working in Python. Unsurprisingly, the concepts of GUI elements as widgets are still around. I liked OO abstractions for GUI since Borland's OWL (footnote 2) because it limits the amount of code you have to read or wade-through. And it is this very aspect that I must praise PythonCard. I took a sample application and modified the GUI elements and put my own program upon it. The entire thing fits in about 2 pages. Thinking back in my MFC days, I would have to say that the equivalent MFC based program would have to have at least 4 files with about 3 to 4 pages of code for each file. Yeah for abstractions.
PythonCard is at version 0.7 and is probably equivalent to MFC 1.0... A "right-off-the-cuff" comment is that it is way behind in terms of GUI evolution. However, I seriously doubt if any movement would conquer Microsoft's army of developers. The one solid thing PythonCard does have is Python and the cross platform-ness. This means the programs will run on Unix, Linux, Windows, or OS-X.
For those who are more interested in Python and User Interfaces, O'Reilly has an index on such a topic.
__________________ Footnotes __________________
(footnote 1:) In the embedded world, I have worked with vxWorks, pSOS, and uCOS. The single biggest detractor in development is the compile-link-download (or flashing) cycle. The shell allows you to try something very quickly and get results whether it worked or not. This method of unit test is indispensable when it comes to large scale testing. If you don't find the bug now, it's just going to bite you in the end during the integration cycle when it is obfuscated with a bunch of other bugs also.
(footnote 2) Borland's OWL was a GUI class library in competition with Microsoft's MFC back in the 90's. OWL encapsulates GUI objects much like widgets. The widget code is much cleaner than the wizard code generated by Visual Studio. Unfortunately Microsoft's might just killed the OWL project quite early. OWL may have been reincarnated in the C++ Builder project (just my speculation), but that too was killed.