Microcontrollers are Golden?
February 24, 2017
on
on

Forgive me ye Cortex-M[x] fans but my active dealings with microcontrollers date back to the times when programming these things was exciting but also art for art’s sake. I mean: a few enthusiastic men (sic) would drive say 100 miles to meet in a rundown place to meet up and rejoice over the complexity and abstract beauty of a complex arrangement in an 8-bit system that worked sort-of if you knew all the ropes, handles, and DMA channels. That’s how loose it was — in our CDP1802 user group we were happy to have the software (again sort-of) look after the thing we feared most, the software! HIDs there were none except maybe a pushbutton, a small beeper, and the odd 5-mm LED. Despite the primitive means we had available back in 1985, all of us realized the immense potential of the stuff in our hands. After all, if you can make one LED light under software control, you can launch a rocket. And believe me, one of us actually did “something similar” at CERN — though with a different micro I guess.
At the time there was much hullaballoo and praise for two gifted club members who managed to cram a cold-boot sequence into 256 bytes of static RAM with battery backup from two AA dry cells. You’d launch it, wait for the one LED on the board to light, then play a piece of code from a wacky cassette tape into the ultra-lo-fi audio input of the system. That program “automatically” checked its own integrity and that of the tape data, then unpacked, installed, and configured a 4-Kbyte system monitor, which in turn flashed the LED two times, and then loaded a larger OS from... floppy disk into ... a 48-Kbyte dynamic RAM card. And then TINY BASIC and then beer, and games like Cosmac Space Invaders.
That was a clever feat at economizing on static RAM chips which were quasi unaffordable at the time. I looked into the code at machine level and marveled at its compactness, every byte and clock cycle was tweaked to the max — or should I say to the min — to make it all happen. As you can guess, the program was written directly in opcode (not even assembly language) — and no way any compiler could have pulled this off in 256 bytes nett.
We were poor at practical applications of our systems though and never impressed with any kind of killer application our next-door neighbors would rush off to buy. Best we achieved was traffic lights control packed in 1 Kbyte, all CMOS and stunningly low power and noise resilient.
Today, microcontroller programming is easier and more comfortable. The incredible size of the developer tools, compilers, source code files, debuggers, and data you drag over the net and through your PC may easily amount to 10,000 times that of the object code you hope to burn into your AVR, PIC or ARM micro. But it does not matter as RAM is almost free today and so are the tools. The rest is peanuts for hardware and a few cents in the monthly payment to your internet service provider, and the bill is conveniently shared with your family members. It all makes for a great business case like: code a killer application (not “app”) for the favorite micro.
Which real-life, money-making, money- or time-saving application did you develop with your microcontroller system at home? Only if it was genuinely useful, press the Comment button below and tell everyone about it.
At the time there was much hullaballoo and praise for two gifted club members who managed to cram a cold-boot sequence into 256 bytes of static RAM with battery backup from two AA dry cells. You’d launch it, wait for the one LED on the board to light, then play a piece of code from a wacky cassette tape into the ultra-lo-fi audio input of the system. That program “automatically” checked its own integrity and that of the tape data, then unpacked, installed, and configured a 4-Kbyte system monitor, which in turn flashed the LED two times, and then loaded a larger OS from... floppy disk into ... a 48-Kbyte dynamic RAM card. And then TINY BASIC and then beer, and games like Cosmac Space Invaders.
That was a clever feat at economizing on static RAM chips which were quasi unaffordable at the time. I looked into the code at machine level and marveled at its compactness, every byte and clock cycle was tweaked to the max — or should I say to the min — to make it all happen. As you can guess, the program was written directly in opcode (not even assembly language) — and no way any compiler could have pulled this off in 256 bytes nett.
We were poor at practical applications of our systems though and never impressed with any kind of killer application our next-door neighbors would rush off to buy. Best we achieved was traffic lights control packed in 1 Kbyte, all CMOS and stunningly low power and noise resilient.
Today, microcontroller programming is easier and more comfortable. The incredible size of the developer tools, compilers, source code files, debuggers, and data you drag over the net and through your PC may easily amount to 10,000 times that of the object code you hope to burn into your AVR, PIC or ARM micro. But it does not matter as RAM is almost free today and so are the tools. The rest is peanuts for hardware and a few cents in the monthly payment to your internet service provider, and the bill is conveniently shared with your family members. It all makes for a great business case like: code a killer application (not “app”) for the favorite micro.
Which real-life, money-making, money- or time-saving application did you develop with your microcontroller system at home? Only if it was genuinely useful, press the Comment button below and tell everyone about it.
Read full article
Hide full article
Discussion (16 comments)
JUERGEN PINTASKE 8 years ago
nikolaos chalikias 8 years ago
Was the percentage of usefull stuff higher? and do the real techno-freaks work now with microcontrollers, or with something most of us ignore it? Sometimes I think that the good thing about the microprocessors at the 80s had nothing to do with the technology it self, but us being young. The real qustion might be, how young we "manage" to be today and in what degree we work with electronics in beginers mind state?
JUERGEN PINTASKE 8 years ago
I have started an autorpage for eBooks - mostly about Forth where you know the compiler result rather than very clever solutions. We did a project with the MSP430 - 20 Pin DIL, Forth and start switching LEDs. 3 switches, 5 LEDs a chip and a resistor - connect via USBtoTTL to the PC and start programming, Do sound and control an model RC Servo. Learning starts with the basics. A house needs a strong base, otherwise it gets very wobbely, and you do not know where the holes are....
Roger D Edgecombe 8 years ago
I developed the software to automate much of a recording studio using two Zilog Z80 micros.
One read and recorded the relevant control buttons on a 12 track recording
desk, sampled and recorded the positions of the sliders, and communicated over an RS232 link with the second processor, which controlled the tape decks,
read SMPTE time code, synchronised the tape speeds, handled acceleration and
braking. Each processor ran a separate multitasking system. Since the studio
was owned and run by a blind engineer, one processor also handled speech
output to announce button pushes, relevant events, and could read and
verbalise text from the screen.
Button activity, slider activity and machine control could be replayed to
reproduce a recording session.
Initial development was done on an IMSAI Z80 system. All written in assembler.
Roger Edgecombe
Australia
TheEditor 8 years ago
I still have my full-blown CDP1802 Cosmicos system which was a more refined version of the ELF. Cosmicos was extremely popular in Holland. Mine is 90% CMOS and people just can't believe its low power consumption. I ran Forth too, tiny basic, VIP/VIS, KDOS, etc. all in microscopic memory space by today's standards :-)
A version of the CDP1802 was the first microcontroller system to be rocketed into deep space and still function after decades. Ticks at 1 Hz clock speed.
I used my Cosmicos to design a greenhouse temperature and humidity controller. It's been running for 20 years on end. I wrote an Elektor Retronics article about the CDP1802. That CPU is "golden" because without it I would not have had my job since 1985. Long live the COSMAC!
Jan
Sally Jelfs 8 years ago
program ('diry') for CP/M which worked correctly with all versions including the paged '3+', with sorted output, various views and free space for all user IDs and disk sizes. Written in assembler, I think it took 4K of memory to run and could sort more files than I could throw at it, even with the early 20MB hard drives. It made its way into the CP/M user group library and hopefully helped others work out how to handle system calls, make a quick sort routine, etc, and cover all the bases. Remember, the Z80 could only access 64MB natively, but with RAM prices so high, many were lucky to have 16k to play with. Towards the end, I did extend the paging system introduced by MAP80's 16K memory cards to each hold 256KB memory cards up to a total of 4MB, but by then the IBM 8088 was starting to sweep the world and the rest, as they say, is history. Mike Newson.
bill rowe 8 years ago
https://olduino.wordpress.com/about-2/about/
ROBERT ALEXANDER 8 years ago
Josh Bensadon 8 years ago
M J Bauer 8 years ago
Martin McCarrick 8 years ago
I was in a band and wanted to control our stage lights from my Atari running cubase so I thought I could use the MIDI out interface on the Atari to the MIDI IN of my 8051 circuit, covnert the MIDI data to analog 0-10v for the Triacs.
I used an I/O pin for the MIDI IN (via an opto isolator) and a timer so had to implement MIDI serial interface in code which was the best part, 1 start and 2 stop bits if I remember right, with 8 bits of data in between, having control over this fuctionality excited me as it still does now, I remember having to select the correct crystal freq for the clock of the 8051 to meet the (31K ?) midi speed.
I derived a safe pulse from the mains to sync up to the 8051 via another I/O pin for zero crossing, and then used PWM to eventually drive the 12 Triacs.
I think it was the first ever MIDI to TRIAC interface on the market, Pulsar came out with an interface a year later but id beaten them lol.
I still get that little excited feeling thinking about microcontrollers, and they do so much more now, amazing times :-)
Tom Watson 8 years ago
All of this was before 1980. Much of the development was using the 6800 system itself, I had up to 60k bytes of RAM and it worked quite well.
ronkrem 8 years ago
I was working in Civil Engineering at Monash University as a Tech Officer in the late 70s and one of the post-grads had a project to see if he could count traffic (actually axles) on busy main roads. He had invented a "sensor" that was two strips of galvanised sheet metal placed together with small pieces of sponge glued between to keep them apart. A car axle going over would press the strips together and make contact. His intent was hook up some sort of electrical device to the strips, nail them across a lane in the road and count contacts. He realised that on a busy road this would be impossible manually and so came to me for help.
In those days there were really only chips like the 8080, 6800 or sc/mp around, and because he wanted to leave the thing setup on the side of the road for most of the day, the power supply would have needed a car battery. I had been experimenting with an 1802 for a number of other projects out in the field, and had bought it as a pre-loaded Cosmac board the details of which I cannot remember now, but it must have been directly from RCA. It came with RAM and EEPROM so it was a stand-alone system. In those days obtaining tools such as compilers and assemblers was essentially impossible, so I had written my own 1802 assembler in Data General Basic. The assembler output was an ascii code file and I loaded it into the Cosmac eeprom via the tty interface.
I realised we would need two of his strips mounted fairly close together so we could match axles to a vehicle based on matching speeds. I designed a debouncing interface for the metal strips along with an interface to a small tape data recorder. I wrote the software to monitor for events from the strip and collect them along with a high resolution time signal into a set of circular buffers in the 1802. When one would fill the input would switch to the next. A buffer filling would signal other code to start up the tape recorder and after a number of inputs signalled it was up to speed and ready, the full buffer would be copied to the tape. When done the tape was stopped again ready for the next full buffer signal.
Being all CMOS, the 1802 and its associated electronics required very little current. The main power requirement was for the small tape deck, although it was also designed for this sort of remote data collection, so the whole thing just required a small gel battery to run all day. A few LEDs to indicate what was going on and a sturdy box and off we went to set it up beside a local major road. We had a couple of chairs and sat there for most of the day recording a rough count of vehicles for later cross checking.
I had included a switch that the software would check on bootup to indicate whether the system was recording or playing back. Back in the lab we connected the 1802 tty output to a Data General 800 via a tape reader interface, started a monitor program in the DG and flicked the switch. The monitor program read in each axle event and wrote them to a disc file. I had previously written a program (again in DG Basic) that would read this file and match up axles based on matching consecutive computed speeds.
It all worked very well and was setup over many weeks on many busy roads around Melbourne, with the reports at last providing the sort of data required for detailed traffic flow analysis. The local Road Traffic Authority was immediately interested when presented with some of the detailed results, the analysis methods, and the technology used. The University soon had a couple of their engineers visiting and we successfully transferred that technology over to them. That post-grad went on to become a prominent traffic engineer and I moved on to the next project.
Ron Kreymborg
Guilha 8 years ago
JUERGEN PINTASKE 8 years ago
mort 7 years ago
wire wrapped. I aquired a quest super elf controller.
I learned how to program with the 1802 (all hand
assembled coding) . A fellow I was working with
had a Sol20 system and needed to have some
eproms programmed for running cpm on his sol20.
I cobbled together a eprom programmer from
reading the Intel data book. I burned several
eproms for my coworker. Work was painstakenly
slow on the s100 system . Of course the 1802
served as a test bed for circuit design and for
debugging.