Feed on
Posts
Comments

DS1307 is an old and classic real-time clock (RTC) chip that has been used in many electronic circuits. There are also many libraries written for DS1307, notably this Arduino Time library which includes a DS1307RTC class. Given its age and popularity, it’s surprising that the chip is not cheap: even at volume pricing, it usually costs around $2 each. Even a microcontroller like ATtiny45 costs only about about 60 cents. How complicated can an RTC chip be compared to a microcontroller!

Recently I came across Microchip’s MCP7940N, which is less expensive and is pretty much a drop-in replacement of DS1307. At a quantity of 100, it costs 65 cents each, which is about a third of the price of DS1307. To be fair, there are even cheaper options, but those often do not have battery backup support, which would not be desirable.

IMG_3832

Microchip has published a DS1307 to MCP7940N migration document which thoroughly explained the differences between the two. To begin, Microchip recommends adding a few extra elements, such as load capacitors for 32.768kHz crystal, and protection circuitry for the backup battery. If you are not so concerned with this level of reliability, you can leave out these elements and hence it will be truly a drop-in replacement.

Next, there are a few software changes we have to make, mainly three:

  • I2C address: MCP7940N uses address 1101111 while DS1307 uses 1101000.
  • Clock enable: MCP7940N uses active high while DS1307 uses active low.
  • Battery backup: MCP7940N disables it on startup while DS1307 always enables it.

These changes are fairly easy to make. So I modified the DS1307RTC library to accommodate both. The library can automatically detect which RTC chip you have. Using the modified library, you need to first run RTC.detect() to detect whether an RTC chip is installed and which one it is. The detect() function returns 0 if either DS1307 or MCP7940N is detected, and a non-zero value if an error has occurred. The rest is the same as before.

This library can replace the one included in Arduino’s Time library. Note that it also works for DS3231, which is compatible with DS1307 but with a built-in temperature compensated crystal.

That’s all. Next time you need an RTC, perhaps you will consider using MCP7940N as an inexpensive alternative to DS1307 🙂

This is a long delayed post. I am glad I finally finished making a video for it, and it’s time to introduce SquareWear 2.0 — an open-source, wearable Arduino microcontroller board. At heart, SqureWear 2.0 is an Arduino running at 3.3V and 12MHz. It has built-in mini-USB port for uploading programs, charging lithium batteries, and creating a serial communication channel. It comes with a lot of useful built-in components, such as a color LED, a general-purpose push-button, a buzzer (yup, you can make it sing a tune), light sensor, temperature sensor, three MOSFETs (to drive high-current load). Even better, it has a built-in rechargeable lithium coin battery (you heard it right: rechargeable coin battery!), so you can power your project right away without requiring external power supply. Every time you plug in the mini-USB cable, it charges the coin battery automatically. Better still, if you want a beefier battery, you can plug in an external lithium battery through the on-board battery jack. The built-in lithium charger can charge external battery as well. Overall SquareWear 2.0 packs a lot of useful features on a 1.7″ x 1.7″ board. It’s great for wearable electronic projects as well as general-purpose microcontroller projects. Below is a summary of built-in components:

  • ATmega328 running at 3.3V, 12MHz.
  • MCP1700 3.3V / 250mA LOD.
  • MCP73831 lithium charging chip (configured to charge at 35mA).
  • MCP9700 temperature sensor.
  • 10K photo-resistor.
  • Four 2N7002 MOSFETs.
  • 5050 color LED.
  • 8.5mm SMT buzzer.
  • 6mm SMT tactile button.
  • Charging indicator LED.
  • LIR2032 rechargeable lithium coin battery (45mAh capacity).
  • 2.0mm JST connector for external lithium battery.
  • SMT mini-USB port, and power switch.

IMG_2856IMG_2861IMG_2858

squarewear2_annotation

