TV card output

The output to the TV from the PIC microcontroller is a very simple circuit. For the audio, it is merely a 0.47uF capacitor, to avoid DC current bias. For the video, it is two resistors. The actual values should be 450 Ohm and 900 Ohm, but 1k Ohm and 470 Ohm are close enough, and work really well. These are used to generate the appropriate voltages (low threshold, black, white and gray). Gray could be used for two levels of output, but due to the speed limitations of the microcontroller this state is not used. Basically the 1k Ohm pin is used the generate the threshold voltages for syncing, and the 470 Ohm pin is used to generate the actual black and white values in the output. The circuit assumes the TV has an internal resistance of 50-75 Ohm, which is generally the case, to generate 0V, 0.4V and 1.2V levels.

This is a copy of the text on the other website, to ensure that it is preserved in case it goes down.

Version 0.1

Version 2, with its old-style joystick interface, desparately needed a TV interface as well. I therefore started working on this. After some experimenting with an old television, I discovered that at 20 MHz it is quite possible to get 14 characters on one line without any real problems. You can also get quite a few characters vertically, but memory of a 16F628 is limited, so I decided on 10 characters, making a grand total of 140 characters. The memory is set to two segments, one starting from A0-F4, the other from 20-58. Each byte represents one character. If the top bit is set, it is assumed to be a regular ASCII character (see picture for the entire set).

Version 0.2

If the top bit is not set, it is assumed to be a user defined character, and retrieved from the local EEPROM. A next version will implement a three-byte code that can be sent over RS-232 in order to change memory and EEPROM locations.

Version 0.3

I then continued developing the "low resolution graphics option" which allows a
screen of 56*20 pixels, shown in the picture. This can be configured per line, so you can have one line of text, and 56*18 pixels, if desired. I originally planned on also have a line-by-line configurable 28*40 resolution, but am probably going to make that a global setting.

Currently I'm working more on the RS-232 interface, which understands the following commands:

Sequence Effect
0 1 2 Sync sequence. Send this if you're not certain if the chip is in sync with its RS-232 communication.
128 A0+14*Y+X V Prints character V at location X,Y. This works for lines 0-5. To print an ASCII character, set bit 7 of V. To print a user defined character, reset bits 0, 1, 2 and 7. This leaves a choice of 16 user defined characters. You can "scroll" through the user defined graphics by changing the lower three bits.
128 20+14*Y+X V See above, for lines 6-9.
128 106/107 V Defines which lines will be text, and which lines will be 56*20 graphics. The bits of 106 define the first eight lines, the lower two bits of 107 define lines 9 and 10. A 0 means text, a 1 means graphics. V is the value assigned.
129 Y*8+X V Defines a user defined character. Y (0-15) defines which user defined character is changed, X (0-7) defines which line in the user defined character is changed. V is the value assigned. Changing a user defined character takes time: do not send multiple changes in rapid succession or some changes might be lost.
130 .. .. Similar to commands starting with 128, but instead the value is XORed instead of assigned. Sending this sequence twice would result in no change.
132 255 0 Set speed to 1200 bits/second.
132 129 0 Set speed to 2400 bits/second (default).
132 129 1 Set speed to 9600 bits/second.
132 64 1 Set speed to 19200 bits/second.
132 32 1 Set speed to 38400 bits/second.
132 21 1 Set speed to 57600 bits/second.
132 3 0 Set speed to 76800 bits/second. This exceeds the maximum processing speed of the device. Do not send data continuously.
132 10 1 Set speed to 115200 bits/second (not continuous).
132 4 1 Set speed to 250000 bits/second (not continuous).
132 0 0 Set speed to 312500 bits/second (not continuous).
132 1 1 Set speed to 625000 bits/second (not continuous).
132 0 1 Set speed to 1250000 bits/second (not continuous).
132 111 4 Odd times: disables fake interlace (makes screen more stable, but makes dark lines inside letters visible), even times: enable fake interlace.
128 126 V 130 111 8 Change all locations on the screen to V. This can be used as a clear screen (with 0xA0 in text mode and 0x00 in graphics mode). V needs to be set only once, and defaults to 0xA0.
128 121 L 128 122 H 130 111 1 Play a musical note through the television. L,H=65536-(15660/frequency). To turn the note off, send 132 111 1 again.
Version 1
TV I built the first daughterboard version (see picture) and discovered that the bytecode is way to slow to even send a continuous 2400 bits/second data stream, let alone higher bit rates. I therefore decided to code some of the commands in bytecode (in fact adding a "TV mode") which worked well, until I tried higher speeds. It turned out I didn't call HandleRS232 often enough, and had to change that. It can now run at 9600 bits/second, and tonight I'll start trying higher speeds. Hopefully I'll get the 57600 bits/second that I promised myself earlier on this page. And yes, the system works also without the LCD display, and only the TV daughterboard connected.

