I use Eclipse as an IDE. I do this to get code completion and syntax highlighting, as it does those pretty well for C/C++. Recently, I was trying to write a ROS plugin, and Eclipse couldn’t find the ros.h header file, which I had included with the line
#include "ros/ros.h". Because of this, it marked every line where there was any use of anything from that header as an error, and gave a warning on the include line. They were not errors, and the code still built fine, but the IDE displayed it wrong. To fix this, I tried the normal solution, which is:
Click Project -> Properties -> C/C++ General -> Paths and Symbols -> Includes -> GNU C++ and then use the Add button to add the path to the include file. After that, reindex the project by right-clicking on the project, clicking Index -> Rebuild, and the include should be resolved.
Unfortunately, it wasn’t. Restarting Eclipse didn’t pick it up.
These instructions suggested that it might be something wrong with my language settings, but that doesn’t work either.
This is the proper way of doing it, and it actually works.
Now my tools are out of the way and I can start work. At 5:00PM on Friday.
Version one of the ToyBrain boards had a bunch of problems:
- TX and RX were swapped on the serial line header
- The ICSP header was backwards
- There was no debug LED
- The SMD resistor pads for the reset pull-up resistor were too small
- The connection for the reset switch was a 0.1″ header rather than a proper footprint
- There was a lot of wasted space
Despite all of that, I managed to eventually get them working, with a slowed-down version of the Arduino bootloader, adapters for the ICSP and serial headers, and much messing about.
The new board is smaller, measuring about 1.5″ by 1.28″, and adds a proper reset switch, a SMD LED for debugging, corrected resistor footprints, and a (in my opinion) slicker layout. I still didn’t add voltage regulation or mounting holes, but I may be able to get a little space for the holes by moving a few traces in the corners of the board.
My ToyBrain boards are programmable over ICSP, but when I connect them to an FTDI USB-to-serial cable, I can’t load a program into them from the Arduino development environment. The error I get back is that the programmer is not responding, which could be caused by several things, listed here by increasing order of how tedious they are to check:
- I might have some misconfiguration on the USB ports or Arduino IDE. I can eliminate this possibility by using the same FTDI cable to program a known-working Arduino BBB. If that works, I know that my problem is off the end of the FTDI cable, in my own hardware.
- I tried this, and got a working blinking light program on my BBB. This means my cable and computer are fine.
- I might have messed up the bootloader configuration for my board. I think this is somewhat likely, as I’m using the Arduino bootloader on a board that is running at 8MHz. If the Arduino bootloader or IDE requires the Arduino 16MHz crystal for proper timing, it is now running at half the normal clock speed, resulting in the serial timings being double what they should be. I can test this by telling the IDE to attempt to talk to the board at half of whatever the normal speed is, using the platform support in recent Arduino IDE releases. If it’s a timing issue, that should fix it.
- This was the problem. I reflashed with the 8Mhz bootloader from here, and now I can load programs and have them run.
- I might have screwed something up in the reset or power circuitry of the Arduino (I already know I got TX and RX backwards). I can check out the connections with a voltmeter pretty easily. I can also burn an LED blink program to the board with ICSP and see if it runs.
- The power and reset circuitry is fine. I burned a LED blinking test program to the board using the command avrdude -c usbtiny -p m8 -U flash:w:test.hex and got a square wave on port B, so the chip is running code and the fuses make at least enough sense that the onboard oscillator starts.
- I may have used bad fuse settings, and put it in some mode that doesn’t result in the bootloader starting. I can test this by burning my own LED blink program to the bootloader section and seeing if it blinks an LED. This won’t make it load code, but it will at least confirm that the bootloader is getting started.
- This is covered by the previous section. The chip isn’t bricked, and it runs code.
When I added the ICSP header to my ToyBrain boards, I mirrored the footprint so that some of the routing would be easier. I did not, however, correct the actual wiring, so now the ICSP header comes off the wrong side of the board.
This is going to be easy to fix in the next revision, but for now I’m going to roll up a little adapter to get the boards programmed.
More later, when it’s closer to noon than midnight.
The ToyBrain boards arrived. I have populated four of them with programming headers and microcontrollers. Two have ATMega8 chips, the other two have ATMega48 chips that I salvaged from some thermostats that I found.
I haven’t bothered fully populating the boards because I want to check that the ICSP headers are working by burning the Arduino bootloader to the chips, and that the serial headers are working by loading a program from the Arduino IDE.
Assuming that I haven’t miss-designed the circuit boards or baked the chips while soldering them, this will provide a smoke-test for the computer side of the boards. I still need to get a bunch of SN754410NE quad half-H-Bridge motor driver chips to handle the output side.
So far, I’ve come up with quite a few applications for the little boards:
- Re-animating gutted toys with new programming
- Controlling a single stepper motor with step/direction signals and limit switches
- Driving up to 4 channels of medium-current LED lights (RGB plus white?)
- Making loud noises by using the quad half H-bridges as push-pull speaker drivers
- Solenoid drivers and control hardware for chimes
I’m very eager to get a few of the boards out to beta testers and see what other people come up with.
The PCBs for my programmable toy controllers are on their way to me. That means that I didn’t mess up the layout in some way that makes it impossible to make the boards, but doesn’t preclude me possibly getting something wrong in the design. I’m going to assemble a few when they arrive and shake them down for layout defects. I also have a beta tester who wants to use one.
One thing I’m considering for the next version is adding an on-board voltage regulator, but that usually calls for caps as well, and starts to drive the board size and price up. I should also add mounting holes, but again, those take board real estate. I may neaten up the connector layout, and make sure everything is on 0.1″ centers for ease of mounting with normal pin headers. If I get all the through-hole connections moved to the edges of the board, or add edge connectors that make good wire lands and good header connections, I may be able to shrink the board more and not have many pins sticking through it. That would mean it would have a smooth bottom, and so be easy to mount with double-sided tape.
I have a bunch of old toy skeletons sitting around. They are not toy versions of the bones of animals, but the frameworks and some of the motors from things like a toy tracked robot, an RC truck, a few toy robot insects, some tiny RC cars, a robot base with continuous-rotation servos, and so forth. All of these things have motors or servos in them. All of them need some form of controller to make them into autonomous robots to do my bidding (or wander around banging into things).
To that end, I’ve developed a little embeddable controller around the ATMega8, ATMega48/88/168, and other pin-compatible microcontrollers. That is the same chip used in the Arduino, so my board will be software-compatible with the Arduino as well.
My controller, which I’m calling ToyBrain, has a pair of 1A (stackable for more current) H-Bridge motor drivers, so it can control up to four motors in one direction, two motors bidirectionally, or one stepper motor. It also provides two headers for servo motors. For inputs, it has four analog or digital inputs and two digital inputs that are connected to interrupt lines, so it can do things like handle bumper switches in an interrupt service routine.
I’ve ordered 10 boards. When they arrive, I’m going to populate them with whatever chips I have around and try to get a few of my old toys running. Assuming everything goes well and I get a polished device together over the winter, this may end up being something I sell at the MIT flea regularly. I’ll hook up a bunch of toys with the same controller, to show off its versatility, and offer the controller as a kit people can buy.