December 04 2009 
Rev on a Chip
How to replace a huge radio receiver with software on a tiny chip
[Editors note] If you have visited our website recently, you'll see that one of the videos on the front door features Charlie Faddis and Prototek Corporation. I recently emailed Charlie to ask if he could tell us a bit more about his operation in a newsletter article, as I knew it would fascinate the readers of revUp as much as it did me, when he explained it to me at RunRevLive in Edinburgh. Below is the result, I hope you find it interesting!
I've just been snowed under with work since this "recession" began. I returned from Edinburgh to find three new clients waiting for me to tackle their software problems. I'm not sure why my business is doing so well while others are shut down. I like to think that is in part due to the fact that Revolution makes me very competitive in the world of engineering.
I can appreciate the C language for what it is. I realize that it's the foundation of Berkley Unix, OSX, the iPhone, and even Rev itself. But when it comes to a frontal attack on a tough problem, C isn't even in the same league with Rev. One of my engineers, a brilliant Berkley graduate with 40 years experience, spent the last six weeks trying to program an 8051 microprocessor with a C compiler. He finally admitted last Wednesday that he just couldn't get it working. I stepped in with Rev and produced a finished and working product in less that twelve hours! My business partner can now sleep through the night again. He was looking a little pale for a while, there.
I've been writing real-time software for over 40 years, and some of the problems that clients bring to me are so complex that I do not trust myself to write the code "by hand". I've come to rely Rev as a power tool for containing complexity. I find it's safer to write a Rev program which, in turn, writes the code for the target machine. I don't know of any other language that I would trust to do that. It has a lot to do with the ASCII data structure combined with revTalk's text handling facilities. It also has a lot to do with the event structure of revTalk. By implementing the same event structure in the target machine I can pass events back and forth through the USB port. I begin by implementing 90% of the task in Rev and 10% in the target machine. As the job progresses I move more and more of the event handlers across the boundary until 100% of them are in the target processor. At that point I unplug the USB and walk away with the solution in hand.
The radio receiver we use in our underground pipe detection system was built using the above process. It fits on an inch square chip, rather than being a radio receiver the size of a large building (this is an ultra, ultra, low frequency receiver with a carrier frequency of only 16 hertz). I realize that the idea of one program writing another program is a bit abstract for some even in the software world. How best to describe the process by which we construct radio receivers from revTalk? There are multiple layers of abstraction. I discussed the issue with my business partner, and he suggested I begin by describing some of the peripheral tools which were required.
I'm in the process of porting those tools over to Rev 4.0 from earlier editions of Rev. I don't wish to publish any scripts that are not vetted. Most problems are easily fixed as they are caused by new reserved words which appear in 4.0. I feel like the name space is closing in around me as Rev evolves! I've taken to adding a dot after my names to prevent collisions.
Naturally, if one is going to construct things like radio receivers an oscilloscope is a necessary tool. Since the receiver is built in software we built a "soft" oscilloscope to view the data in as close to real time as possible. This effort resulted in a general purpose graphing widget which has been endlessly useful to us over the last ten years. It was originally built in SuperCard and then ported to Rev. As I became more familiar with Rev I realized that I could rewrite it, gain more functionality, and end up with a smaller script - about 40% of what was required in SuperCard. You can download this here.
The primary obstacle in porting it from SuperCard was the inability to "paint" text in revTalk. The work-around was to put the text in a transparent field and the art work on an image which resides beneath it. In the end this turned out to be an advantage because, as usual, Rev did all the heavy lifting (love it).
The graphing widget can display up to ten functions in ten different colors, simultaneously. Anyone in the electronics field will recognize the colors as the standard resistor codes...
http://en.wikipedia.org/wiki/Electronic_color_code
The data is passed to the graphing widget by setting custom properties. That data itself is a list of "ordered pairs" of real numbers each on a separate line. . .
1.0, 2.10
1.1, 2.45
•
•
•
80.7, 4.56
If it is to be graphed in blue then. . .
SET THE BLU OF FIELD <field name> TO <container>; SEND REDRAW TO FIELD <field name>;
Four other custom properties control the origin and scale. . . xOrg, yOrg, xGrid, & yGrid.
The paint image is automatically given the unique name of CANVAS<nnnn> where <nnnn> is the i.d. of the field. Thus, multiple graphing widgets will not result in naming conflicts.
During the conference Kevin asked me to describe Rev in three words. I was at a loss for words at the time, but later the the phrase Integrated Development Environment came to mind. Much of the power in Rev is derived from the multiplicative effect of the revTalk language combined with the IDE. I have trouble imagining how I would use this kind of graphing widget in the objective-C or C++ environment. In Rev I can move the data between my hardware and the graphing widget in real time via the serial port and still have the complete set of editing tools at my disposal. So the answer to Kevin's question is I-D-E. It's more than just a catch phrase. It's what does the heavy lifting.
 |
|
