For instance a PIC10F200T
Virtually any code you write will be larger than that, unless it is a single purpose chip. Is there any way to load more program memory from external storage or something? I'm just curious, I don't see how this could be very useful... but it must be.
You kids, get off my lawn!
384 bytes is plenty of space to create something quite complex in assembler.
If you dig back through history to when computers were the size of a room, you'll find some truly amazing feats of artistry executed in <1k.
For instance, read the classic Story of Mel - A Real Programmer. Admittedly, those guys had 4096 words of memory to play with, the decadent infidels.
Also look at some of the old demoscene competitions where the challenge was to fit an "intro" into the bootblock of a floppy, typical targets being 4k or 40k and usually managing to include music and animation.
Edit to add: Turns out you can implement the world's first $100 scientific calculator in 320 words.
Edit for the young 'uns:
Microcontrollers are sufficiently cheap that they are often used to do really simple things that in years past would more likely have been done with discrete logic. Really simple things. For example, one might want a device to turn on an output for one second every five seconds, more precisely than a 555 timer would be able to do.
movwf OSCCON
mainLp:
; Set output low
clrf GPIO
movlw 0xFE
movwf TRIS
clrwdt
call Wait1Sec
clrwdt
call Wait1Sec
clrwdt
call Wait1Sec
clrwdt
call Wait1Sec
; Set output high
bsf GPIO,0
clrwdt
call Wait1Sec
goto mainLp
Wait1Sec:
movlw 6
movwf count2
movlw 23
movwf count1
movlw 17
movwf count0
waitLp:
decfsz count0
goto waitLp
decfsz count1
goto waitLp
decfsz count2
goto waitLp
retlw 0
That would be a real, usable, application, in less than 32 words (48 bytes) of code space. One could easily add a few options to have some I/O pins control timing options and still have lots of room to spare, but even if all the chip did was precisely what's shown above it might still be cheaper and easier than any alternative using discrete logic. BTW, the clrwdt instructions could be moved into the subroutine, but doing so would make things less robust. As written, even if a glitch causes the return-address stack to get corrupted, the watchdog won't get fed until execution returns to the main loop. If that never happens, the watchdog will reset the chip after a couple seconds.
clrwdt instructions. This isn't the most absolutely-failsafe counter arrangement possible, but some consideration is given to safety issues (e.g. the avoidance of clrwdt within a subroutine).
\$\endgroup\$
"ONLY" 384 bytes?
Way back in the day, I had the job of writing an entire operating system (by myself) for a specialized computer that served the ship, pipeline, and refinery management industry. The company's first such product was 6800 based and was being upgraded to 6809, and they wanted a new OS to go along with the 6809 so they could eliminate the license costs of the original operating system. They also were bumping up the boot rom's size to 64 bytes, up from 32. If I recall correctly - it WAS about 33 years ago! - I convinced the engineers to give me 128 bytes so I could put the whole operating system's device drivers on the rom and thus make the whole device more reliable and versatile. This included:
Yes, all of these were as bare-bones as it gets, and hand-optimized to remove every extraneous cycle, but perfectly serviceable and reliable. Yes, I shoehorned all of that into the available bytes - oh, it ALSO set up interrupt handling, the various stacks, and initialized the real-time / multi-tasking operating system, prompted the user on boot options, and booted the system.
A friend of mine who's still affiliated with the company (its successor) told me a few years ago that my code is still in service!
You can do a LOT with 384 bytes...
You can use this for very small applications (e.g. delayed PSU start, 555 timer replacement, triac-based control, LED blinking etc...) with smaller footprint than you'd need with logic gates or a 555 timer.
One thing that I haven't seen mentioned: The microcontroller you mentioned is only $0.34 each in quantities of 100. So for cheap, mass-produced products, it can make sense to go to the extra coding trouble imposed by such a limited unit. The same might apply to size or power consumption.
I designed a humidity sensor for plants that tracks the amount of water the plant has and blinks an LED if the plant needs water. You can make the sensor learn the type of plant and thus change its settings while running. It detects low voltage on the battery. I ran out of flash and ram but was able to write everything in C code to make this product work flawlessly.
I used the pic10f that you mention.
Here is the code I made for my Plant Water Sensor. I used the pic10f220 since it has an ADC module, it has the same memory as the pic10f200, I'll try to find the Schematic tomorrow.
The code is in spanish, but its very simple and should be easily understood. When the Pic10F wakes from sleep mode, it will reset so you have to check if it was a PowerUp or a reset and act accordingly. The plant setting is kept in ram since it never really powers down.
MAIN.C
/*
Author: woziX (AML)
Feel free to use the code as you wish.
*/
#include "main.h"
void main(void)
{
unsigned char Humedad_Ref;
unsigned char Ciclos;
unsigned char Bateria_Baja;
unsigned char Humedad_Ref_Bkp;
OSCCAL &= 0xfe; //Solo borramos el primer bit
WDT_POST64(); //1s
ADCON0 = 0b01000000;
LEDOFF();
TRIS_LEDOFF();
for(;;)
{
//Se checa si es la primera vez que arranca
if(FIRST_RUN())
{
Ciclos = 0;
Humedad_Ref = 0;
Bateria_Baja = 0;
}
//Checamos el nivel de la bateria cuando arranca por primera vez y cada 255 ciclos.
if(Ciclos == 0)
{
if(Bateria_Baja)
{
Bateria_Baja--;
Blink(2);
WDT_POST128();
SLEEP();
}
if(BateriaBaja())
{
Bateria_Baja = 100; //Vamos a parpadear doble por 100 ciclos de 2 segundos
SLEEP();
}
Ciclos = 255;
}
//Checamos si el boton esta picado
if(Boton_Picado)
{
WDT_POST128();
CLRWDT();
TRIS_LEDON();
LEDON();
__delay_ms(1000);
TRIS_ADOFF();
Humedad_Ref = Humedad();
Humedad_Ref_Bkp = Humedad_Ref;
}
//Checamos si esta calibrado. Esta calibrado si Humedad_Ref es mayor a cero
if( (!Humedad_Ref) || (Humedad_Ref != Humedad_Ref_Bkp) )
{
//No esta calibrado, hacer blink y dormir
Blink(3);
SLEEP();
}
//Checamos que Humedad_Ref sea mayor o igual a 4 antes de restarle
if(Humedad_Ref <= (255 - Offset_Muy_Seca))
{
if(Humedad() > (Humedad_Ref + Offset_Muy_Seca)) //planta casi seca
{
Blink(1);
WDT_POST32();
SLEEP();
}
}
if(Humedad() >= (Humedad_Ref)) //planta seca
{
Blink(1);
WDT_POST64();
SLEEP();
}
if(Humedad_Ref >= Offset_Casi_Seca )
{
//Si Humedad_Ref es menor a Humedad, entonces la tierra esta seca.
if(Humedad() > (Humedad_Ref - Offset_Casi_Seca)) //Planta muy seca
{
Blink(1);
WDT_POST128();
SLEEP();
}
}
SLEEP();
}
}
unsigned char Humedad (void)
{
LEDOFF();
TRIS_ADON();
ADON();
ADCON0_CH0_ADON();
__delay_us(12);
GO_nDONE = 1;
while(GO_nDONE);
TRIS_ADOFF();
ADCON0_CH0_ADOFF();
return ADRES;
}
//Regresa 1 si la bateria esta baja (fijado por el define LOWBAT)
//Regresa 0 si la bateria no esta baja
unsigned char BateriaBaja (void)
{
LEDON();
TRIS_ADLEDON();
ADON();
ADCON0_ABSREF_ADON();
__delay_us(150); //Delay largo para que se baje el voltaje de la bateria
GO_nDONE = 1;
while(GO_nDONE);
TRIS_ADOFF();
LEDOFF();
ADCON0_ABSREF_ADOFF();
return (ADRES > LOWBAT ? 1 : 0);
}
void Blink(unsigned char veces)
{
while(veces)
{
veces--;
WDT_POST64();
TRIS_LEDON();
CLRWDT();
LEDON();
__delay_ms(18);
LEDOFF();
TRIS_ADOFF();
if(veces)__delay_ms(320);
}
}
MAIN.H
/*
Author: woziX (AML)
Feel free to use the code as you wish.
*/
#ifndef MAIN_H
#define MAIN_H
#include <htc.h>
#include <pic.h>
__CONFIG (MCPU_OFF & WDTE_ON & CP_OFF & MCLRE_OFF & IOSCFS_4MHZ );
#define _XTAL_FREQ 4000000
#define TRIS_ADON() TRIS = 0b1101
#define TRIS_ADOFF() TRIS = 0b1111
#define TRIS_LEDON() TRIS = 0b1011
#define TRIS_LEDOFF() TRIS = 0b1111
#define TRIS_ADLEDON() TRIS = 0b1001
#define ADCON0_CH0_ADON() ADCON0 = 0b01000001; // Canal 0 sin ADON
#define ADCON0_CH0_ADOFF() ADCON0 = 0b01000000; // Canal 0 con adON
#define ADCON0_ABSREF_ADOFF() ADCON0 = 0b01001100; //Referencia interna absoluta sin ADON
#define ADCON0_ABSREF_ADON() ADCON0 = 0b01001101; //referencia interna absoluta con ADON
//Llamar a WDT_POST() tambien cambia las otras configuracion de OPTION
#define WDT_POST1() OPTION = 0b11001000
#define WDT_POST2() OPTION = 0b11001001
#define WDT_POST4() OPTION = 0b11001010
#define WDT_POST8() OPTION = 0b11001011
#define WDT_POST16() OPTION = 0b11001100
#define WDT_POST32() OPTION = 0b11001101
#define WDT_POST64() OPTION = 0b11001110
#define WDT_POST128() OPTION = 0b11001111
#define Boton_Picado !GP3
#define FIRST_RUN() (STATUS & 0x10) //Solo tomamos el bit TO
//Offsets
#define Offset_Casi_Seca 5
#define Offset_Muy_Seca 5
//Low Bat Threshold
#define LOWBAT 73
/*
Los siguientes valores son aproximados
LOWBAT VDD
50 3.07
51 3.01
52 2.95
53 2.90
54 2.84
55 2.79
56 2.74
57 2.69
58 2.65
59 2.60
60 2.56
61 2.52
62 2.48
63 2.44
64 2.40
65 2.36
66 2.33
67 2.29
68 2.26
69 2.23
70 2.19
71 2.16
72 2.13
73 2.10
74 2.08
75 2.05
76 2.02
77 1.99
78 1.97
*/
#define LEDON() GP2 = 0; //GPIO = GPIO & 0b1011
#define LEDOFF() GP2 = 1; //GPIO = GPIO | 0b0100
#define ADON() GP1 = 0; //GPIO = GPIO & 0b1101
#define ADOFF() GP1 = 1; //GPIO = GPIO | 0b0010
unsigned char Humedad (void);
unsigned char BateriaBaja (void);
void Delay_Parpadeo(void);
void Blink(unsigned char veces);
#endif
Let me know if you have questions, I'll try to answer based on what I remember. I coded this several years ago so don't check my coding skills, they have improved :).
Final Note. I used the Hi-Tech C compiler.
When I was in high school, I had a teacher that insisted that light dimming was too difficult a task for a student such as I to tackle.
Thus challenged I spent quite a bit of time learning and understanding phase based light dimming using triacs, and programming the 16C84 from microchip to perform this feat. I ended up with this assembly code:
'Timing info:
'There are 120 half-cycles in a 60Hz AC waveform
'We want to be able to trigger a triac at any of 256
'points inside each half-cycle. So:
'1 Half cycle takes 8 1/3 mS
'1/256 of one half cycle takes about 32.6uS
'The Pause function here waits (34 * 0xD)uS, plus 3uS overhead
'Overhead includes CALL PAUSE.
'This was originally assembled using Parallax's "8051 style"
'assembler, and was not optimized any further. I suppose
'it could be modified to be closer to 32 or 33uS, but it is
'sufficient for my testing purposes.
list 16c84
movlw 0xFD '11111101
tris 0x5 'Port A
movlw 0xFF '11111111
tris 0x6 'Port B
WaitLow: 'Wait for zero-crossing start
btfss 0x5,0x0 'Port A, Bit 1
goto WaitLow 'If high, goto WaitLow
WaitHigh: 'Wait for end of Zero Crossing
btfsc 0x5,0x0 'Port A, Bit 1
goto WaitHigh 'If low, goto waitHigh
call Pause 'Wait for 0xD * 34 + 3 uS
bcf 0x5,0x1 'Put Low on port A, Bit 1
movlw 0x3 'Put 3 into W
movwf 0xD 'Put W into 0xD
call Pause 'Call Pause, 105 uS
bsf 0x5,0x1 'Put High on Port A, Bit 1
decf 0xE 'Decrement E
movf 0x6,W 'Copy Port B to W
movwf 0xD 'Copy W to 0xD
goto Start 'Wait for zero Crossing
Pause: 'This pauses for 0xD * 34 + 3 Micro Seconds
'Our goal is approx. 32 uS per 0xD
'But this is close enough for testing
movlw 0xA 'Move 10 to W
movwf 0xC 'Move W to 0xC
Label1:
decfsz 0xC 'Decrement C
goto Label1 'If C is not zero, goto Label1
decfsz 0xD 'Decrement D
goto Pause 'If D is not zero, goto Pause
return 'Return
Of course you'd need to modify this for the chip you mention, and maybe add a cheap serial routine for input since your chip doesn't have an 8 bit wide port to listen to, but the idea is that a seemingly complex job can be done in very little code - you can fit ten copies of the above program into the 10F200.
You can find more project information on my Light Dimming page. Incidentally I never did show this to my teacher, but did end up doing a number of lighting rigs for my DJ friend.
Well, years ago I wrote a temperature controller with serial I/O (bit-banging the serial I/O because the MCU didn't have a UART) and a simple command interpreter to talk to the controller. MCU was a Motorola (now Freescale) MC68HC705K1 which had a whopping 504 bytes of program memory (OTPROM) and about 32 bytes of RAM. Not as little as the PIC you reference, but I remember having some ROM left over. I still have a few assembled units left, 17 years later; wanna buy one?
So yeah, it can be done, at least in assembly.
In any case, I've written very simple C programs recently that would probably have fit inside 384 bytes when optimized. Not everything requires large, complex software.
You can write a blink a LED with 384 bytes program memory, and even more.
As far as I know, it is not possible to extend the program memory with an external chip (unless you're building a full ASM interpreter in the 384 bytes, which would be slow). It is possible to extend data memory with an external chip (EEPROM, SRAM) though.
It's actually worse than you think. Your linked Mouser page is confusing matters when it specifies this processor as having 384 bytes of program memory. The PIC10F200 actually has 256 12-bit words of program memory.
So, what can you do with that? The 12-bit PIC instruction set used by the PIC10F20x devices are all single-word instructions, so after you subtract a few instructions for processor setup, you're left with enough space for a program of about 250 steps. That's enough for a lot of applications. I could probably write a washing machine controller in that kind of space, for example.
I just looked over the available PIC C compilers, and it looks like about half of them won't even try to emit code for a PIC10F200. Those that do probably put out so much boilerplate code that you might only be able to write an LED flasher in the space left. You really want to use assembly language with such a processor.
waving my cane in my day, we had to etch our own bits out of sand!
In 1976 (or thereabouts) the Atari 2600 VCS system was one of the most popular "video game platforms" of the time. In it, the microprocessor (MOSTEK 6507) ran at a blazing ~1 MHz and had ****128 bytes of RAM**.
A second example that I recall of a microcontroller with extremely limited RAM (~128 bytes) was a PIC12F used on a DC-DC converter. This micro also had to use assembly language in order to run at all.