TV Game Update: the speed is now up to 78600 bits/second continuous, where it belongs. To the left you can see a picture of a conversion of the "Version 1" meteor game to TV. The space ship has pixel level (two TV line level) up and down movement, and the meteors are moving quite fast compared to its speed. This is still in the beginning stages, but development goes quite well.

Version 1.01

Version 1.01 now has the Drake v2.0 logo when it boots. I also modified the output not to be on cables, but on the PCB itself. A good picture of the board is now available on this page as well. The final version of this system will be on a smaller board, but will still have three outputs (though it is still mono: the two sound outputs are provided with the same stream). TV Card

Version 1.02

Here is a picture of the current font of the TV card. It includes the suits of cards, a ball, an overscore, a solid block and a grayed block, four triangles in four corners and a number of digraphs (and ...) which allow more characters to be squeezed on a line, improving the amount of text that can be displayed on one line.

Version 1.03

To show how the digraphs help in increasing the number of characters per line, you can see a text in the picture on the right. The content is a Dutch song which has been roughly translated into English. As you can see, the digraphs allow a lot more characters per line than would normally be possible. This is version 1.03 because the digraphs are different from the ones in version 1.02. As you can see, the largest number of characters on one line in this example is 21, which is 50% more than the normal 14. The only line with less than 14 characters is "first had", this line still has six regular spaces left. The average line length is 16.6 characters, almost a 20% increase.

Version 1.04

This is the first picture of the version using the 16F628A. The 16F628A has the unfortunate aspect that disallows reading from the EEPROM while it is being written to (the 16F628 had no problems with that). I'm still working on making tbhe meteor pattern more random, which is more difficult than it seems. The random generator might need more work. I'm also working on porting the application to the 16F688. This will increase the amount of user defined characters to 32, and the number of characters in the character set to 256. However, it will disallow user defined characters and regular characters to appear on the same line.
Purchasing
If people are interested in buying this TV card, which can easily be used in other Microcontroller/PC projects, I would be welcome to send it to you. It can be configured to your desires, will come unassembled with a preprogrammed PIC16F628A, and will be $10 excluding shipping. Features:

* 14*10 character resolution
* 56*20 graphics mode, selectable on a per line basis
* 16 user definable characters, can be combined on a pixel line basis
* Communication speed up to 250000 bits/second (3 bytes/charater)
* 1 voice audio with frequencies up to 15660 Hz
* Fast clear screen operation
* Special character set with digraphs for an average of 18 letters/line

Drake TV daughterboard

The Drake TV daughterboard is a very simple circuit, based around the PIC16F628A, although I made a version using the PIC16F688 as well. The board uses a composite video and RCA audio output, has the usual 78L05 power regulator and uses a 9-pin sub D connector to hook up to the old Drake motherboards, which will be described at another time. The daughterboard accepts specially coded input of characters, and outputs them as a signal to the TV, also handling audio.

The choice for a PIC16F628A was very deliberate, and the resulting code ONLY runs on this device. A larger memory actually causes the timing to go off, and such a device would actually have less functionality (which is the case for the PIC16F688). 18F devices could of course perform similarly, but they would be more expensive. With the current circuit you can output TV from your product for less than $2.

