Thursday, December 17, 2009
Making a Time Machine server with Ubuntu
I originally tried using NFS and Samba, but the setup procedure turned out to be too complicated and neither of them worked out in the end, for some reason (but I'm sure it could be done). I stumbled across netatalk which includes an AFP (apple file sharing protocol) server. I then followed the tutorial here, to set it up.
However, some things to note:
The tutorial is a year old and the latest version of netatalk has not been uploaded to the ubuntu repositories, so you need to get the latest sources from the netatalk website and compile them yourself (the latest version has Time Machine support).
You can follow the tutorial through, like I did, and just update to the latest netatalk when you've completed the tutorial. Simply download the latest netatalk sources, do a ./configure, make, sudo make install and reconfigure the netatalk configuration files. Make sure to add the "tm" option to the configuration files. I posted a comment on that site, so just search the page for the user "solarwind" to see my comment about that.
Friday, November 20, 2009
Electronics Supplier in Toronto
This store, located on 255 College st., sells Arduinos for $30 as well as a whole bunch of other stuff you'd expect to find at Sparkfun.
Friday, September 11, 2009
Hamachi is great!
Hamachi simulates a physical LAN very closely, so every game I tried worked on the LAN setting very reliably: Red Alert 3, Counter Strike Source, and many more.
Friday, August 28, 2009
The Pirate Bay Sold - Alternatives
BTJunkie, Demonoid and EZTV are the best.
Saturday, August 22, 2009
Bicycle Speedometer Project
At it's core, it's just a simple reed switch hooked up to a PIC microcontroller's CCP module (in capture mode) which measures the period of the turning of the wheel. Based on the period data, the microcontroller then calculates the speed and displays the information to the user on an LCD screen. Now, to dive in deeper...
This project can, of course, remain as simple as a mere speed measuring device or can be expanded into a full bicycle computer which maintains trip logs (time, distance, speed, keeping track of rest breaks), control headlights based on ambient light and so on.
The main speed measuring module consists of a reed switch mounted on one of the front forks. A strong magnet shall be placed on one (or more) of the spokes. Every time the wheel turns, the magnet will pass the reed switch and close the circuit, sending a signal to the microcontroller. The microcontroller is then interrupted by the event and the CCP module then measures the period. To compute the speed of the bicycle, only the circumference/diameter of the wheel and the period must be known. Although only one magnet is required, more can be placed to allow for greater accuracy. On the PIC's side, an appropriate external crystal shall be used with the CCP's timer to allow for millisecond timing. With the appropriate crystal, the CCP can then measure the period (in milliseconds) of the wheel to produce very accurate speed readings. Readings can be presented to the user every 1 second, for example. The LCD can be of HD44780 type or this or this or one of the graphic LCDs at Futurlec. The LCD should be small and readable yet consume as little power as possible. The microcontroller itself will be in sleep mode most of the time to conserve power.
A real time clock and SD card (via SPI interface) can also be added to the project to allow for data logging and to add a simple real time clock. The RTC will maintain time via a "backup battery" and the SD card would be written to every now and then.
The entire computer could be powered by batteries. But since the computer consumes less than a few mA at most, a solar panel is also possible. Or it would also be possible to use the energy generated by the bicycle and store it in capacitors.
As for the core of the computer, any PIC would do for such a relatively computationally non-intensive job. However, I was thinking of using the dsPIC33FJ128GP802 :)
Free Blogger Templates
BTemplates is a gallery that shows, describes and ranks the best templates for Google’s platform for blogs. It was the first blogger templates gallery created in March 2008 and currently has the largest collection of templates.
Friday, August 14, 2009
Thursday, August 13, 2009
UART Example for DSPIC33 (DSPIC33FJ128GP802)
#include <p33FJ128GP802.h> _FOSC(OSCIOFNC_ON & FCKSM_CSDCMD & POSCMD_NONE); //Oscillator Configuration (clock switching: disabled; // failsafe clock monitor: disabled; OSC2 pin function: digital IO; // primary oscillator mode: disabled) _FOSCSEL(FNOSC_FRCPLL); //Oscillator Selection PLL //_FOSCSEL(FNOSC_FRC); //Oscillator Selection no PLL _FWDT(FWDTEN_OFF); //Turn off WatchDog Timer _FGS(GCP_OFF); //Turn off code protect _FPOR(FPWRT_PWR1); //Turn off power up timer void InitUART1() { // This is an EXAMPLE, so brutal typing goes into explaining all bit sets // The HPC16 board has a DB9 connector wired to UART2, so we will // be configuring this port only // configure U2MODE U1MODEbits.UARTEN = 0; // Bit15 TX, RX DISABLED, ENABLE at end of func //U2MODEbits.notimplemented; // Bit14 U1MODEbits.USIDL = 0; // Bit13 Continue in Idle U1MODEbits.IREN = 0; // Bit12 No IR translation U1MODEbits.RTSMD = 0; // Bit11 Simplex Mode //U2MODEbits.notimplemented; // Bit10 U1MODEbits.UEN = 0; // Bits8,9 TX,RX enabled, CTS,RTS not U1MODEbits.WAKE = 0; // Bit7 No Wake up (since we don't sleep here) U1MODEbits.LPBACK = 0; // Bit6 No Loop Back U1MODEbits.ABAUD = 0; // Bit5 No Autobaud (would require sending '55') U1MODEbits.URXINV = 0; // Bit4 IdleState = 1 (for dsPIC) U1MODEbits.BRGH = 0; // Bit3 16 clocks per bit period U1MODEbits.PDSEL = 0; // Bits1,2 8bit, No Parity U1MODEbits.STSEL = 0; // Bit0 One Stop Bit // Load a value into Baud Rate Generator. Example is for 9600. // See section 19.3.1 of datasheet. // U1BRG = (Fcy / (16 * BaudRate)) - 1 // U1BRG = (36850000 / (16 * 9600)) - 1 // U1BRG = 238.908854 //Round to 239 U1BRG = 239; // Load all values in for U1STA SFR U1STAbits.UTXISEL1 = 0; //Bit15 Int when Char is transferred (1/2 config!) U1STAbits.UTXINV = 0; //Bit14 N/A, IRDA config U1STAbits.UTXISEL0 = 0; //Bit13 Other half of Bit15 //U2STAbits.notimplemented = 0; //Bit12 U1STAbits.UTXBRK = 0; //Bit11 Disabled U1STAbits.UTXEN = 0; //Bit10 TX pins controlled by periph U1STAbits.UTXBF = 0; //Bit9 *Read Only Bit* U1STAbits.TRMT = 0; //Bit8 *Read Only bit* U1STAbits.URXISEL = 0; //Bits6,7 Int. on character recieved U1STAbits.ADDEN = 0; //Bit5 Address Detect Disabled U1STAbits.RIDLE = 0; //Bit4 *Read Only Bit* U1STAbits.PERR = 0; //Bit3 *Read Only Bit* U1STAbits.FERR = 0; //Bit2 *Read Only Bit* U1STAbits.OERR = 0; //Bit1 *Read Only Bit* U1STAbits.URXDA = 0; //Bit0 *Read Only Bit* U1MODEbits.UARTEN = 1; // And turn the peripheral on U1STAbits.UTXEN = 1; // I think I have the thing working now. } int main() { ADPCFG = 0xFFFF; //make ADC pins all digital //PLL setup: CLKDIVbits.PLLPRE = 0; // N1=2: PLL VCO Output Divider Select bits; 0 -> /2 (default) PLLFBDbits.PLLDIV = 42 - 2; // M=40: PLL Feedback Divisor bits; 42 - 2 = 40 -> 40 x multiplier // (divisor is 2 more than the value) CLKDIVbits.PLLPOST = 0; // N2=2: PLL Phase Detector Input Divider bits; 0 -> /2 //40 x: 73.700000 MHz = 36.850000 MIPS //42 x: 77.385 MHz = 38.6925 MIPS //43 x: 79.2275 MHz = 39.61375 MIPS while(OSCCONbits.LOCK != 1); // Wait for PLL to lock RCONbits.SWDTEN = 0; // Disable Watch Dog Timer TRISA = 0b00000000; TRISB = 0b00000000; asm volatile ("mov #OSCCONL, w1 \n" "mov #0x46, w2 \n" "mov #0x57, w3 \n" "mov.b w2, [w1] \n" "mov.b w3, [w1] \n" "bclr OSCCON, #6"); RPINR18bits.U1RXR = 7; RPOR3bits.RP6R = 0b00011; asm volatile ("mov #OSCCONL, w1 \n" "mov #0x46, w2 \n" "mov #0x57, w3 \n" "mov.b w2, [w1] \n" "mov.b w3, [w1] \n" "bset OSCCON, #6"); InitUART1(); while(1) { U1TXREG = 'H'; } return 0; }
Wednesday, August 12, 2009
Tungsten Carbide Drill Bits
Thursday, August 6, 2009
Pure Gnome/KDE on Ubuntu
I’ve used this so many times to clean my system. A simple command to get back to a pure Gnome or pure KDE Ubuntu/Kubuntu system – especially if you have both desktops installed.
http://www.psychocats.net/ubuntu/puregnome
or
Saturday, June 27, 2009
FreeRTOS on the dsPIC33
I recently ordered a bunch of dsPIC33F samples – specifically the dsPIC33FJ128GP802. These devices are amazing. They’re fast, have lots of RAM, and very very easy to use with FreeRTOS.
Things to keep in mind when setting up a project for the dsPIC:
- Ensure you define the MPLAB_DSPIC_PORT macro (Project options –> MPLAB C30 –> Add… (in the preprocessor macros box)
- I prefer to use heap_3.c so that the compiler’s own malloc() and free() functions can be used. To use them, define a heap size (Project options –> MPLAB LINK30 –> Heap size: (text box)). I just put 5000. Adjust yours accordingly.
- C30 optimization: (Project Options –> MPLAB C30 –> Categories: Optimization) – I selected –O3 level optimization. Adjust yours accordingly. The port page on freertos.org says to enable the Omit frame pointer checkbox. Strangely enough, the demo application does not have the checkbox enabled.
- Also remember to tweak your FreeRTOSconfig.h file and set up all the include directories.
I had no trouble getting the project to work. I even made a simple LED blinker. No modifications to the linker script had to be made (what a relief). The sample project is provided below:
Friday, June 19, 2009
Setting Up FreeRTOS for the PIC18 Using MPLAB C18
FreeRTOS is a really cool real-time operating system (preemptive scheduler) for various architectures. It has been ported to the PIC18 platform (using MPLAB C18 compiler). However, the port is not very good.
Isaac Marino Bavaresco (isaacbavaresco AT yahoo DOT com DOT br) of the PICLIST has greatly improved and optimized the port for PIC18. His PICLIST page is here.
It took me a long time to get everything set up and working properly, so I’m writing this tutorial as an easy quick-start guide on getting FreeRTOS running on the PIC18.
Things you’ll need to get started:
- A PIC18 device
- MPLAB & MPLAB C18 compiler
- FreeRTOS
- I have made a convenient FreeRTOS modified package available for download (FreeRTOS 5.3.0) for the PIC18 containing Isaac’s improved port. DOWNLOAD
- My sample project. It’s the fastest way to get started. However, I recommend that you download this sample project just for the source files (don’t actually use the project file) and you set up your own project by reading this tutorial. DOWNLOAD
Step 1 – Setting up your directories
Configure your directories in this structure:
- PIC_Projects
- FreeRTOS
- Project_1
- Project_2
- Project_3
Step 2 – Download FreeRTOS_mod for PIC18 from the link above.
Unzip in your projects directory and you will get a directory named “FreeRTOS”.
Step 3 – Create a project
- Open MPLAB and click Project –> New…
- Create a project with the name of your choice corresponding to the directory structure outlined above.
- Click Configure –> Select Device… and select your PIC18 device
- Click Project –> Build Options –> Project…
- In the Directories tab
- select Library Search Path from the combo box and add the lib folder from your C18 installation. For me, it was C:\MCC18\lib.
- Next, select Include Search Path from the same combo box and add the following directories:
- .
- ..\FreeRTOS\Source\Portable\PIC18
- ..\FreeRTOS\Source\include
- In the MPASM/C17/C18 Suite tab
- Enable the checkbox for Extended mode.
- In the MPLAB C18 tab
- In the General category, add the following macro: MPLAB_PIC18F_PORT
- In the Memory Model category, select Large code model, Large data model, Multi-bank model
- Apply the changes.
- Add the following files to the project Source Files:
- Everything in the FreeRTOS\Source directory
- Everything in the FreeRTOS\Source\portable\PIC18 directory
- My main.c file from my sample project
- Add the following files to the project Header Files:
- FreeRTOSConfig.h from my sample project
- Add FreeRTOS\Source\portable\PIC18\18f2620_e_FreeRTOS.lkr file to the Linker Script section. If you are using a different device, you need to make your own linker script. Use the one provided as a reference and compare it to the original one.
- You should now be ready to compile your project. Go ahead and click Project –> Build All and watch the magic happen.
Explanation
All that this project does is create two tasks that constantly print “abcd” and “1234” to the UART. It uses a mutex to ensure that the non-thread-safe puts function is only being used in one thread at a time.
The RTOS configuration file is FreeRTOSConfig.h. The only thing non-standard in there is the #define CUSTOM_HEAP macro. I created this little modification to replace the standard malloc()/free() calls in the RTOS source to instead use Isaac’s functions which are far more optimized.
FreeRTOS Finally Working!
With a lot of help from Isaac Marino Bavaresco (PICLIST), I finally got FreeRTOS up and running perfectly on my PIC18F2620. It’s a fun chip loaded with features and perfect for FreeRTOS. I’ll write a complete tutorial shortly to get the RTOS working on this chip. Hopefully, when I get my dsPIC33 and PIC32, it will be a whole lot easier to get the RTOS working.
Monday, June 8, 2009
Some Starter C18 Code for the PIC18
I haven’t posted anything in a while, so here is some C18 code for a starting off a project.
#include#include #include #include #pragma config OSC = INTIO67 //Internal oscillator #pragma config FCMEN = OFF #pragma config IESO = OFF #pragma config PWRT = ON #pragma config BOREN = OFF #pragma config WDT = OFF #pragma config MCLRE = OFF //MCLR is disabled #pragma config PBADEN = OFF #pragma config LVP = OFF #pragma config XINST = ON //extended mode enabled long int i = 0; void delay1s() { Delay10KTCYx(200); Delay10KTCYx(200); Delay10KTCYx(200); Delay10KTCYx(200); } void main() { OSCCON = 0b01110000; //8 MHz OSCTUNE = 0b01011111; //enable PLL TRISC = 0x00; //PORTC is all output stdout = _H_USART; //Set to user-defined output stream via _user_putc OpenUSART(USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_LOW, 51); while(1) { delay1s(); printf("ping! %li\n", i); i++; } }
Here’s the project itself: Click to Download
Friday, May 29, 2009
FreeRTOS has a PIC18 port!
Havn’t posted anything in a while, but working with FreeRTOS and the PIC18 port. Fully preemptive scheduling, small, fast, efficient and works with C18 compiler.
More on this once I have everything sorted out.
Monday, May 18, 2009
More thoughts on my token bus based RS485 protocol
It was suggested on the PICLIST that I list all possible errors that could happen with my protocol and write possible solutions. Let’s see how this goes.
In a perfect bus where there is no line disturbance, no random death of a node, and proper following of protocol by each node, we can assume that data will not get corrupted, the token will not get lost and the buss will never fail. However, in reality, there is noise and line disturbance, nodes may randomly go down or leave or get hung up, or nodes may fail to follow protocol for some other reason. Due to these issues, it is important that we try and list the possible problems that may occur on the bus and provide solutions if we can.
Possible problems:
- The biggest problem in this type of protocol is when the token itself gets lost.
- When the bus is in working order, it is always busy due to the token being passed around. If the token gets lost for some reason, no node on the bus will have voice and therefore, the bus goes idle.
- The token may get lost due to several reasons such as line disturbance during passing of the token from node A to B, or if a node which owns the token goes down. In either case, the bus goes idle because no node has voice and therefore no node transmits.
- Fortunately, we can use the silence on the bus to our advantage as an indicator that a new token must be assigned. A possible solution to this problem is that every node will detect a lost token when there is a silence on the bus for longer than (ID * 2) + 10 ms (for sake of example; better values need to be calculated during implementation). Therefore, the node with the lowest ID will detect the silence first. As soon as this node detects the silence, it has to assume ownership of the token and start transmitting something (before the next node detects silence).
- Some things to consider: this method should work well. However, it assumes that all nodes give full priority to the network. If a node gets partially hung up doing a task for (let’s say) 50 milliseconds, it could cause the bus to issue a new token. The problem now is that two tokens are on the bus and this will effectively cripple the bus. However, this shouldn’t happen since part of the software stack design requires full priority be given to the bus.
- Another problem arises during corruption of data.
- When node A sends a normal data packet to node B, it expects that B receives the packet successfully. But what if B doesn’t get the packet due to data corruption? For a non critical packet, this may be acceptable. But when we actually need that packet to reach its destination, we need a way to make sure that it got there.
- A possible solution to this (discussed in the original protocol description) is the ACK packet. How this works is that the sender node (node A) sends a packet and enables the ACK_REQ flag to signal that it wants an ACK from the target that it got the packet. When the target node (node B) receives the packet, it sees that the ACK_REQ flag is enabled and sends back an ACK (or NACK) packet to the original sender (when it has voice, of course). If there is a problem where B does not get the packet at all, or the packet is too corrupted to identify the sender, A will trigger a timeout 100 ms after it sent the packet (again, these numbers are for example purposes only). This number, however, depends on the number of nodes present on the bus. If there is a large number of nodes on the bus, we must wait a long enough time for the token to get to node B for it to send back an ACK (or NACK). But it is safe to assume a large number like 100 ms or 250 ms for this since we don’t expect errors to occur very often. This leads us to our next problem:
- What happens if the ACK (or NACK) packet gets corrupted?
- So far, A has successfully sent a packet (with ACK_REQ) to B. B now sends an ACK (or NACK) back to A. Suddenly, something happens, causing the packet to get completely corrupted. What happens now? In this situation, B has received the packet but A is still waiting for an ACK and thinks that B didn’t get the packet at all.
- For this situation, we can attach a sequence number to the packet. So even if the same packet (with the same sequence number) gets sent out multiple times, it wont get “used” more than once by the target.
2 more network protocols suggested on the PICLIST
http://yaspnet.sourceforge.net/
These look really useful.
For embedded applications, CSMA/CD, token bus, and the polling system seem to be good choices.
Olin’s Old Network
Olin Lathrop:
There are other ways to guarantee this. I think the vast majority of RS-485 networks use a bus master system. This simplifies a lot of stuff. I did one a while back where the master addressed each slave in turn. If the slave had nothing to send, it responded with a NACK so that the master would know to go on to the next slave. In my system, the configuration wasn't known up front, but the maximum number of slaves was limited to 15. The bus master kept track of which slave addresses were in use to avoid the timeout for the unused ones each time thru the list of slaves. If a slave timed out three times in a row, it got crossed off the list. Once per loop, the master would try one unused address. If a slave responded, it would be added to the active list. This allowed hot-swapping and powering slaves up and down, which was important for this particular system. This was done 10 years ago on hardware that was designed before that. The biggest bestest PIC at the time was the 16F877. CAN hardware wasn't that readily available yet. A few years later and I definitely would have argued for using CAN instead. This project is long dead, so I can give more details on it. I have attached the protocol document. As I have said consistantly though, I still think you're better off using CAN and a 18F4580 or similar.
Sunday, May 17, 2009
My RS485 Network Protocol
After hours of research, I was unable to find a suitable real-time, multi-master/peer-to-peer network protocol for RS485. So I made my own. Please evaluate it and comment on it.
The protocol is designed to work over RS485, using an RS485 transceiver hooked up to a PIC's UART pins. 8 bit, no parity, 1 stop bit. Maximum length of data segment of packet is 0xFF bytes long, but since most midrange controllers don't have that much, I'll stick with 26 bytes. The protocol has a token bus type topology (or at least that's what I think it's called), so it's deterministic, collision free and real time.
The packet looks like this:
<preamble> <destination> <source> <flags> <length of following data> <data> ... <data> <checksum>
<preamble>: 1 byte. Start of packet. 0xAA.
<destination>, <source>: 1 byte each. 0x01 - 0xFE. 0x00 represents the bus owner, configuration node or hub (unimplemented for now). 0xFF is broadcast, for all nodes.
<flags>: 1 byte <0, 1, 2, 3, 4, 5, 6, 7>
0 - ACK - acknowledge
1 - NACK - no acknowledge (could not use the packet, for some reason)
2 - ACK_REQ - when sending, request an acknowledgement from target node
3 - ID_REQ - request identification information from the target node
4 - TYPE - is the data segment a special command type or a normal data type?
5 - TOKEN - this packet is a token and contains data of zero length; all other flag bits must be zero
6 - not used/application specific
7 - not used/application specific
<length>: the length (in bytes) of the data segment that follows
<data>: the data (or command) segment itself
<checksum>: the 8 bit polynomial checksum
Notes:
The lowest ID on the bus has voice (starts with token). If it has a message to send, it can send up to 4 packets. Then it MUST give up its voice and give the token to the next node. -> The 5th (or less if it has less or even no data to send) packet must be a token that it passes to the next node.
If the node has no data to send, it will pass the token to the next node in the bus, which is it's own ID + 1.
IDs are static on the bus and are assigned incrementally (I want to make them dynamic, though).
When a byte is received, it is buffered in memory in the "interrupt on RX" function. After the last byte (checksum) has been received, the packet is checked, validated and used. It is discarded if the packet does not belong to the node.
The packets shall be examined as CPU time permits. One question to you all though: since this type of network requires the constant examining of packets, I assume it takes a lot of CPU time.
The token bus type network guarantees that a node will be able to transmit every x units of time. However, for small, embedded applications, two other types of networks are also very possible: CSMA/CD and Polling. All the different types of networks are discussed on this page: http://www.ece.cmu.edu/~koopman/protsrvy/protsrvy.html
Further:
After posting on the PICLIST and getting opinions about the protocol, I got the following responses:
- What happens when the token gets lost? For example, when the node which has the token goes down. Tokens get lost.
- My possible solution: I don’t expect a node which owns the token to go down. Note that when sending tokens, the receiving node must always acknowledge that it got the token. If it does not send an ACK, the sender still owns the token and must try again a few times until the receiving node gets the token. If there are a few unsuccessful tries (4 or 5), the token owner broadcasts (to 0xFF) that the target node is probably down and sends the token to the next node (n + 0x02). Now, to solve the problem of recovering from a lost node which has the token, we could probably add another node to the bus known as the bus owner with an address of 0x00. The owner takes place in passing the token around and keeps track of who is on the bus and who is not. If the token gets lost, the bus owner then polls each of the nodes to see which node went down. After that, the bus owner then either reassigns the IDs so that they are all consecutive or broadcasts to all nodes saying which node went down so the nodes do not pass the token to that node. Basically, the bus owner makes sure that the bus is in working order.
- Look at the DMX 256 protocol.
- Look at uLan - http://ulan.sourceforge.net/
- What happens when an ACK is not received?
- In this situation, the first packet (with an ACK_REQ) is successfully transmitted, but there is an error when the target node sends an ACK. In effect, the ACK does not get sent back to the original sender. The sender would probably then send the packet again. This could be a problem especially when node A passes the token to node B. B then needs to ACK to A that it got the token. If A does not get the ACK, A will then send the token again. But what might happen here is that B will start talking on the network since it has voice (it got the token). A collision occurs. This might be a very improbable situation, but if it does happen, it will disrupt the bus.
- A possible solution to this is that:
- A token –> B
- B ACK –> A
- A ACK –> B
- What happens here is that A sends a token to B and waits for an ACK.
- If B did not get the token at all, it obviously will not send an ACK. In this case, A still has the token. A will wait for a while and then trigger a timeout in which case it will retry sending the token to A.
- If B got the token:
- B sends an ACK to A.
- If there is a problem sending the first ACK, B will retry sending the ACK until it gets a response. If it doesn’t get a response, B drops the token and it is assumed that A still has the token due to an unsuccessful transfer.
- If A got the ACK:
- A sends an ACK to B.
- If there is a problem sending the ACK to B, B will drop the token. Now no one has the token. The bus owner sees this as the token has not been circulating for a while. The bus owner then resets the bus by giving the token to a certain node.
- If it B got the ACK, B now has the token.
- As you can see, this gets very complicated really quickly. Maybe CSMA/CD isn’t so bad after all.
Sunday, May 10, 2009
I2C for chip-to-chip communication
If you have several PIC microcontrollers and other I2C devices on the same PCB, the best bus to use would probably be the I2C bus. It’s a synchronous multi-master bus so the PICs can talk to each other while controlling the slave devices as well.
Here are some interesting sites on the I2C bus:
http://www.robot-electronics.co.uk/htm/using_the_i2c_bus.htm
http://www.i2c-bus.org/i2c-primer/
Sunday, May 3, 2009
CAN – It’s Awesome!
After further research, I learned more about the CAN bus (controller area network). It only requires three wires (high, low, ground) and terminating resistors (typically 110 ohms for CAT5 cable) and a CAN transceiver. Unlike RS485, the CAN bus specifications specify the physical layer as well as the protocol layer. The bus allows for multi master communication over long distances (1000 m) and sufficient data rates (1 Mbit/s). The details such as collision avoidance/detection error checking and so on are all taken care of at the chip level.
Maxim IC has some CAN transceivers and I just sampled them. I’m planning to use them over CAT3 or CAT5 cable (twisted pair). Let’s see how this goes.
More on this once I get the system up and running.
Saturday, May 2, 2009
Microcontrollers & Communication
I recently started a project which required several microcontrollers (placed around the house) to be able to communicate with each other. The difficult part is choosing a communications method and protocol. After doing some research, I found the following to be suitable options for inter-microcontroller communications.
The most interesting and suitable option I found was was the RS485 bus. This bus allows for communications over potentially long distances (greater than 1.3 km), tolerates high speed, allows for many protocol designs, is asynchronous and easy to use. Several protocols allow for multiple bus masters with collision detection. Overall, the bus should be pretty reliable. Further research suggested that either CAT3 (phone cable) can be used with 6 contact RJ11 type connectors. This allows for full duplex communication over 4 lines and one ground line. CAT 5 ethernet cable with RJ45 type connectors could also be used if desired. However, twisted pair cable is strongly recommended (such as CAT3 or CAT5).
Another option is using ethernet. The Microchip ENC26J60 transceiver can be used. However, I’m not sure how ethernet can be used as a bus (without a hub/switch). More on this later.
If wires prove to be too cumbersome to implement, one may chose to take the wireless route. Futurlec sells SPI radio transceiver modules at a low cost. Implement your own protocol.
Other busses such as CAN, LIN and USB are further discussed on the following site: http://www.ucpros.com/
Sunday, April 26, 2009
Another cool idea for connecting vias for DIY double-sided PCBs
Tony Smith, , of the PICLIST gave me this idea:
Take a long piece of solid strand wire and thread it through all of the vias, like sewing. The wire should obviously be bare (stripped of all insulation). Solder one side, then the other. Do this for all the vias and clip off the excess wire and the interconnecting wire.
It’s fast, easy, cost-effective, and it works.
Saturday, April 25, 2009
Annoyances and solutions for components when top-soldering DIY double-sided PCBs
Most components are very easy to top solder when making double-sided PCBs. However, some can be annoying and hard. The following may be a simple solution for such components:
- Large capacitors
- Do not insert completely. Leave space on top and bend capacitor over on its side. This will leave a lot of space for easy top soldering.
- Male/female pin headers
- For the male pin headers, use pliers or a vice & hammer to tap the plastic part further toward the connection end. This will give room for top-soldering.
- For the female headers: this can get tricky on some types as not enough pin length is left to allow for top-soldering. The best I can think of in this case is to try and raise the header off the PCB slightly anyway and solder the top parts first. Then flip to the other side of the PCB and continue soldering.
- Switches, piezoelectric speakers, and other seated components.
- These can also get tricky to top-solder. Again, the solution may be to raise the component off the PCB as much as possible. If this doesn’t work, then the next quickest way is to solder stiff copper wires to them as lead-extensions.
If all else fails, it’s always handy to have a few through-hole rivets (as discussed in detail in my previous post). In any case, top-soldering is the quickest and most cost-effective method for DIY double-sided PCB making.
And there’s my thought for today.
Thursday, April 23, 2009
Tuesday, April 21, 2009
Kubuntu 9.04 RC
I just gave Kubuntu 9.04 RC a try - installed it on my old Dell Inspiron 6000 laptop. Works very well (KDE4.2). It was flawless and did everything I needed. Unfortunately, KDE login/logout is still a bit slow compared to Gnome, but this will improve with time. 9.04 final release is due in two days.
Driving a Piezoelectric Speaker with a PIC
Piezoelectric speakers are really cool. You can get them inexpensively from most hobby electronics stores, take them out of PCs, and so on. You can directly connect them to your microcontroller (resistor recommended) and generate any tone you want.
Simply connect one end of the speaker to an output pin on your PIC and connect the other end to GND for the simplest configuration. You make the speaker “tick” by passing current through it. By rapidly turning the output pin on and off, you generate a tone. Here’s a very simple example program that turns the output pin on and off via software:
#include "main.h" #define SLEEP 1000 void main() { setup_adc_ports(NO_ANALOGS|VSS_VDD); setup_oscillator(OSC_8MHZ); setup_uart(9600); while(true) { output_high(PIN_B6); output_high(PIN_C0); delay_us(SLEEP); output_low(PIN_B6); output_low(PIN_C0); delay_us(SLEEP); } }
Pin B6 (in my case) is the speaker output. Pin C0 is an output to an LED (for testing, it is not needed). You can change the value of the SLEEP define for varying frequency of sound.
However, there is another way that this can be done (more reliably) – using the PIC’s internal PWM (from CCP module). You can generate very precise frequencies that way.
Sunday, April 19, 2009
PICKIT2 Linux GUI – In Progress
I’m working on a Linux GUI for the PICKIT2, it’s in progress – almost done. Stay tuned.
Saturday, April 18, 2009
MAX233A
I just got my MAX233A samples from Maxim. They’re UART RS232 <—> TTL level computers so you can interface your PIC’s UART to your computer’s RS232 port. Makes development a lot quicker since it’s easy to program and view output.
On windows, you can use the termite terminal to communicate via UART on a windows machine. On a Linux machine, you have a lot more options – see Minicom. There are even floppy Linux distributions designed just for this purpose, so you can pull that old 386 out and put it to some use.
The great thing about the MAX233A is that it requires no external capacitors for its internal charge pumps (which are used to boost voltage levels to RS232 specifications). The only thing that’s required is a decoupling capacitor as described in the sample circuit in the datasheet.
I salvaged an old RS232 mouse for its cable. It had all the wires I needed (TX, RX, GND) to fully interface to my microcontroller.
So just go ahead and order some samples of the MAX233A – it’s a great little chip.
If you have a PIC that supports self writes to flash, you can even write (or download) a serial bootloader and development will go even faster as you’ll be able to program your chip directly over UART.
Saturday, April 11, 2009
DIY IPOD Battery Pack
So my IPOD Nano 1st G internal battery is dying. I can barely squeeze out a few minutes of play time using the normal Apple firmware. IPOD Linux and Rockbox are awesome; by setting the backlight brightness to a minimum, I can get a whole lot more playtime. One option is to buy a battery and installation kit (they’re pretty inexpensive). However, this method requires you to open up your IPOD (which is really not that big of a deal), but there must be a simpler way of getting the job done – using components you can find around the house.
What I’m talking about is an external power supply/battery pack that can fit onto any IPOD (through the USB cable) - http://www.ladyada.net/make/mintyboost/
But we can make one ourselves – a more versatile one.
The IPOD cable consists of one end that plugs into the device and the other end is a standard USB male connector. The USB connector consists of 4 pins - V+, GND, D+, D-. To supply power to the IPOD, we need to supply exactly 5 volts through the V+/GND pins. The D+ and D- should be tied to V+ via 100k resistors (I think – more on this later). And there you have it – your own power ipod power supply.
The actual circuit, however, can get a bit complicated. What regulator do we chose? The design I’m thinking of will be able to be powered from as little as 2 AA batteries to the 12 V output from your car. We need a regulator that can accept this high range of voltages. Obviously it needs to be a boost/buck (step up/step down) regulator. These tend to get a bit annoying as we need external capacitors and solenoids for the circuit. Take a look at the mintyboost above for inspiration.
Oh, and it would be cool to have it small enough so all of it fits on the back of an IPOD Nano 1st G.
Just a thought.
Wednesday, April 8, 2009
DIY Through-Plating for Double-Sided PCBs
Creating your own PCBs can be annoying – especially when trying to make them compact and contain many parts. Routing can be very difficult. Luckily, we can make our own double-sided PCBs just as easily. However, the problem now is finding a way to create vias and plated through holes at home safely, efficiently, effectively, quickly, easily and cheaply. Large chemical through-plating machines are out of the question. There must be an easier way to do it.
I came across a webpage a while back which had a few ideas for tackling this issue: http://www.electricstuff.co.uk/pcbs.html
There are several ways to overcome the vias/plated through-hole problem:
Top-soldering:
- Easy, quick, cheap, works for most ICs and components. The IC holders can be a bit tricky though, as well as certain capacitors and funny components.
- Connects one side of the board to the other – like a plated through hole.
- For vias, a smaller hole can be placed and a wire can be soldered through it on both sides of the PCB. This is slow and annoying.
Linking pins and rivets:
- These linking pins (http://www.harwin.com/search/T1559-01?ProductSearch=True) seem to be very interesting and provide a quick and easy solution for vias.
- For through-holes, the following system can be used: http://www.megauk.com/through_hole_rivets.php. The machine is expensive and is not necessary. According to the first article mentioned on this post, the rivets can be placed easily with tweezers alone. They seem to be relatively inexpensive (cost 20 pounds for package of 1000 rivets).
Sunday, April 5, 2009
Salvaging an RS232 serial mouse
I recently got some MAX232A samples from Maxim-IC. These chips convert the TTL RS232 signals from your PIC to the RS232 voltage levels required by your PC. They make it very easy to connect your PIC with your PC. I only needed one more thing: an RS232 serial cable. I noticed I had some old RS232 serial mice lying around. I decided to break one open and remove the cable. Perfect – the cable had all the wires I needed – RX, TX and more. Let’s put this aside.
Next, there were some more interesting components inside the mouse that may come in handy, such as buttons, phototransistors, IR LEDs and so on. The IR LEDs, phototransistors and the gears could be used for something interesting.
I found a site that describes the use of the IC inside the serial mouse to extract movement information: http://www.geocities.com/kellertuberg/telescope/serial_mouse.html
Let’s see where this goes…
Saturday, April 4, 2009
Homebrew CPU
I found some interesting sites on making your own CPU from scratch. Some of them are only made out of 74 series integrated circuits.
That site is part of the homebrew CPU webring. Just scroll to the bottom and you can click “next” through all the sites in the webring.
DS18B20 1-wire Driver for CCS C
I got my hands on a few of these DS18B20 1-wire digital temperature sensors. They’re really awesome. They’re small, easy to work with, and they run on the 1-wire bus which means they can run on a minimum of two wires. However, I found it easier to just run these devices with 3 lines: +5V, GND, Bus – saves a lot of design complexity.
I found a few good 1-wire drivers for CCS C (especially for these devices):
dallas onewire primitives library and ds1822 driver code
I then took ideas from them and made my own little driver. Some of the code is copied, some of it isn’t. Here it is:
main.c
#include "main.h" #include "1wire.c" #include "ds1820.c" float value = 0.0; void main() { setup_adc_ports(NO_ANALOGS|VSS_VDD); setup_adc(ADC_OFF); setup_spi(SPI_SS_DISABLED); setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1); setup_timer_1(T1_DISABLED); setup_timer_2(T2_DISABLED,0,1); setup_oscillator(OSC_8MHZ); setup_uart(9600); delay_ms(1000); printf("Starting...\t\n"); while(TRUE) { value = ds1820_read(); printf("%f\t\n", value); } }
main.h
#ifndef MAIN_H #define MAIN_H #include <16F690.h> #device adc=8 #FUSES NOWDT //No Watch Dog Timer #FUSES INTRC_IO //Internal RC Osc, no CLKOUT #FUSES NOPROTECT //Code not protected from reading #FUSES NOBROWNOUT //No brownout reset #FUSES NOMCLR //Master Clear pin used for I/O #FUSES NOCPD //No EE protection #FUSES PUT //Power Up Timer #FUSES IESO //Internal External Switch Over mode enabled #FUSES FCMEN //Fail-safe clock monitor enabled #use delay(clock=8000000) #use rs232(baud=9600, parity=N, UART1, bits=8, stop=1) #endif /*MAIN_H*/
1wire.c
#ifndef ONE_WIRE_C #define ONE_WIRE_C /* * One wire (1-wire) driver for CCS C compiler. Suitable for use with devices * such as the DS18B20 1-wire digital temperature sensor. */ #define ONE_WIRE_PIN PIN_C5 /* * onewire_reset() * Description: Initiates the one wire bus. */ // OK if just using a single permanently connected device void onewire_reset() { output_low(ONE_WIRE_PIN); // pull the bus low for reset delay_us(500); output_float(ONE_WIRE_PIN); // float the bus high delay_us(500); // wait-out remaining initialisation window output_float(ONE_WIRE_PIN); } /* * onewire_write(int8 data) * Arguments: a byte of data. * Description: writes a byte of data to the device. */ void onewire_write(int8 data) { int8 count; for(count = 0; count < 8; ++count) { output_low(ONE_WIRE_PIN); delay_us(2); // pull 1-wire low to initiate write time-slot. output_bit(ONE_WIRE_PIN, shift_right(&data, 1, 0)); // set output bit on 1-wire delay_us(60); // wait until end of write slot. output_float(ONE_WIRE_PIN); // set 1-wire high again, delay_us(2); // for more than 1us minimum. } } /* * onewire_read() * Description: reads and returns a byte of data from the device. */ int onewire_read() { int count, data; for(count = 0; count < 8; ++count) { output_low(ONE_WIRE_PIN); delay_us(2); // pull 1-wire low to initiate read time-slot. output_float(ONE_WIRE_PIN); // now let 1-wire float high, delay_us(8); // let device state stabilise, shift_right(&data, 1, input(ONE_WIRE_PIN)); // and load result. delay_us(120); // wait until end of read slot. } return data; } #endif /*ONE_WIRE_C*/
ds1820.c
#ifndef DS1820_C #define DS1820_C #include "1wire.c" float ds1820_read(); void ds1820_configure(int8 TH, int8 TL, int8 config); /* * ds1820_read() * Description: reads the ds18x20 device on the 1-wire bus and returns * the temperature */ float ds1820_read() { int8 busy=0, temp1, temp2; signed int16 temp3; float result; //ds1820_configure(0x00, 0x00, 0x00); //9 bit resolution onewire_reset(); onewire_write(0xCC); //Skip ROM, address all devices onewire_write(0x44); //Start temperature conversion while(busy == 0) //Wait while busy (bus is low) busy = onewire_read(); onewire_reset(); onewire_write(0xCC); //Skip ROM, address all devices onewire_write(0xBE); //Read scratchpad temp1 = onewire_read(); temp2 = onewire_read(); temp3 = make16(temp2, temp1); //result = (float) temp3 / 2.0; //Calculation for DS18S20 with 0.5 deg C resolution result = (float) temp3 / 16.0; //Calculation for DS18B20 delay_ms(200); return(result); } /* * ds1820_configure(int8 TH, int8 LH, int8 config) * Description: writes configuration data to the DS18x20 device * Arguments: alarm trigger high, alarm trigger low, configuration */ void ds1820_configure(int8 TH, int8 TL, int8 config) { onewire_reset(); onewire_write(0xCC); //Skip ROM, address all devices onewire_write(0x4E); //Write to scratchpad onewire_write(TH); onewire_write(TL); onewire_write(config); } #endif /*DS1820_C*/
All you have to do is set the define to the appropriate pin you’re using for the 1-wire bus. Remember to attach a 4.7k pullup resistor on the bus to VDD. The value of the pullup resistor is not critical. If I remember correctly, I tested resistors anywhere from 1k to 10k and they worked fine. If not, just stick with the 4.7k pullup as recommended in the DS18B20 datasheet.
Monday, March 30, 2009
University of Toronto Life Sciences
I just got accepted into the University of Toronto Life Science program. Awesome!
Saturday, March 28, 2009
Some interesting electronics/hobby/microcontroller sites
http://dev.emcelettronica.com/ Your Electronics Open Source
http://www.youritronics.com/ Youritronics: DIY, Electronics, IT and Gadgets
http://www.embedds.com/ Embedded projects from around the web
Thursday, March 26, 2009
DIY Reflow Soldering
I recently ordered a whole bunch of samples and high end integrated circuits from various companies such as Maxim, Austria Microsystems and Microchip (such as the PIC32). These chips are all really cool. However, there’s a problem. They’re all surface mount. It has become a trend for companies to offer high pin count and new devices in surface mount packages only. This is bad news for prototyping (especially for hobby use) because surface mount packages don’t fit in breadboards. However, it is very much possible to make PCBs with fine-pitch pads/traces for even up to 0.4 mm TQFP chips such as the PIC32 100 pin versions. However, the problem now becomes the soldering.
There are two ways that a hobbyist can attach surface mount chips to PCBs:
- Traditional soldering iron with lots of flux and a fine tip. Or,
- Homebrew reflow soldering, which is what today’s post will examine
For complete newcomers to the topic, the process of reflow soldering is outlined below:
- A special type of solder known as solder paste is applied to the surface mount pads on the PCB. The solder paste very think and acts like glue.
- The surface mount components are then populated on the PCB on top of the solder paste. Due to the viscous nature of the solder paste, the devices stay in place.
- The entire board is then slowly heated to a certain temperature enough to get everything warm (around 100 degrees Celsius for 2 minutes). Then temperature is quickly increased to around 200 degrees Celsius for the solder paste to melt.
- At this point, the solder paste melts and attaches the devices to the pads on the PCB.
- The PCB is cooled slowly and is ready for use.
Reflow soldering makes it very easy to solder very fine pitch components. All you need to do is apply solder paste to the pads, place and align the device properly, and melt away. Fortunately, hobbyists have several ways to go about making their own reflow “oven”, as outlined below:
- A conventional toaster oven can easily heat up to temperatures required to melt solder paste. Toaster ovens are also inexpensive and are commonly used by hobbyists as reflow ovens.
- Another way to go about reflow soldering is by using the stove top or a hot plate or a skillet.
- A third, less common way is to use a reflow station or a hot air gun. Engadget has a really good article on how to make such a device very inexpensively. http://www.engadget.com/2006/03/07/how-to-make-a-surface-mount-soldering-iron/
However, since the “temperature controls” on most toaster ovens, skillets, hot plates and stove tops is next to useless, it is important to measure the temperature of your heating device beforehand to become accustomed to the temperature at a certain setting so as not to overheat your PCB and potentially damage components.
There are also numerous videos on youtube regarding homebrew reflow soldering using various techniques including toaster ovens, stove tops, skillets and even hot air guns.
Sparkfun has a few very nice tutorials as well: http://www.sparkfun.com/commerce/tutorials.php (look in the “Surface Mount Soldering Tutorials” section).
I also asked a whole bunch of questions regarding homebrew reflow soldering on the PICLIST. Here are my questions:
1. I thought heat damages components. I was consistently cautioned not to overheat components during hand soldering. If the idea is to heat up the solder just enough to melt (and maybe a bit more so as not to form a "cold soldered" joint), then wouldn't reflow soldering do the same damage to components?
2. One of my DIP chips came with a notice saying that it should be "cooked" at 125 degrees Celsius prior to reflow soldering. I would never reflow solder a DIP chip, but this is interesting. Why do they have such requirements? Is it because of any possibility of trapped moisture in the chip that could rapidly expand in high heat and damage internals? What's the worst case for not obeying this notice?
3. I've also heard of reflow soldering "profiles". What exactly are these profiles? Is it a requirement that I adhere to them for homebrew reflow soldering projects?
4. How do I apply solder paste on pads? Do I just squeeze it out of the tube and rub it consistently over the pads so that all of it is connected? Does a very precise amount need to be applied discretely on each individual pad? How is this done?
5. Where to buy solder paste, are there different types, what brand, what type? Should I use flux? Should I pre-flux the pads or apply flux and then solder paste?
6. I've also heard that it is wise to calibrate or know where your skillet/stove reaches a certain temperature. What temperature is good for reflow soldering? How do I measure this temperature?
7. How long should the PCB be on the skillet/frying pan during the reflow soldering process?
Here are some other questions that I had formed based on the answers given by the PICLIST members:
8. How long does the solder paste usually keep (before it goes bad)?
9. Also, do you recommend closed ovens or open type frying pans/skillets/etc?
I got some very useful and interesting answers from the good folks at the PICLIST. I thank all members of the PICLIST who have taken the time to write detailed replies to all of my questions. Here are some interesting replies from the members:
Answers to Q #1:
Herbert Graf:
Almost all components are DESIGNED for reflow, so no, they won't be
damaged by it, assuming you follow a recommended profile.Joseph Bento:
Yes, heat damages components. It's the way the heat is applied,
however. A solder iron may have a tip temperature of over 400c. At
this temperature, you need to complete your connection quickly or else
risk damaging the component. If you use an oven with paste solder for
SMT components, you will typically limit the temperature to around
200c. Paste solder turns liquid at around 170c. I have hand
assembled many boards with SMT components and have never seen a
component damaged in a 200c oven.Jesse Lackey:
Parts are sturdier than you think. Just don't be on the super hot for a
long time.
Answers to Q #2:
Herbert Graf:
Bingo. Think of a kernel of popcorn. Heat it up, it explodes. Same with
a chip. If you don't dry it out by "cooking" it, it will rupture during
reflow. The main issue is the damage may not even be apparent, very hard
to debug issues could result.Olin Lathrop:
Popcorn.
Answers to Q #3:
Vitaliy:
Profile is basically a temp vs time graph, that shows you what the
temperature should be at a certain point in time. What it boils down to, is
you need to preheat the board at a lower temperature (preheat), then quickly
raise the temperature so the solder paste melts (ramp-up), then cool the
board, but not too quickly (ramp-down).
Answers to Q #4:
Vitaliy:
Take a small syringe, carefully file off the sharp end to make the end flat,
then use it to dispense solder paste. See this page for info on application
techniques:
http://www.seattlerobotics.org/encoder/200006/oven_art.htm
You don't need to be too precise, you just need to dispense the right
amount. Reflowing is self-correcting, to a point.Olin Lathrop:
In real production, this is done with a stencil. The stencil is usually
thin steel of a specific thickness. The solder paste is sortof squeegied
accross the stencil so that it gets wiped off the stencil but blobs remain
in the voids formed by the holes in the stencil. The stencil is then lifted
off the board and just the blobs of solder paste remain.
For one-off home use, you'd probably apply the paste manually with a
syringe, and then expect to fix a few shorts afterwards.Herbert Graf:
The pros have a mask and basically use a silk screen technique to get
the past on the board. While much more time consuming, simply squeezing
the paste on the pads will work pretty much just as well. Don't use
alot, experience will tell you how much. If you use to much chances are
either the joint will be rubbish, or you'll get a sometimes very had to
see bridge.
Answers to Q #5:
Mark Rages:
http://www.dealextreme.com/details.dx/sku.7952
There are more links for where to buy the paste, but I have to carefully dig through the ever expanding thread. There are also lots more answers and questions on the thread, but these are the ones that I felt were most important.
Sunday, March 22, 2009
Peltier Elements
A Peltier element is a metal element which passes heat from one side to the other when a current is passed through the element. So one side gets really cold and the other gets really hot. They’re inexpensive and compact. Solid state as well. Seems interesting, could possibly be used to make a drink cooler or something similar.
Saturday, March 21, 2009
Logic Families
Some information I found on different logic families.
Device Families: TTL (74xx) True TTL 74L Low power 74S Schottky 74H High speed 74LS Low power - Schottky 74AS Advanced - Schottky 74ALS Advanced - Low power - Schottky 74F(AST) Fast - (Advanced - Schottky) 74C CMOS...................check Vcc levels 74HC (U) High speed - CMOS (Unbuffered output) 74HCT High speed - CMOS - TTL inputs 74AHC Advanced - High speed - CMOS 74AHCT Advanced - High speed - CMOS - TTL inputs 74FCT (-A) Fast - CMOS - TTL inputs (speed variations) 74FCT (-T, -AT) Fast - CMOS - TTL inputs (speed variations) 74AC Advanced - CMOS 74ACT Advanced - CMOS - TTL inputs 74FACT AC, ACT (Q) series 74ACQ Advanced - CMOS - Quiet outputs 74ACTQ Advanced - CMOS - TTL inputs - Quiet outputs Bus Driver Families 74ABT Advanced - BiCMOS - Technology 74ABTE ABT - Enhanced Transceiver Logic 74ABTH Advanced - BiCMOS - Technology - bus Hold 74BCT BiCMOS - TTL inputs 74BTL Backplane - Transceiver - Logic 74GTL Gunning - Transceiver - Logic 74GTLP GTL Plus Low Voltage Families 74ALB Advanced - Low Voltage - BiCMOS 74LV (U) Low - Voltage (Unbuffered output) 74LVC (R) (U) LV - CMOS (damping Resistor)(Unbuffered output) 74LVCH Low - Voltage - CMOS - bus Hold 74ALVC Advanced - Low - Voltage - CMOS 74LVT (R) (U) LV - TTL (damping Resistor(Unbuffered output) 74LVTZ Low - Voltage - TTL - High Impedance power-up 74ALVC (R) ALV - CMOS (bus Hold) (damping Resistor) 74ALVCH Advanced - Low - Voltage - CMOS - bus Hold 74LCX LV - CMOS (operates with 3v & 5v supplies) 74VCX LV - CMOS (operates with 1.8v & 3.6v supplies 4000 True CMOS (non-TTL levels) ECL Device Families: MEC I 8nS* MEC II 2nS* MEC III (16XX) 1nS* .......* = Rise & Fall Times 101xx 100 series 10K ECL, 3.5nS* 102xx 200 series 10K ECL, 2.5nS* 108xx 800 series 10K ECL, voltage compensated, 3.5nS* 10Hxxx 10K - High speed, voltage compensated, 1.8nS* 10Exxx 10K - ECLinPS, voltage compensated, 800pS* 100xxx 100K, temperature compensated 100Hxxx 100K - High speed, temperature compensated 100Exxx 100K - ECLinPS, temp, voltage comp., 800pS*
QtCreator – Trolltech’s Own IDE
I didn’t find out about this amazing IDE until I was browsing for themes for my KDE 4 desktop on kdelook.org and saw an interesting looking icon in one of the theme screenshots. Curious, I googled the icon name (qtcreator) and was pleasantly surprised to find out that it was Trolltech’s own IDE for Qt.
It’s amazing. Really easy to make anywhere from quick and simple GUIs to complete and complex applications. The source editor is really cool too. The IDE looks nice, loads fast, feels slick and is available for Linux, Windows and Mac. Completely free.
Download: http://www.qtsoftware.com/downloads
More Hobby PIC18 Devices
The best hobby chips are: (spaces added in part numbers for readability)
- PIC 18 F 26/46 20 – Very robust, but a bit more expensive ($5.50), 100 K flash write cycles (the two below only have 10 K flash write cycles)
- PIC 18 F 26/46 K 20 – Low power
- PIC 18 F 26/46 J 50 – Low cost ($3.30), 2 – 3.3 V, 5.5 V tolerant digital inputs, USB, peripheral pin select, RTCC
- PIC 18 F 2550 – USB
The 18F26J50 definitely seems cool. Note that the 46 models (as opposed to the 26 models) have higher pin counts and therefore, more ADC channels. Both come in DIP packages – very hobby friendly. The only trouble with the 18F26J50 is that it has a maximum voltage of 3.3 V.
Thursday, March 19, 2009
Microcontrollers for Hobby Purposes
If you want to dive right into the art of electronics and microcontrollers, choosing the right chip might be a bit difficult. Microchip alone offers hundreds of different microcontrollers with many different cores and series. In today’s post I’ll list a few good microcontrollers that are inexpensive, readily available, have lots of RAM, flash and onboard peripherals.
I’ll start off with Microchip’s microcontrollers. Generally known as PIC microcontrollers, they’re one of the most popular (if not the most popular) series of microcontrollers out there. However, there are many different series of microcontrollers that Microchip offers.
- 10F – these are the lowest of the low end of PIC microcontrollers. They’re generally used for very specific purposes in large production quantities since they’re extremely cheap. Stay away from these as they have very little flash and RAM.
- 12F – these are known as the low end PICs. Not many onboard peripherals but a reasonable amount of flash and RAM.
- In this series, it’s good to buy a handful of the 12F683 chip.
- 16F – these are known as the midrange PICs and are probably the most popular hobby microcontrollers. Inexpensive, a solid amount of flash and RAM, good pin count, lots of onboard peripherals.
- A good chip to buy here is the 16F886.
- 18F – these are known as the high end PICs and have lots of RAM and flash. They’re slightly more expensive but since we’re not dealing with production quantities of 100 000 chips, cost is negligible. Lots of onboard peripherals, lots of RAM and flash. The extra flash and RAM is well suited for C compilers as well.
- Go for the 18F2620, which is pin compatible with the 16F886 but boasts a lot more features.
- 16 bit series – these are also really cool and are 16 bit but I don’t really see a reason to buy these over the 8 bit chips outlined above. However, Microchip does offer the C30 compiler for these chips which is based on gcc so there are a few advantages.
- 32MX – these are Microchip’s top of the line 32 bit microcontrollers. They cost around $10 each for the highest end models but the PIC32MX(360|460)F512L has 512 K flash, 32 K RAM and comes in a 100 pin TQFP package. They’re really fast, powerful, energy efficient and you can do pretty much anything with them.
- Since they come in a 100 pin TQFP package, they may be a bit hard to solder and do not fit on breadboards, so I recommend getting a 100 pin TQFP adapter from Futurlec, or even purchasing a UBW32 development board.
- Go for the highest end chips, the PIC32MX360F512L for the regular and the PIC32MXF460F512L for the model with an onboard USB module.
All in all, the 16F886 and 18F2620 are two cool chips that any hobbyist should have.
Oh, and don’t forget the PICKIT2.
Wednesday, March 18, 2009
Rorschach’s Quotes (from Watchmen [2009])
(In Rorschach's Journal) Dog carcass in alley this morning, tire tread on burst stomach. This city is afraid of me. I have seen its true face. The streets are extended gutters and the gutters are full of blood and when the drains finally scab over, all the vermin will drown. The accumulated filth of all their sex and murder will foam up about their waists and all the whores and politicians will look up and shout "Save us!"... and I'll look down and whisper "No." They had a choice, all of them. They could have followed in the footsteps of good men like my father or President Truman. Decent men who believed in a day's work for a day's pay. Instead they followed the droppings of lechers and communists and didn't realize that the trail led over a precipice until it was too late. Don't tell me they didn't have a choice. Now the whole world stands on the brink, staring down into bloody Hell, all those liberals and intellectuals and smooth-talkers... and all of a sudden nobody can think of anything to say.
None of you understand. I'm not trapped in here with you. You're trapped in here with me.
There’s probably more good ones. I’ll add them as I find them.
Thursday, March 12, 2009
Prototyping Wire
For breadboards, use thin, single-stranded copper wire. It bends and holds into various shapes and can easily pierce into the breadboard holes. However, for prototyping with copper strip boards such as Veroboards, stiff, single-stranded wire is not ideal. Instead, use thin, multi-stranded wire because it bends around stuff easily and does not get in the way. Also should be very easy to solder once you tin the tip of the wire. Be sure to twist the end of the wire when you strip it.
Tuesday, March 10, 2009
SPI Modes in CCS C
When interfacing SPI devices, the appropriate SPI mode should be used. The SPI modes are described here in detail: http://en.wikipedia.org/wiki/Serial_peripheral_interface
Here are some easy to use defines for use with the CCS C compiler in the setup_spi() function:
#define SPI_MODE_0_0 (SPI_L_TO_H | SPI_XMIT_L_TO_H) //SPI Mode 0 #define SPI_MODE_0_1 (SPI_L_TO_H) //SPI Mode 1 #define SPI_MODE_1_0 (SPI_H_TO_L) //SPI Mode 2 #define SPI_MODE_1_1 (SPI_H_TO_L | SPI_XMIT_L_TO_H) //SPI Mode 3
Just put them in a header or source file somewhere and call setup_spi() like this:
setup_spi(SPI_MASTER | SPI_MODE_0_0 | SPI_CLK_DIV_4);
Note that SPI Mode 0 is a typical SPI mode. The AS1107 uses it, for example. I think it’s the most common SPI mode.
Sunday, March 8, 2009
My First CCS Program – 16F690 on Low Pin Count Demo Board (PICKIT2)
Here’s my first real CCS program. It’s for the 16F690 on the low pin count demo board that comes with the PICKIT2. All this program does is read the voltage on RA0 provided by the trimpot and show the 4 most significant bits of the result on the LEDs. Simple, elegant, easy and it works. CCS is really cool once you get it set up the way you like.
Source: http://pastebin.com/f3516334c
Header: http://pastebin.com/f796e3258
CCS Annoyance Update
Update: the progress popup window can be suppressed. Just go to Project Options > Output Files and you’ll see the option. You can even make it default for new projects. Source: Matt Pobursky from the PICLIST.
More About CCS C Compiler
- When compiling a project, an annoying progress dialog pops up and stays for a few seconds after the compilation process has completed. Annoying.
- CCS C compiler integrates well into MPLAB, so you can bypass the annoyance above. However, MPLAB does not come with the awesome project wizard, which brings us to our next point:
- The project wizard doesn’t let you make modifications to your existing project. It only lets you create a new one.
EXT4 is FAST
I decided to reinstall ArchLinux on my 4 year old Dell Inspiron 6000 laptop today. For the record, the specs of my laptop are as follows:
- CPU: Intel Pentium M 750 @ 1.86 GHz
- RAM: 1 GB DDR2 dual channel
- Screen: 15.4” 1680x1050 resolution
I decided to install a default ArchLinux install using the EXT4 filesystem. I kept most of the options default but installed a few extra packages such as GNU dev tools as well as wireless drivers. As far as partitioning is concerned, I used 4 partitions (/, /home, /boot, swap), all EXT4 except for SWAP. I installed from the 2009.2 USB images. The install completed very quickly – partly because I installed from a USB memory stick as opposed to a CD/FTP and because the filesystem was EXT4.
The installation completed successfully and I rebooted. I pulled out a stopwatch and started the timer just as I hit the enter button on the GRUB ArchLinux menu item. After exactly 10 seconds, I was fully booted into a BASH shell. EXT4 is extremely fast. My previous install took around 16 – 20 seconds to boot into a minimal BASH shell.
Can’t wait to setup a desktop environment and see how long it takes to get into it. In comparison, my windows XP (I’m dual-booting) boot time is around 25 seconds to get into the desktop. It takes at least 18 seconds to boot to the graphical login.
EXT4 is truly fast. Hopefully Ubuntu 9.04 will have EXT4 as an option. For those of you considering installing EXT4 – go for it. It’s fast, stable, and there are/will be a lot of useful tools for it including online defrag.
Friday, March 6, 2009
AS1107 LCD Driver Chip Interface Code for C18
I was unable to find any code to interface this chip on the Internet. However, there were a few people with videos demonstrating its use. After contacting them, borrowing a few of their driver ideas, and writing my own driver, I was finally able to get this chip to work. Here’s my driver.
- Written for Microchip C18 compiler. Can easily be adapted to other compilers.
- My chip is an 18F2620, however, the code can work with almost any PIC.
The code is pretty much self-explanatory. The headers are where everything is defined and where the user is able to define pin assignments.
Download: http://www.mediafire.com/?5jjjzz2jitj
Thursday, March 5, 2009
DIY Automatic Precision Wire Cutter for Prototyping – Part 2
In the previous post, we examined a possible set of features and design goals for such a device. However, the feature set and design goals are difficult to implement. So here’s idea #2. The design is greatly simplified and has less feature. However, it should be much simpler to make.
The device will consist of a set of wire feed rollers, a wire cutter and a wire insulation stripper head. Since it is difficult to design a device that will fully remove the insulation off of the end of the wire, this design will not incorporate such a feature. Instead, this design will use the insulation stripper head to pinch (effectively cut) the insulation near the end where it should be stripped off. After it has pinched both sides, the cutting head will cut the wire. The wire will fall out and is almost ready for use. However, the insulation has not been stripped from the end; it has only been pinched. It is now very easy to remove the insulation by hand with your fingernail since it has already been cut. Here is a diagram of the design:
How it works:
- Wire is fed into the wire feed rollers. The wire then goes into the thin tube in the middle which aligns the wire properly.
- The wire is further rolled out until it reaches the insulation pinching head. At this point, a little more wire is pushed out (about 5 mm) so that the insulation can later be stripped off.
- The cutting head then does its job by pinching the insulation so it can be pulled off easily by your fingernail.
- More wire is fed. The amount that is fed is equal to the desired length of the wire.
- Once the desired length of wire is fed, the insulation pinching head once again pinches the wire.
- Now more wire is pushed so it can advance to the cutting head. The cutting head finally cuts the wire (end product) which then drops out of the machine.
This design is a lot simpler because it requires a lot less parts. Stepper motors and motor drivers can be found anywhere. The insulation pinching head can be acquired by dismantling a hand-operated wire cutter which can be found anywhere as well. The cutting head can be made out of anything – even cheap wire cutter pliers if desired.
The whole device can be controlled by direct connection to a computer or by a PIC microcontroller.
DIY Automatic Precision Wire Cutter for Prototyping - Part 1
One of the most annoying things while prototyping using solderless breadboards, prototyping boards, Veroboards and so on is cutting your wires at just the right length to make a perfectly straight connection. Sometimes, you may need a small piece of wire that will connect points 2, 3 or 4 holes across. If you have many of these, the wire cutting process itself will consume most of your time.
Well how about a DIY computer-controlled machine that will cut wire, strip it and bend the ends at a 90 degree angle for you at just the right length? Pretty neat, huh?
Design goals:
- Inexpensive to build.
- Easy to build.
- Fast to build.
- Easy to set up and use.
- Compact and portable.
- Can either be controlled by a microcontroller + LCD + keypad user interface for stand-alone use or can be controlled by direct connection to a computer.
Functions:
- User provides a continuous supply of wire to the machine.
- User then selects the length of the wire and length of the contacts.
- Machine cuts length of wire (= desired length + contacts length).
- Machine then strips the ends of wire of insulation to expose the copper. This is done with respect to the desired contact length chosen by the user.
Already the design of the machine becomes quite complex. More details to come in the next post.
Monday, March 2, 2009
CCS C compiler is not as bad as I thought…
In the past, I had believed that the two best C compilers for PIC microcontrollers were made by HI-TECH and Microchip. I didn’t give much thought to CCS C as there are many other PIC C compilers in the market. I was pleasantly surprised when I gave CCS C a try.
Pros:
- Very easy to get started with and use.
- Produces compact code.
- Huge built in library of functions for peripherals and so on.
- Large user-submitted forum code library and large user base.
- Great support for many PIC devices from the low end 12 bit PICs (PIC10F) to the 14 bit PICs (PIC12F, PIC16F) to the high end PICs (PIC18F) to the DSPICs.
- Powerful command line interface for the compiler.
- Runs on Windows and Linux natively, (no need for WINE). However, the Linux version is lagging behind two updates (Linux: 4.085; Windows: 4.087).
- MPLAB integration.
- Well documented user manual – easy to read and understand.
- Good support for data types, but could be improved (for example, by adding 64 bit data types).
Cons:
- Horrible, ugly, and otherwise inaccessible and intrusive user interface. Although beauty is in the eye of the beholder, I strongly believe that they could have made their IDE more pleasant to use by:
- Using a standard widget set and not their horrible custom MS Office 2007 knock-off.
- Making things easier to access by placing accessible buttons that perform common actions (open datasheet, open compiler manual, etc.)
- Can be buggy sometimes and can be frustrating when you’re searching for a problem in your code and it’s actually the compiler’s fault. The CCS team needs to be a bit more careful with their updates.
All in all, the extensive code library and shallow learning curve make this compiler very suitable for hobby projects where you can actually spend time working on your project and not worrying about hunting down libraries or writing lengthy drivers.
DS12887 (DS1287) RTC Chip Driver Writtin in CCS C for PICs
Here’s a driver for the DS12887 (or DS1287) RTC chip written in CCS C for PIC microcontrollers. The code can easily be ported to C18 or HI-TECH C. Should be useful for my chip.
Dell Laptop CPU Frequency Scaling and Fan Control
SpeedswitchXP is a CPU frequency scaling utility for Windows XP which allows the user to select power profiles. I leave mine to dynamic when on both external power and when on battery. So far, it’s doing a great job keeping the laptop cool and quiet by reducing CPU speed when the processing power is not required (which is about 95% of the time). Now the fan never turn on high.
I8kfan is a fan control application that allows the user to set fan speed profiles. Make sure you don’t force your fan speed too low or the heat can damage components. I don’t use this currently as I let Windows manage my fan speed, but it’s a useful utility to have.
Friday, February 27, 2009
LED Fan Clock
Tuesday, February 24, 2009
Interesting Maxim Chips
Build Your Own Clock
- A PIC microcontroller (16F886 seems like a good choice; a 12F683 can also be used).
- A 32.768 kHz crystal for timing (can be used as the primary clock source as well as timer clock source for the PIC).
- A display. For this purpose, an LED Matrix display or LED 7 segment display can be used. A very low power static LCD can also be used if low power consumption is part of the design goal.
- Shift registers can be used to drive the LED displays.
- Optionally, a system to synchronize to local low-frequency radio time signals can be added.
- A light level sensor can be used to automatically adjust LED brightness based on ambient light levels. Should be dim during the night and bright during the day. (Possible use for a photoresistor hooked up to the ADC on the PIC?)
- Include a user-programmable alarm.
- Include a calendar.
Monday, February 23, 2009
Oscilloscopes
Make a clock using a 32768 Hz crystal and a low end PIC
1Hz Clock Generator using PIC12F675 Clock with 32.768KHz Crystal
Sunday, February 22, 2009
Multivibrator
A multivibrator is an electronic circuit used to implement a variety of simple two-state systems such as oscillators, timers and flip-flops. It is characterized by two amplifying devices (transistors, electron tubes or other devices) cross-coupled by resistors and capacitors. The most common form is the astable or oscillating type, which generates a square wave—the high level of harmonics in its output is what gives the multivibrator its common name.http://en.wikipedia.org/wiki/Multivibrator Can be used to build oscillators, touch switches, flip flops and so on.
Friday, February 20, 2009
Displaying custom 5x8 characters on your HD44780 LCD
Step 1: Send the Command
To define your own custom characters, you simply write to the character RAM. To do this, simply send the command (0x40 + address). The address can be anywhere from 0 - 63 as there are 64 bytes available for use. To start out, simply set the address to zero. So, send the instruction (0x40). I have my code set up like this:
send_cmd(0x40 + 0);
Step 2: Send the Data
You are now ready to start sending data to the LCD module to define your own characters. Each of the LCD blocks is composed of 5x8 pixels. Each row of pixels, top to bottom, represents one byte. Since each row only has 5 pixels, only the lower 5 bits of each byte you send will be considered by the LCD module. So, to start defining a character like the one shown here, you will need to now send the following data like this:
send_data(0b00000);
send_data(0b00100);
send_data(0b00010);
send_data(0b11111);
send_data(0b00010);
send_data(0b00100);
send_data(0b00000);
send_data(0b00000);
The character RAM pointer will auto-incriment so you don't have to keep setting the address. Just send the data. The above 8 bytes define the first character. To define another character, just directly send another 8 bytes representing your second character.
Step 3: Use Your Characters
To use your freshly-created custom characters, all you have to do now is set the display address back to a valid position on the LCD screen and send your character. Every character you define has an ascii value of 0 - 7. For example, to display your first character, send the number 0x00 as data. If you have a second, third or fourth (or so on) character defined, send data 0x01, 0x02, 0x03 (and so on). I have my code configured as follows:
set_cursor(2, 1);
send_data(0x00);
This will display our custom character.
Here's a complete program that puts it all into context:
http://pastebin.com/f3fb04ca
The above program utilizes my HD44780 C18 Driver Code.
Thursday, February 19, 2009
Tiny ARM Embedded Linux Computers
Great Electronics Books
Wednesday, February 18, 2009
Two more radio transceivers from Futurlec
Tuesday, February 17, 2009
Popular Shift Register with Enable Pins
- 74HC595 - 8-Bit Shift Registers with Output Latches - Datasheet at Futurlec - $0.50 each.
- UCN5832 (a bigger version of the 595)
Great Electronics Stores to Buy Parts
Sunday, February 15, 2009
Turbocharge Your PIC with PLL
The PIC18 series have a maximum internal oscillator frequency of 8 MHz, which translates to 2 MIPS. However, the PIC can run at much higher speeds (especially when using an external clock source). Using the PIC's PLL, one is able to multiply the clock source by up to 4 times. This is even software-controllable if using the internal clock source. Using the maximum speed of the internal oscillator, the PIC can run at up to 32 MHZ with PLL enabled. This yields blazing fast performance of 8 MIPS. Best of all, you can turn this feature on or off as you please to control power consumption. Using the PLL is very easy.
We must first ensure that we are using the internal oscillator. So, in C18, declare a configuration option like this:
#pragma config OSC = INTIO67
Next, we must either configure the internal oscillator to run at 4 or 8 MHz. The PLL will not be enabled on any other configuration. Since we're opting for speed here, let's set it at 8 MHz. Put the following as the first line in your main() function:
OSCCON = 0b01110000;
Note that the last two bits of OSCCON must be 00. And finally, to enable the PLL, add the next line right after:
OSCTUNE = 0b01011111;
This enables the PLL and runs the PIC at the maximum possible frequency using only the internal oscillator - 8 MIPS @ 32 MHz. To toggle the PLL on or off, simply set OSCTUNEbits.PLLEN to either 1 or 0, respectively. Refer to the datasheet for information on how to fine-tune the PLL.