Last year around this time I released SqureWear 1.1, which is based on Microchip’s 18F14K50 microcontroller. It’s pretty neat, but over time I’ve received quite a few requests to develop a similar board based on the Arduino. This inspired me to work on SquareWear 2.0. Many design choices, including components I selected to put on board, were based on feedback and experience at various wearable electronics workshops I organized.

With SquareWear 2.0, programming is now done through the Arduino software. You can make use of thousands of available Arduino libraries to help build your project. Similar to the standard Arduino, it is based on a ATmega328 microcontroller. However, SquareWear does not have a separate USB-to-serial chip. Instead, it simulates USB functionality all in software, using the V-USB library. It has a USBasp bootloader, and can perform serial communication through USB. It can also simulate a mouse, a keyboard, or other human interface devices (see V-USB example projects). While software-based USB is not that fast, it really helps reduce the cost and size of the board by having one chip to carry out all the tasks. That’s why we can offer SquareWear 2.0, with all the aforementioned components and features, at a very competitive price.

The bootloader is based on Frank Zhao’s USnoobie project. To enter programming mode, press and hole the on-board tactile button, then turn on power. This will allow the microcontroller to bootload as a USBasp programmer, which is supported by Arduino. On Linux and Mac, you don’t need to install any driver; on Windows, you need to install the USBasp driver (come on, Microsoft!), which is included in the SqureWear software package. The board has internal assignments for the following pins:

  • D2/D7: USB D-/D+.
  • D4: tactile button.
  • D8/D12/D13: LED red/green/blue channel.
  • D9: buzzer.
  • A0/A1: light/temperature sensor.

The other pins are all mapped out to sewable pin pads with large holes. You can either stitch conductive threads through the pins, or solder wires directly onto the pins, or solder snaps to make it easy for quickly attaching or detaching the board from fabric.

IMG_2859IMG_2860

I should mention that pins D3, D5, D6 are internally connected to n-channel MOSFETs and these pins are suitable for driving high-current load (up to 250mA each pin). This is very useful if you want to switch a large number of parallel LEDs, a motor, a muscle wire, a heat wire etc. You can even combine two or three of them together to drive higher current. If you are familiar with Arduino, you should know that these three pins also support hardware PWM, so you can use them to control the brightness of LEDs, the speed of a motor etc. Technically I call them ‘power sink pins’ because unlike a standard output pin, they can only connect or disconnect a component from ground (sink). So the right way to use them is by connecting the positive wire of your component to Vcc (or external power), and the negative wire to one of the MOSFET pins.

Anyways, I want to keep this post short, so I will leave you to find more details in the video tutorial above, and the user manual in the software package. If you are interested in buying SquareWear 2.0, it’s available for purchase at the Rayshobby Shop. Feel free to leave comments below, or on the forum. Thanks!

A reflow oven comes in handy when you work regularly with SMT circuits. I’ve had the T-962A reflow oven for about a year now. While it has worked reasonably well, recently it has started showing some signs of aging. First of all, the total reflow time is quite long, about 15-16 minutes. This is really slow. Worse even, occasionally the internal temperature sensor would have a hiccup and the boards would come out under-heated or over-heated. Also, I hate the built-in buzzer, which produces a very loud, high-pitched beep when reflow is completed. This is very annoying — since I keep the reflow oven outdoors, I didn’t want my neighbors to think the beep is my fire alarm. So it’s time to find an alternative / backup solution.

After some online research, I’ve decided to build a reflow toaster oven using an Arduino-based controller. Toaster oven is cheap and provides better, more even heating than a hot skillet. I know toaster oven reflowing has been blogged about everywhere, but I do want to give my version some bells and whistles to provide more convenience. For example, I typically keep the reflow oven outdoors on my porch while working in the basement. So I’d like to receive a remote notification when reflow is complete (no loud beep please!). Also, I’d like an automatic way to open the oven door and blow air into the oven to accelerate the cooling time. For remote notification, I’ve decided to use an 433MHz RF transmitter to send signals to a remote power socket. I have a lamp connected to the power socket, and this way I will get notified when reflow is done. For faster cool-down time, I will use a servo tied to the oven door handle with a string — rotating the servo shaft can pull the door open. I will also put a second remote power socket connected to a circulation fan to blow air into the oven. Since I am using remote power sockets anyways, I am going to throw in a third one for the oven. This way all power line devices are controlled by power sockets, so there is no messing around with cutting cables etc. If you want better reliability, you can certainly use a relay or an SSR. I just decided to go with RF power sockets for the convenience.