Old drakes

Note that the old drakes are still available. I will undoubtedly republish that content here, but I wanted to make sure the link was posted as well.

Calculator software

No diagram of how the PIC16F877A was actually connected: the only special things were the ceramic resonator that I used to keep it at a specific frequency (the PIC16F877A unfortunately does not have an internal clock) and the diode that I used to share pins with the ICSP circuitry.

This article concerns the code for the calculator I built.
By now a lot of features of my code should be recognizable. The initialization of the system is generally the same, both of the LCD display as well as the rest of the system. The code starts defining icons used on the display: the HD44780 allows user definable characters, and here they are defined and read. Then there is the keymap, which maps the scanlines of the keyboard to actual values. After initialization, the following steps happen:

1. Day and month are read by sending their locations in the DS1302 and calling TIMERead which retrieves that value.
2. In the birthday loop ROMretrieveword is used to retrieve the next birthday, which is then compared with the current date to see if the name associated with this birthday should be displayed.
3. After this done it waits for a random key to be pressed, indicating that the birthdays have been viewed. After this the birthdays are not displayed until the calculator is turned off and on again.
4. At this point it reaches the MainLoop where the menu is displayed and the user can use a key to select an item from the menu. The menu has groups of 3, representing the lines on the keypad. This interface has failed in all my user tests, but it works for me. You might want to find a better organization, though. The menu options are 1 to display the time, 2 to set the time, 3 to use the calculator and 4 to use the address book.

The addressbook starts at MainContacts:
1. The LCD display is cleared.
2. ROMretrieveword is used to skip the birthday.
3. If this was the last contact, go back to the main menu.
4. Display the first line of the contact (which is the name).
5. Wait for a key press.
6. If it is 2, skip the next parts of the address and continue at 2.
7. Show rest of address and return to main menu.

The calculator starts at MainCalculator. The menu works the same as the main menu. Some of the keys on the keyboard (backspace, +, +/- and =) have short cuts. At any point # can be used to access a menu with additional features. The most remarkable aspect of the calculator is the method of storage: the numbers are stored as they would be displayed, in the decimal system. All calculations are done using the decimal system as well, using the mechanisms that are taught to children. Not efficient in either memory and space, but quite readable and very easy to convert between keyboard input and display, which was my biggest concern.

A few other routines that require mentioning are the keypad read routine, which always checks for *. If * is pressed, the system jumps to the main menu, regardless of what state it is in. This is a very useful shortcut for the user, but is a good example of how code should not be written. Another aspect of the keypad that is interesting is how it debounces. The other interesting aspect is the way data is stored. The data is not stored in an external memory, like with the GPS system, but
uses the main memory of the PIC16F877A. It has 8K of 14 bit wide memory, and using clever tricks we can store 12K of address data and birthdays in this memory. I wrote a separate JAVA program to cover this address compression.

Keeping time and date

Keeping time and date is relatively simple if one uses an external component. It is in principle possible to use the PIC microcontroller itself, moving it into sleep mode, giving it a 32.768 kHz crystal, et cetera. However, the head aches are not worth it if you have the space for a 8 pin DIP, like the DS1302. The DS1307 is another option if you wish to use I2C. This circuit was meant for my calculator, mostly to keep the date so it would tell me of birthdays that I might otherwise miss.

Connecting a DS1302 is pretty simple: just connect the 3 wires to the PIC microcontroller, connect the X1 and X2 to an appropriate crystal (these crystals have very small pins, so if a socket is used for the DS1302, something I would recommend, you can add the crystal to the same socket, and not solder it) and connect the power. Do not forget the 0.1uF decoupling capacitor, although in this case it might be less important, because the DS1302 is supposed to work using a backup battery. The DS1302 can charge this backup battery, so the ideal choice is a super capacitor. The value in the circuit is no joke, I used a 1F capacitor for this purpose. They are slightly bigger than a watch battery and can NOT handle voltages larger than 5V. However, most of the time it will not charge over 2V, which is still sufficient for the DS1302 to work. It has never lost time in my application, even with the power being off for weeks. The hardest part of the DS1302 is the software, but fortunately you can just copy the pieces of code that I wrote.

