The most basic level for this week is to get a premade program working on the circuit boards we designed and assembled. Then make a modification to the code to do something else. In order to make code the microcontroller understands we need to compile the C code into a .hex file using a driver library called
avr-gcc that compiles our code. We then use a program called avrdude in conjunction with a piece of hardware called an In System Programmers (ISP) to flash (in the old days the EPROM memory could be wiped by flashing an intense UV light through a little window on the chip) and program the microcontroller. We can then use an FTDI cable to communicate between the microcontroller and our computer through a usb port.
This process can be done somewhat manually, or with a make file that combines multiple steps. Additionally, we could use the Arduino environment by loading a bootloader and then making use of the Arduino libraries to simplify programming, or if we're real hardcore we could write the Assembler code ourselves.
First I'll explain the simpler avr technique to load files to a microcontroller (uC) using make files, then the more indepth technique, and finally the arduino method. First though we need to verify we have the correct drivers and software for everything to work. As a reference I used the Fab Academy instructions and the High-Low Tech:For windows:
Compile the code - convert the (filename).c files (C-language that humans can read) into the (filename).hex files (Hex language that microcontrollers can read):
make -f hello.ftdi.echo.c.make
make -f hello.ftdi.44.echo.c.make program-usbtiny-fuses
make -f hello.ftdi.44.echo.c.make program-usbtiny
To run the standard code for the class, looking below replace (filename) with
avr-gcc -mmcu=attiny44 -o (filename).out (filename).c
avr-objcopy -O ihex (filename).out (filename).hex
avrdude -p t44 -P usb -c usbtiny -U lfuse:w:0x5E:m
avrdude -p t44 -c usbtiny -U flash:w:(filename).hex
python term.py com6 115200Where com6 would be replaced with whatever your serial port shows up as on your system. Note also, that it maybe necessary to adjust the communication speed parameters in the windows device manager to operate at the 115200 baud rate specified.
I ended up being successful with the project despite an initial issue with communication frequency. I had python already installed on my computer and when I ran the the term.py program I got gibberish on thhe screen. What I realized though was that the gibberish was actually doing the echo as it should, it just was not displaying the correct information. So that meant the microcontroller was infact programmed, but the communication lines were not synchronized. So, looking into how to specify the communication rates in the AVR code I saw the following lines:
#define bit_delay_time 8.5 // bit delay for 115200 with overhead
#define bit_delay() _delay_us(bit_delay_time) // RS232 bit delay
The bit_delay_time is used to specify the delay time in communications channel to synchronize the serial communication. So doubled checked how many microseconds of delay should happen and 1/115200 = 8.68*10^-6, or 8.68 microseconds. So I changed the value to:
#define bit_delay_time 8.68 // bit delay for 115200 with overhead
and then communication seemed to work perfectly.
I made use of the highlowtech folks again with their Attiny as an arduino tutorial. I also tried loading the Arduino bootloader onto the board and running an arduino code on it. This was successful when selecting the USBTinyISP programmer. However the serial communcation was not working correctly. I think I need to do the serial through software on this chip, so I'll need to get into that...later. I decided to jump back to playing with the avr stuff directly.
I wanted a lightweight motor control board that could have a simple potentiometer position feedback loop or potentially a capacitive input device. I'm realizing now, I left one pin unused and I could have made use of that to allow a quadrature encoder input as well. Ohwell, next time. The pain point is that it is neat to have a very low cost motor driver for tiny motors, and including a position feedback loop allows for a precision position control system. Actually, just thinking about it now, that extra pin could also be used to put a tachometer on the output in combination with the potentiometer. This would allow a cleaner velocity measurement for better PD control. The reason to use a DC motor instead of stepper motor is that a DC motor can potentially generate more torque than a stepper by dumping more current into the motor. Stepper motors locate into stable magnetic orientations, that is they have holding torque but not really moving torque. Microstepping overcomes the holding torque of the motor to hold in intermediate positions between the motors natural stable positions. So the maximum torque possible is limited by the holding torque of the motor. A DC motor can actually sink as much current as the wire enamel can withstand heating. So, it is technically possible to provide sufficient cooling and overpower a DC motor. Of course there are issues with regards to inside our outside coils and how well they can cooled. But it also means that for short bursts it is possible to generate more current(torque)/size than a stepper motor. Using a cheap DC motor and a cheap encoder is likely possible to outperform a stepper motor in torque/weight generation as well as smoothness of the torque profile.
Looking at the assemblers I will be designing for my research, it makes sense for me to have a lightweight motor controller that is based around a DC motor, such that I can be sure to use motors that can hold themselves up and generate torque spikes as necessary.
I basically took the standard hello.echo board and added an LED for diagnostics, an A4952 Full-bridge PWM motor driver, a LM2940IMP voltage regulator to regulate 9V down to 5V, and some extra pins for i/o with the motor and potentiometer. The files can be downloaded here, and the partslist here.
An error I made was that the large copper pours for the input current handling is actually really difficult to solder due to its heat conduction, and it was difficult to get heat to the pin placement. Additionally, I did thicken up the traces to the motor output pins which would have been helpful for current carrying capacity. I used a through hole electrolytic capacitor to provide a little more current capacity to the system in the event the motor current draw drains the current of the system and sags the voltage of the system. Because of this and the double sided board I had to cut out an area around the positive lead of the capacitor. I made a point of soldering the negative to the bottom side to give myself a large ground plane that may be useful when i try to play with capacitive sensing in a couple weeks.
I made a point of going around and checking each of the subsystems to verify they were working. At 9V input from a power supply the voltage regulator was able to keep power at about 5.9V, a little higher than I would have liked, but technically within the operating range of the ATiny44 (6V).
I have not yet got to testing the motor driver