Materials
Here is the list of materials I used:

IMG_3591IMG_3593IMG_3594IMG_3595
I have an existing set of RF power sockets and I don’t remember where I got them. But the link provided above looks similar, so they should work fine. A quick note: there are cheaper RF power sockets which only support toggling, but I would suggest getting the type that has separate on/off buttons for each channel, because you can know for sure whether the socket is on or off. Also, there are some types which work in the 315MHz frequency band. In this case, you need to get 315MHz RF transmitter instead of 433MHz.


Step 1. Temperature Probe
The reflow oven is a temperature-controlled device, so the first thing to do is to have the microcontroller sense temperature. The cheap kitchen thermometer is perfect for this: it has a thermistor (i.e. temperature-sensitive resistor) wrapped around a metal probe. Just open the thermometer, desolder the two wires, and extend the wire length by soldering two pieces of longer wires. I also used some hot glue to fix the joints so they they won’t move around and break.

IMG_3597IMG_3598IMG_3607IMG_3596

Next, measure the diameter of the temperature probe (mine is about 0.147″), and at the back of the toaster oven drill a hole that’s slightly bigger (I used 5/32 drill) than the probe size. The hole should be located at roughly a quarter to one-third on the height, so that when the probe is plugged in it would neither touch the top heating element nor the tray. Next, wrap a layer of Kapton tape around the temperature probe, and insert it through the hole, so that it stays tight in place.

The oven should be set to the highest temperature, convection, and stay on. This way we can bypass the oven’s internal control mechanism and instead use the microcontroller to turn heating on and off.
IMG_3599IMG_3602IMG_3603IMG_3606

For the microcontroller to sense temperature, just use the 2.32K resistor to form a voltage divider with the thermistor (i.e. probe). See the schematic on the right below. The divided voltage is connected to Arduino’s analog pin A0 for reading.

IMG_3608t_volt_divider


Step 2. Temperature Calibration
The next step is to perform temperature calibration. If you’ve got the same kitchen thermometer and 2.32K resistor as I have, you can skip this step. But if you have a different set, you need to perform a calibration step to find out the relationship between the actual temperature with the analog reading. To do so, I used an existing digital thermometer (my EX330 multimeter) to serve as reference. Insert its temperature probe to the oven and get the tip close to the center; then I wrote a simple Arduino program to print out analog values from A0 once every second. Turn on the oven to let it heat up. The temperature will rise, and the analog reading also rises.
IMG_3609IMG_3610IMG_3611

When it reaches about 210°C (Celsius), turn off the oven, and record the analog reading. Then do another reading when the temperature drops to about 170°C, and the last one when it drops to about 80°C. Basically 210°C is when we should stop heating (the temperature will climb up a little more beyond 210), 170°C is when the oven door will open and the fan will kick in, and 80°C is when the reflow is considered finished. My readings corresponding to these three temperature values are roughly 830, 790, and 360. These will be used in the Arduino program later.

IMG_3612IMG_3613IMG_3614


Step 3. Oven Door Opener
Next is a fun step. I built a oven door opener using a servo. The basic idea is to attach a piece of string between the servo and the oven door handle. Rotating the servo shaft will be able to pull the door open. To do so, I picked up some pieces of wood from HomeDepot and build a wooden frame. To make the whole assembly stable, the base of the frame should be sufficiently heavy. Then I secured the servo to the frame using some long #4 screws and nuts. Since the servo doesn’t come with a long shaft, I used a small piece of wood and attached it to the servo gear. This can extend the sweeping distance of the servo. Be careful not to make it too long though, otherwise you may overdrive the servo’s torque.
IMG_3620IMG_3621