Calculator switchpad

Today I got my first comment on this blog, and I appreciate it a lot. Hopefully more comments follow.

The switchpad of the calculator came from Jameco, and was basically 16 switches in a grid, as displayed in this schematic. To connect them to the PIC16F877A was simple: on the read side the voltage is pulled up to a known voltage (5V makes perfect sense) using a resistor network. The values of these resistors are arbitrary. I like 100k Ohm because this reduces power consumption. Speed does not really matter as they are switches anyway, and their fastest response time is 10ms. On the scan side you just connect the pins to the PIC16F877A. To read it is a matter of setting a particular line to 0V and see if any of the receiving ports detect it. If this is the case, that particular switch was pressed.

The software is slightly more complicated, because switches tend to "bounce" a bit, and it needs to be debounced, preferably over a 20ms range. So if there are changes faster than 20ms, these should be ignored, and the system should wait until the signal is stable for over 20ms. This is relatively easy to code as well, though.

Version 2 GPS software

Version 2 of the GPS had a new program, although some of the old software is still recognizable.

It first initializes the variables, and the LCD display. It also sets the serial port for 4800 bps communication, which is what is needed for the GPS module. This means output to the PC will also be in this speed. The LCD activation sequence is always the same, as the R/W line is pulled down, we need to have maximum delays (160uS and 5ms respectively). Finally the software displays a . on the display to indicate that something is happening.

During the start loop it reads from the GPS until a valid string is read. If the button is pressed during this time, it is remembered so that the location can be recorded.

During the main loop it continues to read from the GPS and makes sure that a valid sentence is stored separately for later recording. The SendString routine sends the GPS string from the sentence that is at location Number. This is used to display relevant information for each screen.

There are a number of states, that can be cycled through using the button. In one state it works normally, displaying the location and recording locations and pictures in case the camera triggers the flash port. In various other states different information is displayed. In the sending state it displays "Sending..." and sends the complete memory to the PC over the serial port.

Other routines handle the storing in external memory, the reading from external memory, the writing and reading from the serial port, and the recognizing of a valid sentence and skipping all the other information from the GPS module.

The detecting of the switches is done with a separate routine, which sets a flag when it happens. This routine is called as often as possible, to make sure no button presses are missed.

Serial port for the new GPS

Version 2 of the GPS has a more complicated serial port interface, as it has two functions. The original only had to read from the GPS, and store the results in memory, the new version also has to be able to send the result to a PC. Unlike version 1, which used an external GPS and therefore used a regular serial input, version 2 uses an actual GPS module. The second version also has to be able to output to a PC, something that was not covered at all in the first version.

The connection to the GPS module has some intricacies, because the GPS module, despite having a 4-6V input, had only a 3.3V output. Glancing through the data sheets of the PIC16F628A this might seem to be no problem, until one notices that the serial input port of this microcontroller uses Schmitt Trigger inputs, which means the minimum voltage for a '1' is 4V. To do the conversion I used a 74HCT125, which accepts a large range of input voltages, and converts them to whatever voltage is set on Vcc. Of course it is a bit of a waste of the other 3 buffers inside this chip, but it works and makes it very unlikely to damage the GPS module. An alternative would be to run the PIC16F628A on 3.3V, but this would cause other difficulties, for example with the interface to the LCD display, which needs 5V. Apart from the buffer, the connection to the GPS is very simple, as there is no other conversion necessary.

