During my Silicon Valley Sabbatical
Key words: Volunteer, 80188, Embedded System, Manufacturing Process Automation
In between the process of sending resumes and even occasionally seeing
headhunters face to face I have been keeping busy. I volunteer helping
kindergarten students use the school’s computer lab. Because I turn
the computers on and start the program they are use the students avoid the
confusion in finding and starting programs. Yet many kindergarten students
can do that if everything is working. But always something makes a
problem. Such a problem with even one student delays the entire class.
After they all get started I watch for raised hands. Their teacher’s
policy is to only give help to those who quietly raise hands. (Good for
her!)
I have tried to volunteer at Santa Clara High School. Apparently my offer to
teach a little C programming is not something needed at the high school
level.
It's a new school year and I have yet to do any formal volunteer work.
Water Tank Tester
The basic idea here was an end of assembly line test for those water dispensers
that use an inverted 5-gallon water bottle in top. The question to be
answered was, “Does it leak?” The test methodology was simple – fill it
with air. If air does not leak then it won’t leak water either.
A friend who worked with me at Quantum was working at ProStar Technology.
(http://www.enetstars.com) He told
me about this tester product they had contracted to build. I got a quick
explanation on a white board and off the cuff provided a way of thinking about
the pneumatic valves in that system. “Don’t think of the separate valves
as anything special,” I said. “Instead always think of the state of each
of the systems controlled by those valves.” One of these systems used two
valves. That part of the system had three states: fill, hold and vent.
Let the mainline program select a state and let the state set the valves.
I should have suspected that when he bought me lunch I would be offered a
contract to do the whole thing. “How much,” he asked, “to do the whole
thing?” I thought it would be fairly simple and said $2000 for a
useable system. This was more than anticipated but was accepted by the
owner. When I found out that editing control sequences was also needed
(but not part of a useable system) I said, “okay, Rick you can do this
feature.” I got an extra $1500 to edit control sequences as well.
The entire $3500 was paid upon customer acceptance but my efforts ended up
paying me just under $10/hour.
I dug up a multitasking operating system I had written some years prior and
modified it to be callable from C code. I ended up with 4 tasks.
Although I implemented a wait for event, that OS feature was never used.
Every task relinquished control for some number of milliseconds.
I simplified all the I/O in that system. To turn on an LED all one had to
do was write a few control bytes into RAM. My 1KHz ISR checked those bytes
and made the LED do what was requested. These control bytes had a way of
flashing LEDs at any desired number of milliseconds. Turning it on for 6
of every 14 milliseconds dimmed the display backlight. The setting of the
control structure was done in some easy to call C code.
I managed a 20-key keypad. The 1KHz interrupt posted the current state of
each switch every millisecond. A task written in C ran every millisecond
to decode all this into key press and key release events. These key events
were serialized and made available for the rest of the system to decode as
required.
I managed a 20-character by 4-line display. For the most part “ProStar
Technology” displayed on the first line. Every millisecond I updated the
next character from my display buffer RAM into the display. Thus the
display was at most 80 milliseconds behind the display buffer RAM.
I managed a three-position test selection switch. I also managed a start button
and a big red abort button. As expected “start” started a test. The
abort button killed the test and let compressed air out of the system safely.
I managed an EEPROM. I would have used the CPU board vendor’s EEPROM code
except that I wanted to do all I/O in my 1KHz ISR and the vendor’s code took 5
milliseconds to write a byte in the EEPROM. So…I disassembled the vendor’s
code and compared it to the documentation for the particular part they were
controlling. Bottom line: I was able to read or write two bytes at a time
in my ISR although when writing I had to wait 5 or 6 milliseconds before trying
to access the EEPROM again.
My EEPROM update method was entirely a background process. Whenever code
modified the RAM image of the EEPROM that code also set a timer.
Additional writes set the timer again. When things settled down the timer
would expire. Then I read the EEPROM two bytes at a time. If those
two bytes matched the RAM image I went on to the next two bytes. If they
did not match I wrote both bytes. In typical operation this scan took only a
second or two because very few bytes were ever updated.
I wrote every line of code in that system except a few standard C library
routines.
Self Directed Learning - Z8
I bought a $40 Z8 development kit at one of the Embedded Systems Conferences in
San Francisco. The Z8 Encore kit came with a C compiler, an assembler and
the usual goodies to build simple firmware applications. Thinking I might
do something with a simpler Z8 I bought Zilog's 8-pin version the next year.
I had hoped to do a stepper motor controller and put together an integer square
root routine needed for acceleration ramps. Then I looked hard at the
pinout. I would need at least 3 pins for motor control and two pins for a
stable clock. Power and ground take two and one pin for host communication
simply was not enough.
But if anyone needs Z8 expertise please contact me.
Self Directed Learning - ARM
One of my mental projects is to build a TRUE random number generator (TRNG.)
It would provide 8 to 10K bytes per second over a USB connection. I toyed
with PIC, Z8 and then ARM. ARM was particularly nice because the Keil
tools are free for small non-commercial applications. At least I could
learn ARM. http://www.keil.com/ has
recommended reading material and bought the "ARM ARM." To my mind there is
something very useful in dead tree documentation.
With the Keil tools I was able to write my computationally efficient hash for my
TRNG. I was also able to look around for an ARM processor with USB, at least one
analog port and at least 16K each internal RAM and ROM. ST had one but its
analog conversion speed was to slow.
For ARM assembly language practice I wrote a Twofish encryption subroutine.
(Twofish was one of the 5 AES finalists.)
Perhaps it was because I left my card with an Oki rep at the Embedded System
Conference in SF that I got an invitation to an Oki / IAR demo. At this
demo I spent $199 for an ARM development kit. (At that price it will only
generate 16K code. It’s a pre sales offer. “Get to love us for
almost no money and you will be back later with several thousand dollars.”)
As I write this I have found two bugs in IAR’s code. (1) Their simulator
set System rather than Supervisor state for an SWI (Software Interrupt)
instruction. (2) Their C compiler inline assembler and their assembler
both fail to recognize the CLZ (Count Leading Zeros) instruction. Yet with
a real ARM processor and coding the CLZ in hex I can get it all to work.
Live a little; learn a little. It turned out that the CLZ was properly
flagged an an error. In error I though that the 7 in ARM TDMI7 was 2
levels beyond ARM V5. TDMI7 is ARM V4. The CLZ instruction was
created in V5. (The Simulator bug was fixed in a later version of the IAR
tools.)
My TRUE Random Number Generator is not going to happen. Some FEW people
would buy such a device at $89.95. And some fewer of those would be
willing to pay $250 or more. If I had samples ready to go I could probably
sell a few. But I don’t see enough of a market to cover packaging startup
costs let alone something to pay me for my time. But hey, you want such a
device, please do not hesitate to contact me. With care its bill of
materials could be a little under $20.
Life goes on. I now have a PIC-based TRUE Random Number Generator.
As I write this it's not quite ready for prime time but start reading
here for background. The
following page contains details and a link to the current documentation.
Shifting to Another ARM Topic...
Years ago I was asked about how I would modify my 100% non-preemptive 8085
multi-tasking OS into one that was preemptive. At the time all I could say
was that what I had worked well and I had no need for task preemption. And
I know I did not answer the question.
So why not write a preemptive multitasking OS for ARM?
The rhetorical question has a good answer. Multiple OSs already exist for
ARM. Therefore I am unlikely to find a market for my work. And these
OSs already have drivers and protocol stacks etc which takes anything I might be
able to do well out of contention for getting paid for my efforts.
My ARM OS efforts are aimed at the tutorial value of writing a preemptive
multitasking OS. As I write this I have my SWI handler written and working
and the basic task scheduling in my head. I have my mutex code working but
needing to interface with task scheduling. Once my mutex code works with
CPU scheduling doing semaphores will be a piece of cake. I have gobs of
FIFO queue experience from my CDC 6000 days but need to learn how queues are
normally presented in an RTOS.
My startup procedure creates tasks. After at least one task is created from
main() a call to osrun() starts the scheduler.
At this point I am using C++ objects for mutex, semaphore, queue and whatever
else I need. I am exploring deriving these from a basic OS wait for event object
but I don’t want to make my underlying assembly code dependant on C++. I
suspect I will include a common struct in my scheduling objects. And C
code will need an explicit parameter to the object.
This OS development is already serving its purpose in keeping my mind
technically alert while I am between jobs.
Back