The video below shows the servo in action. This is using Arduino’s built-in Servo example called Sweep. The servo’s three pins are connected to 5V, pin D9, and ground.


Step 4. Remote Power Sockets
The next step is to interface with the remote power sockets. I’ve written a previous blog post about this. Since then I have discovered the RC-Switch Arduino library. This is a very useful library that can automatically decode the signal patterns from most common remote power sockets. All that’s required is an Arduino and a RF receiver. I wired up my 433MHz receiver to the Arduino, and used the library’s receiver example to figure out the following binary code for my power sockets:

  • Channel 1 on: 010101010011000101000011; off: 010101010011000101000000.
  • Channel 2 on: 010101011100000101001100; off: 010101011100000101000000.
  • Channel 3 on: 010101010000110101110000; off: 010101010000110101000000.

Once the patterns are figured out, I can then connect a 433MHz transmitter to Arduino to simulate the remote control. This way I can reliably turn on and off each socket individually.


Step 5. Putting Everything Together and Testing
Now all the ingredients are ready, it’s time to put everything together for testing. The Arduino pin assignments are: temperature probe on analog pin A0, servo on digital D9, and RF transmitter on D10. The power sockets assignments are: toaster oven on channel 1, fan on channel 2, and lamp on channel 3. Since the controller will be used outdoors on the porch, I found an enclosure that can fit everything nicely inside. I also soldered a wire to the RF transmitter as an antenna to extend the transmission range. The power comes from an external 5V adapter. Please check the video at the beginning of the post for demonstration. The controller program source code can be downloaded here:

IMG_3622IMG_3623

With the capability of opening oven doors and blow air into it, the cool-down time is significantly faster. The total reflow time is about 6 minutes now, which is a lot better than 15 minutes before. That’s it, my reflow toaster oven with bells and whistles. It can certainly be improved by adding PID control, The hardware cost, everything included, is about $120. It’s inexpensive and pretty easy to replicate. Much better than my professional reflow oven!


Continuing from yesterday’s post, today’s sneak peak preview is for OpenSprinkler DIY v2.1u — the solder-and-assemble-yourself version of the OpenSprinkler.

IMG_3446

This is the first major upgrade of the DIY version since v1.42u. The main differences compared to 1.42u are:

  • The microcontroller is upgraded to ATmega644, doubling the flash and RAM size of ATmega328.
  • Switching regulator changed to LM2596S-5.0, which is beefier than MC34063.
  • Added microSD card slot, space to fit MOVs, and pin headers to fit an RF transmitter.
  • Enclosure is changed to use the injection molded case.

The design is pretty much similar to the fully assembled OpenSprinkler 2.0. To make it easy to solder, some components are been changed to use through-hole version, notably the ATmega644 microcontroller, the ENC28J60 Ethernet controller, triacs, and several capacitors. Due to the limited space (particularly as the through-hole ATmega644 is so much larger than the previous ATmega328), it’s not possible to keep all components in through-hole style. In fact, even with surface mount, I ended up using the trick of hiding some components underneath the microcontroller, as shown in the picture below:

IMG_3449

In addition, the microSD card slot and the LM2596S regulator are not well-suited for hand-soldering. So unlike v1.42u, which uses all through-hole components, v2.1u will be in the form of hybrid SMT and through-hole — The SMT components will be pre-assembled, and the through-hole components will be soldered by users. Strictly this should be called semi-assembled OpenSprinkler.