To connect to the PC we would officially have to output +12V and -12V signals. Clearly this is not easy with 5V power, and even if we used the 9V battery power we would still run into trouble with negative voltages. Fortunately there is the DS275. This small component leeches voltage from the RS232 interface of the PC and uses that voltage to send the messages to the PC. Of course, a PC might not have the right voltage (in fact, often they do not) but you would expect a PC to be able to read its own voltage levels back. The DS275 covers the -12V, for the +12V it uses Vdrv, which in this case is still connected to +5V. As the RS232 specification states that anything above +3V should be considered legal, +5V is fine, though barely. Hooking up the DS275 is very staightforward. As you can see it handles reads as well, but in this case it is not used. However, on the PC side the read should still be connected to allow access to the voltage levels. Note that if you decide to use the DS275 for sending AND receiving you should realise the component is NOT full duplex. You can either send or receive, but not both at the same time. If you need to do this, you might want to consider the Maxim 232 range of devices, which will be covered at another time.

Of course, you can see the decoupling capacitors of 0.1uF everywhere in the schematic. The GPS, the DS275 and the 74HCT125 all need them. Also, the plug used for the serial port is female, in this case, and this is why pins 2 and 3 were swapped compared to the previous schematic.

More power (on voltage doubling)

The calculator uses 2 AAA batteries. However, so far all my circuits use 5V, and even the HD44780 LCD display requires 5V. Initially I decided to use 4 rechargeable AAA batteries (1.25V each, 5V total) but this was too cumbersome and heavy.

I had already used the ICL7660A to invert a voltage. This time I decided to use it to double a voltage. The circuit above comes straight from the documentation, and it works. However, as you can see, there is a diode involved, which causes the voltage to drop by 0.7V. So the 3V becomes 5.3V. Clearly there is a risk involved here: if the batteries are exceedingly fresh, they will deliver over 1.5V each and the 5.5V threshold of the PIC microcontroller could be reached. However, this has not happened yet. Also, rechargeable batteries don't work well in this configuration, because they have too little voltage to properly power the LCD display.

In the schematic the +5V is not 5V that is applied, but actually the voltage that comes out of the circuit. The battery is hooked up to the 3V input. Despite the odd configuration of the capacitors, they are correct.

A more ideal way to create the 5V is to use a bucket converter, but that will not be covered in this post.

Software licensing

In this blog there are many references to software I published using google documents. As you can tell from the source files, this software is copyrighted. This post is to clarify the nature of this copyright.

First of all, you can always contact me regarding the use of a specific file. In fact, I appreciate people contacting me. You can contact me for other things as well. So if there is any doubt, just send me an Email.

PERSONAL USE: Next is the use of the files. Obviously, if you want to try the code, that is fine. There is no warranty: if this file blows something up, it's not my fault. They are on the blog merely to explain how I did certain things for myself.

OTHER USE: If you use the source code (or a modified version) to create something and it stays in a quantity less than 10, there will be no objection from me (but again, telling me would be nice). The moment things become more commercial (even if you plan to give them away) you need to contact me first.

MODIFICATIONS: If you want to modify the code, this is usually fine too, though I would appreciate it if you told me, and sent me an updated version.

DISTRIBUTING: Unless I give permission (which I most likely will do), you are not allowed to distribute the source code, or a modified version of it. Obviously you can create a patch file, and publish it together with a link to my code. Even in that case, it would be best to let me know. In general, I just would like to be aware where my code is going.

Hopefully this explains things. This is version 1.0, if you need a reference. If there is a later version, it will void this one, except for those cases where this one was used before the other one appeared.

My calculator

On the piclist I recently posted that I would publish my calculator here. So here is the first installment, with picture.

As you can see, the calculator uses a weird keyboard that I found in the catalog of Jameco. It used an even smaller one first (with only 12 keys) and later I replaced it with the current one. It uses a PIC16F877A microcontroller to do basic arithmic operations, has an HD44780 display and works using 2 AAA batteries (and has worked on the same batteries since 2006). There is a LED to indicate it is on, as well as an on/off switch. I've started making a cover out of it (using a cat litter container) but this is not finished yet. The software for the calculator is available.

Features of the calculator are:
* Keeps time and date
* Alerts of birthdays
* Stores addresses
* Basic arithmetic (multiply, divide, addition, subtraction, random number)
* 0.00000001 to 99999999