This article is a follow on from all the work I did on the Netbook. There were a number of minor issues that arose and although I managed to resolve the issues, I was not happy overall. What I did like about using the netbook is having the keyboard and screen available for diagnostic work and emergency changes. The concept for all this work is based on using the netbook for a remote radio repeater site where it collects operational data and sends it back over a wireless lan connection. The netbook works fine for being managed remotely, with the added bonus of being able to use the keyboard when someone is actually at the site.
Where the problem arose that I have not found a satisfactory solution for is the data collection. I have used for some time several devices, phidgets, tsl, and a RFX reciever. Each of these devices has some item that causes problems. The phidgets uses USB and require a special USB module in the kernel, which did compile and load on the arm netbook, but for some reason produces lower values and is not reliable in producing readings. I find the phidgets overall interface not to be compatible with what I want to do. All three of the devices have the same main flaw - I can't poll them and get just one item of data. Let me explain.
The phidget is being polled in the background constantly and producing new values whether or not I am ready to get them. The TSL device when polled returns all 4 temp sensor values in one string. The RFX receiver is even worse, in that it returns temperature and other values as each RF device transmits their values. I am not interested in using tons of computing power that I don't have to collect and sort through all the values to return a current reading. My latest design concept is based on a SSH command that causes a single program to run and returns the data at that time. I don't want any file I/O if possible, as that would involve reading and writing to a file system that I don't want to provide. A small virtual file system using extra RAM is fine, but with 104MB of usable RAM in the netbook, it can't be very big without causing memory shortages.
My Latest design consideration is using one of several SiLabs development boards and talk to it serially using MyForth. I recently studied all about USB protocol and have decided that I will only use two types of USB devices - memory devices (flash drives mainly) and serial devices. By serial devices I mean FTDI serial to USB converter driven devices - the RFX device is a FTDI USB serial interface and you talk to it just as if it was a regular serial port. Alternately I will use true serial device boards like the SiLabs development boards that talk to a USB to serial converter. I am using the mos7720 dual port converter on the netbook and am happy with the results. This design also limits the number and type of USB modules needed to be loaded into the netbook kernel.
This new design adds several features and enhancements, while only adding a little more programming and need for new skills. By using MyForth on the SiLabs boards, it is possible to do diagnostic testing of the data collecting system remotely and even make long term changes on the fly. This is why NASA uses Forth for most of the space projects as it allows for program changes to systems million of miles from home. In my case it will allow me to create a data collecting system that fits my special needs and returns values I can trust.
The next step is selecting which SiLabs board to use, and since I have several left over from previous developement projects, the choice is the F120. I have one with a bad port pin but other wise working normally with MyForth already loaded. I like the SiLabs board, as you can get some boards for as little as $35 each. My TSL device cost $30 and comes as a kit. The phidgets board I am using is now $89, which is almost the cost of a full SiLabs dev kit - $99 (board plus tools and pwr transformer).
SiLabs is a chip maker and produces the development boards for learning about their chips and aiding in designing with their feature rich 8051 based chips sets. To say there are lots of options and possilbe chips to use, would be an understatment. For my needs the 120 chip is over powered for what I want to do, but has lots of extra memory and I/O to test ideas and narrow down my usage. SiLabs also make a series of "toolstix" systems that are intended as prototype boards for the smaller set of chips. the "toolstix" is a USB based dongle that has a cpu card attached with a few I/O pins available for adding signals to. I have a couple of these and will be trying them later. Their cost is typically under $20 and might actually be all I need, but I don't have much time on using them and so will leave them for a later article.
What I do have is a used SiLab 120 dev board, MyForth installed on it, and some test code I wrote to prove out the use of a Wiznet adapter board. The "test120" setup, basically reads the cpu temperature, converts it into text that it wraps into a HTML formatted string and outputs this over the serial port. The idea was to create a simple HTML server using the Wiznet chip set to send over the network a properly formatted web page. It however is more of a "how-to" demo project to test if you have MyForth setup and running correctly. For us it will work to show what parts and pieces are needed to create a data collecting system using the netbook.
When you buy the SiLab comnplete development system, you get the board for the type of cpu your interested in, and everything to talk to it from a M/S Windows system. Typically there is a CD-ROM that contains the IDE and Software to talk to the board using the supplied USB to JTAG interface. There are no compilers supplied and thus that would normally be another expense. What Bob Nash, and Charley Shattuck have done is adapt process and code from work that Charley did while at AMR to allow for using gforth as the cross-compiler and producing running code on the SiLab 8051.
They call this system MyForth and I have had it available on this site for several years now. The MyForth is a forth based cross-assembler toolset that allows for "tethered" operation of the SiLab boards for both M/S Windows and Linux machines. You don't need to spend more money for cross-compilers and fancy tools to bring these systems on line, just MyForth. Now MyForth uses gforth and thus you will need to load gforth on your system of choice, but it pretty much sits quietly underneath your work and unless you want to do or know more can be forgotten.
However there is one issue that cropped up recently with using gforth - namely the updated verion 7 release. For MyForth to work in tethered mode, it requires proper handshaking of the serial port (USB or plain). We have been using version 6 of gforth for almost ten years now, and so when 7 came out we expected everything to work fine and it does, except for one change. MyForth stopped downloading code to the boards and as I found out, it is due to changes in the lower level coding of gforth wehen talking to the serial device. The code was greatly simplified and the "status" function completely broken. I tried several things, but was unable to get any flag back when data was waiting in the serial buffer.
Since we are using gforth only to run our other programs, the fixes in version 7 really are not needed and using version 6 for now is just fine. I found on the debian site both 6 and 7 deb packages and thus was able to load 6 and use it. The serial interface still work as before on 6 and everything should work as advertised. The download package from here has the rpm and deb packages for gforth 6 included. I do plan to file a bug against the changes, but I believe we might be the only users of this function, so don't expect any changes soon.
To do this learning project, you will need a SiLabs development setup, a running PC system with Linux, but M/S windows will work as well. You can use either real serial ports or USB adapters, but I find that real ports are better and adding a true serial card is less than $30. The real serial ports gives me more confidence that nothing is messing with my data except the code I am running. Using USB devices however leaves you at the point that sometimes your not sure if the problem is your code or the USB driver code. So for me when in doubt use real devices when possible as I did when debugginh the gforth issue. I used two serial ports, one talking to the card, and one monitoring the serial lines to see if data was actually streaming to and from the device.
A quick note, that I normally use mincom for my serial work, however I saw a comment about "cutecom" and tried it. It is gui based tools, but works much better and a few modes that can prove to be "must haves". The save to file option is great, but it is the dump as "hex" mode that I find absolutely necessary for debugging. I need to see and send hex "A5" and "5A", as they are MyForth handshake signals used to setup the download step. Using cutecom I was able to see and simulate the handshake and thus prove it was gforth having the problem.
What you will need from here is the latest version of the MyForth source code tree. This is the "trunk" section of our svn repository with the .svn directories removed. You will find a clean strtucture that has both code, docs, tools, and examples. We will be using the "test120" directory of code. Basically what you do to my this work, is download the tree onto a directory in your home structure. You will do your work in the test120 directory and it will reach back and grab other modules from the tree to run. I set things up to use the gforth search path option and thus some setting are need to define that search path. There are a couple of scripts in the bin directory that do that for you.
We start by editing the small scripts for your setup.
Under Dev....
Till then enjoy!
Links
The SYNET07526-R on-line - see web pages from the netbook.