While the hybrid solution may sound disappointing to DIY lovers, I figured this is still an interesting compromise, as it leaves sufficient flexibility for anyone who wants to tinker with it. For example, the mcu can be easily upgraded to ATmega1284, which is pin compatible with ATmega644 but has 128KB flash and 16KB RAM. Also, the triacs can be replaced by transistors or MOSFETs to interface with DC devices. So we will see if there is enough interest in this new experiment. If you are looking for an all through-hole version, I have to say 1.42u remains the best solution.

IMG_3447IMG_3448

Now, why is this version numbered 2.1? Is it jumping ahead of the fully assembled OpenSprinkler 2.0? That’s right — there are some minor improvements / changes from 2.0, so I figured a new revision number is necessary to tell them apart. Here are the main differences:

First, the ATtiny45 (which functions as a USBtiny programmer) has been removed, partly to save space, and partly to simplify the design. Instead, the ATmega644 will be flashed with a USBasp bootloader, which allows itself to function as a USBasp programmer in bootload mode. This will take away 2KB of flash memory space, but on the plus side, it eliminates one chip, and the transfer speed of USBasp is actually noticeably faster than USBtiny. Additionally, using ATmega644 to directly handle USB tasks (thanks to the V-USB library) makes it possible to add USB serial functionality. As a result, you can do serial communication to debug the code, without any external USB serial converter. So it’s win-win-win 🙂 The details can be found in my previous blog post about USB HID-class Serial Communication for AVRs.

Next, the 24VAC port has been changed to use a new type of screw terminal that has smaller pin spacing and orange color. This will prevent users from accidentally plugging it into the COM or Rain Sensor port, which would damage the controller. A 2amp fuse on the 24VAC line, and a current limiting resistor for the Rain Sensor port has also been introduced for added protection. Finally, a relay has been added on digital pin D14, to allow general-purpose switching need, such as opening garage door, and power line device etc.

Due to these changes, particularly the USBasp bootloader (which requires ATmega644 to run at 12MHz instead of the current 8MHz on OpenSprinkler 2.0), it’s necessary to use a new revision number to avoid confusion.

In any case, the prototype has been verified and I only identified a couple of minor changes to fix. Otherwise it’s pretty much ready to go. It should be available for purchase within a month. So stay tuned!

A month with no new post? That’s unacceptable. Since my last trip to Shenzhen, I actually have quite a few new ideas and projects to post about. The thing is there are so many of them that I don’t know which one to start with! Anyways, I’ve decided to put a stop to this. In this blog post, I will describe some work I did a little while back about implementing HID-class serial communication for AVR microcontrollers using the V-USB library.

Introduction

First, let me explain what I am trying to do. As you probably know, V-USB is a very useful software-only implementation of low-speed USB device for AVR microcontrollers. It adds USB functionality for almost any AVR, particularly for those without hardware USB functionality. With this, it’s possible to make a very low-cost standalone Arduino with USB port and without having to use an FTDI chip. I know there is the Arduino Leonardo, which is based on ATmega32u4, and which has hardware-based USB functionality. But mega32u4 only exists in SMT package, and it’s more expensive than mega328 after all. Besides, I am fully embracing the ‘I do it because I can’ spirit, and this is actually a great motivation for me to learn about V-USB.

What do I need the USB for? Mostly for two reasons. One is to flash a program to the microcontroller, so it needs a USB-based bootloader. For this, there is a very nice open-source project called USnoobie, which can bootload mega328 as a USBasp programmer. This way you can flash a program through the USB port directly, without using a serial cable or an external AVRISP programmer. So this is all good.

The second reason to have USB is for serial communication — the ability to transfer data (e.g. strings) in and out between the device and a host computer through the USB port. This is useful especially for debugging (i.e. printing values to a serial monitor), unfortunately this feature is missing in most V-USB projects. There are some related projects. For example, I came across the AVR-CDC project, which turns a mega328 into a CDC-class USB-serial converter. But there seem to be some limitations of using V-USB to implement CDC (i.e. violates USB standard), and also CDC-class devices require installing a driver on Windows. I would like to make a HID-class USB device which does not require driver installation. So overall I didn’t find any available resource that I can use directly.

Circuit Design and V-USB

Now I’ve explained the motivation, let’s see how to go about implementing it. The first step is to learn to use V-USB. I started with the EasyLogger project downloaded from the V-USB website. It is based on the tiny45 mcu. The program reads a sensor (e.g. temperature or light) and presents itself as a USB keyboard to print out the sensor values to a host computer. This is an excellent starting point for me because USB keyboard is a standard HID-class device, and the project is simple enough that I can easily learn and make modifications.

To adapt it to mega328, I first made a circuit based on USnoobie. Here is the schematic and my build of the circuit on a breadboard:

m328-vusbIMG_3287

It’s a pretty standard V-USB setup. I assigned digital pin PD2 (INT0) to USB D+, pin PD7 to USB D-, and PD4 to a pushbutton. The pushbutton is used to enter bootloading mode. Specifically, if the button is pressed when the circuit is powered up, the bootloader is activated and the mcu will appear as a USBasp programmer. Different from USnoobie, I’ve decoupled this button from the D- line, so that I can use the button for general-purpose input (otherwise pressing the button will trigger the D- line). This requires changing the USnoobie code slightly to use pin PD4 for bootloading condition. Finally, I’ve also added a MCP9700 temperature sensor (you can replace it by any analog sensor such as photosensor) to analog pin ADC0 for testing later.

The next step is to modify the source code. First, change usbconfig.h to match the D+ and D- pin settings, specifically the following three macro defines:

#define USB_CFG_IOPORTNAME      D
/* */
#define USB_CFG_DMINUS_BIT      7
/* */
#define USB_CFG_DPLUS_BIT       2
/* */

Next, modify main.c. This step is pretty technical and tedious. It mainly involves changing register names to match mega328 (since the code was originally written for tiny45). Also, the calibrateOscillator(); function can be removed as the mega328 will be running on an external 12MHz clock.

I also modified the Makefile in order to compile and flash the code for mega328. After a few tweaks here and there, the EasyLogger started working on my mega328! It can successfully output numerical values to a text editor through the USB port. This is very encouraging. If these steps don’t make much sense, you can take a look at the code below, and give it a try yourself.

Learning HID

HID stands for Human Interface Device. It’s a USB class designed primarily for keyboard, mice, joystick, and similar human interface devices. The nice thing about HID is that it’s supported on all operating systems. For example, on Windows, the system uses built-in HID driver to handle USB requests, so no driver installation is required. This is why when you plug in a keyboard or mice, you never have to install a driver (imagine how annoying it would be if you had to!).

To implement HID, you first will need to construct a HID descriptor, which describes the number of reports, and the size, meaning, and (optionally) value range of each report. For example, these reports can be the ASCII code of the pressed key, the x and y offsets, and button presses of the mouse. There are also more general-purpose reports like a buffer of bytes. This is what I will be using to transfer bytes in and out between the device and host. To be honest, the whole USB descriptor thing was very obscure to me in the beginning. I didn’t know if there is one correct way to define it, or it can be flexible. As it turns out, Linux is pretty forgiving about it, but Windows is not. After many trials and errors, I finally settled with this HID descriptor:

PROGMEM const char usbHidReportDescriptor[USB_CFG_HID_REPORT_DESCRIPTOR_LENGTH] = {    /* USB report descriptor */
    0x06, 0x00, 0xff,              // USAGE_PAGE (Generic Desktop)
    0x09, 0x01,                    // USAGE (Vendor Usage 1)
    0xa1, 0x01,                    // COLLECTION (Application)
    0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
    0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
    0x75, 0x08,                    //   REPORT_SIZE (8)
    0x95, 0x08,                    //   REPORT_COUNT (8)
    0x09, 0x00,                    //   USAGE (Undefined)  
    0x82, 0x02, 0x01,              //   INPUT (Data,Var,Abs,Buf)
    0x95, HIDSERIAL_INBUFFER_SIZE, //   REPORT_COUNT (32)
    0x09, 0x00,                    //   USAGE (Undefined)        
    0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
    0xc0                           // END_COLLECTION
};

It contains an outgoing buffer of 8 bytes (to transfer data to the host) and an incoming buffer of 32 bytes (to receive data from the host). As I said above, Linux is pretty flexible about the descriptor — you can change it in many ways and it still works. Windows, however, is very strict — if you are not careful, it will simply refuse to recognize the device.

The next step is to write functions to handle the USB requests. For transferring data out, I used the usbSetInterrupt function, which allows sending data spontaneously to the host (i.e. whenever the device has something to report). (I should mention here that I wrote the code as an Arduino library called HIDSerial. So everything gets compiled in the Arduino software. You can certainly use avr-gcc to compile the code as well). I made HIDSerial an inherited class from Arduino’s Print class, so I can make use of the many available print functions (e.g. print a string, an integer, a floating point) in the class for serial printing need, without writing extra code. For transferring data in, I implemented the usbFunctionWrite function, as described in the V-USB Document Wiki.

Now, before I can test and debug the code, I need to have some minimal host software to communicate with the device. That’s what I will be describing next.

Write Host Software using Processing

Going the HID route means the device will not appear as a standard serial COM port, so you can’t use the standard serial monitor to send and receive values. Instead, I will have to write host software myself. I can certainly do this in C or Java. But since I want to make the host software cross-platform, I have chosen to implement it in Processing, which allows me to easily export the program as standalone applications on all platforms. Long story short, to do this, I used HIDAPI library. It has all the goodies to handle communications with HID devices, such as finding a device, opening the device, reading from the device, and sending feature report to the device. Also, using the G4P library, you can easily build a GUI with buttons and text fields, and make the interface just like a standard serial monitor. Once the software is finalized, I can simply click on ‘Export Application’, and select all three platforms, and voilà, the host software is all set! Below are two screenshots of the HID serial monitor:

hidserialmonitor1hidserialmonitor2

Source Code

The source code of this project is available for download on my GitHub repository:

You can either do a git clone, or directly download the project as a zip file (see the Download .zip button on the right-hand side of the page). The folder contains circuit schematic, part list, Arduino library (HIDSerial), host software (HID serial monitor), and bootloader (optional, but recommended as it allows you to re-flash the microcontroller through USB, without any external programmer). The Arduino library consists of several starting examples, which are also demonstrated in the video above. I am sure there are bugs and issues with the code, but please feel free to leave comments and feedback below, in order for me to improve the code.

Limitations and Issues

The biggest limitation of this implementation is the data transfer speed — it’s much slower compared to a standard USB-serial converter. This will be an issue if you need to pump out data as fast as possible. But I figured that for the purpose of debugging, the transfer speed is usually not that critical. The software works pretty reliably in Linux, but I’ve found that on Windows, the host software starts to lose data after running for a while, so not all data get transferred correctly. Resetting the microcontroller and restarting the host software seem to get it back to work. I am still investigating the cause of this issue. It may still have to do with Windows being very strict with USB communication protocols. Perhaps the USB experts can take a look at the code and point me in the right direction.

Adapting the Code to Other AVRs

It’s relatively easy to adapt the code to other AVRs. For example, ATtiny45/85 is a popular V-USB platform, since it’s small, cheap, and has internal oscillator that can run at 16.5MHz, which meets the USB standard (so it saves a crystal and frees up two pins). By changing a couple of pin assignments in the source code, I was able to get the HID serial functions to work on tiny45. I really should do it on tiny85, since tiny45 has only 4KB flash space (even a simple demo would take more than 3.5K flash space). Here is a picture of the tiny45 breadboard build. You can even program tiny45 in the Arduino software by following the descriptions here.

IMG_3322

Thanks for reading the post. Feedback, comments, and questions are welcome.

« Newer Posts - Older Posts »