Today we solved our Zigbee problem, it was really silly: we were not waiting enough time before and after entering the Zigbee’s command mode. We had a loop to do this waiting that worked fine, but since we programmed the System Boot with a clock twice as fast as before, the loop was not long enough anymore.
Since we had both motors and zigbee working well, Helen wrote a basic program to control the motors with the keyboard, sending directions through Zigbee.
Gabriel is working on driving our OLED screen. He wrote a program following the example in the datasheet but it did not work. It is difficult to debug because the bug can be either in software or in the pin assignment done in the Libero project (FPGA). We will re-check the pin assignment tomorrow. He also started working on a way to make it simpler to write the .dat file (the image to program the FPGA and the System Boot).
I wrote some code to use the encoders, and set the Libero project to set flags for the corresponding ADCs, so an interrupt would be generated when the measure in the ADC overcomes a certain threshold. For some reason I have not figured out yet, the interrupt routine is never called. For now I will leave the interrupt approach, and create a FreeRTOS task to monitor the ADC samples.
This weekend me and Helen worked more on the OpenOCD’s patch to write in the SmartFusion eNVM flash. We finally got it working, now we can load and execute code in flash \o/. Helen is now making some adjustments and organizing the git tree so we can commit it to OpenOCD.
We used Actel’s eNVM driver to create a stub that OpenOCD places in RAM and uses to perform the writing. The stub is compiled, the elf is converted into a binary image which is converted to a char array that is included in the OpenOCD source. After that, we wrote a OpenOCD flash driver for SmartFusion. A OpenOCD flash driver demands certain functions to be implemented, but as we’re in quite a hurry, we minimally implemented only the ones we needed: probe and write. The probe function initializes information that OpenOCD has on the flash bank. We saw in other drivers that it usually does more things, but we implemented only the basic to allow the write function to work. The write function places the stub in RAM, then repeatedly places a part of the image in RAM and runs the stub to write them to flash.
I’ll now move to creating the Libero project for our robot. Libero is the Actel’s development plataform for SmartFusion, and we need to use it to redirect the GPIOs to the FPGA pads. For now, it will generate a FPGA image that contains only this routing of GPIO to pads. Latter, as we work on the app libraries, we will insert the modules to control the motors, LCD, and other peripherals. Then we will use it to generate the final FPGA image that we will load into the Tutobot.
Today I finished the last details of the PCB and started placing the components. There is a lot of components, our LCD is kind of big, and the smart fusion chip isn’t that tiny either. I started considering a circular board of 11cm diameter, but increased to 15cm after seeing all the components.
One thing that is decided is that the motors will be on top of the board, so it stays closer to the ground (and so the line sensors). I drew some rectangles to represent the space of the motors and wheels. I still need to learn how to make the holes for the wheels and screws.
I also have to be careful with the ground planes. I divided the board in two, one part has the regular ground planes, the other one has the analog ground. This is a recommendation from Microsemi, to have a less noisy analog ground. The two will be linked at a single point by a zero ohm resistor.
Tomorrow night I will keep working on this.
Gabriel is working on our Makefile structure for compiling projects easily.
Helen is going further with programming testing interruptions. She could activate them, but the vector table is in the flash memory (which we are not able to program by the openOCD yet). She is searching a way to inform the core that the vector table should be placed in RAM.
The motors we choose are 6V nominal but the documentation says they can be driven with 9V. The stall current is of 360mA.
I choose a driver IC we had on our mentor graphics library, the L6206. I have one uncertainty about it, it’s its over current protection. The datasheet gives information on how to calibrate the current threshold using a resistance between 5k and 40k. The problem is that the minimum threshold previewed (with a 40k resistance) is about 552 mA, which is above the stall current. I am not sure this is a big problem, if anyone has comments I’d appreciate =].
Meanwhile I am searching a voltage regulator for the motor. It has to generate the 9V with 800mA, from the voltage coming from the battery/usb system. This input voltage is not constant and may vary from 2.5 to 4.2 V. Looking for some options at Linear technologies, I found some ICs, and narrowing down to the simpler and most adapted ones I got these:
None are available in our library, so one of them needs to be added. I could not see important differences between them, but I think the 1872 is a little more powerful than we need. For now I am going with the 1370.
These last days we have been working on schematics for our PCB. Each on is working on different parts of it so we can finish it as soon as we can. I’m working on the schematics for our sensors, wheel encoder and motor driver. We had some changes on this yesterday so I have to adjust my schematics, I can post them here latter.
For sensors we are using the QRE1113 as color sensor to follow lines (following the idea of the Pololu’s QTR sensors), and the HSDL-9100-021 as proximity sensor.
For motor choice we ended up choosing the option 3 because the motor has a much better quality ( the option one is rather too noisy…) and because the encoder has a slighly better resolution.
This last week we decided to drop the STM32 microcontroller for using a SmartFusion SoC. It is a mixed IC that contains a ARM CortexM3 core (called Microcontroller SubSystem – MSS), a FPGA and an analog bloc. This would allow students to practice not only microcontroller programming but also do logic exercises by programming the FPGA in some HDL.
Since this decision we all started to research about the SmartFusion, and from the moment we had already got some overall knowledge, each one is following an specific task. I’m working on the PCB schematics. I first listed all SmartFusion pins and descriptions. Now I’m trying to close the peripherals choice. I choose a motor driver IC, and then went to check the FTDI chip we had chosen. I found out it needs an external EEPROM attached, so I’m chosing one right now. I also discovered the FTDI chip resets in a USB to UART mode, and some sort of programming must be performed so it works in a different mode (JTAG for instance). The programming is performed via the USB port on the chip. FTDI provides some drivers and libraries. There is a Linux version of them, but it seems that Windows has a better support. That is an issue that will need further research when we try to program the FTDI.
Next thing is choosing an SPI Flash memory. It is a way to program the FPGA, and even if we don’t use it right now, as it is a cheap chip, we are going to put one. After that I think all ICs and major components are chosen.
After that I have to solve a little dilemma : which peripherals connect with the MSS IO pins, which ones connect to FPGA IO pins. Maybe multiplex some of them so they can be controlled either directly by the FPGA or by the MSS, but having in mind that the MSS has a lot less IO pins than the FPGA. If we programmed the FPGA with some IO controller bus, I think we could use FPGA IO pins from the MSS. This bus would be a slave to the main MSS’s AHB bus. Well, when we decide that I’ll surely write another post. Any suggestions on this issue are welcome =).
We talked about motors and encoders with the teachers and it turns out we can spend a little bit more on the encoders. Also, they said (if I got it right) that doing our own optical encoders could be complicated to calibrate. They mentioned we could take the chassis out and use the board as chassis. Well, all that said, today I looked for motors + encoder + wheels again, and set up some possible “kits”.
There is also the option of using mechanical encoders, they are like a potentiometer that turns without ending. They are quite cheap, about 3 € each, but we need to make a gear system to attach it to the motor axis.
I personally like the cheap option 1, but the encoder’s resolution might be disappointing (it’s there where the option 3 is better, and the 2 maybe). Also I’m not so sure of the way we’re going to mount it on the board, since the sensor needs to fit around the encoding wheel. I imagine we can order a board with holes for the wheels and encoding wheels, and the sensor can stay on the board on the side of the encoding wheel. What do you think about it?
This last week we were told we should finish our software homework on the STM32 boards until Friday (or at least try to), so we could be prepared for the communication challenge. Well, let’s just say I’m still having dreams about blinking LEDs and datasheets… xD. I worked all week on this, ALL the time. Even so, I had to skip some details so I could have the time to get Zigbee code working for the big Friday. The communication challenge is done, but I still have to make some adjustments on my homework: code the PWM control for the LCD’s back-light and the timer to control the buzzer.
And I should say, there’s an important lesson I learned this week: commit your code in your version control system ALL THE TIME, specially if something new that wasn’t working suddenly is. It is important to commit small changes, so latter you can easier find out what introduced a bug. I guess the teachers told us that before, but it’s when you need to go way back on your code (because it’s not working anymore) that you really feel how important it is. I used to commit only when I had finished working on a whole big lot of stuff, and when I had to come back in my commits, I had to undo a whole big lot of stuff too, which wasn’t really efficient… So my final thought for the week is: git commit all the time.
Last Thursday we had a quick meeting with our teacher, when we discussed about the general status of our project. One of the topics was the micro controller choice. They suggested we checked the STM32 low power and connectivity lines, so we did a little research on it today.
We wanted to eliminate JTAG programing interface and program directly by USB or Zigbee (by UART/USART). The STM32 have boot mode that starts a embedded boot loader which is capable of receiving an image by a communication interface, and loading it in flash. The difference between the STMs is from where they can get this image. They all can get it from USART, but only some of them can get it from USB. The one we had chosen before can get it only from USART, so we need to change.
Having that in mind, we got to two possibilities;
A STM32F105 or F107, from the connectivity line, allows flashing from USB, USART and CAN.
A STM32L151/152 with flash size of 384kB, from the low power line, allows flashing from USB and USART. For example the STM32L151VD.
With the low power devices, we have the following inconveniences:
The datasheets and reference manuals say we can flash from USB, but the system boot loader manual says nothing about them. The only information we have from this manual is that the low power medium density F151/152xx devices can’t flash from USB, only from USART.
The low power devices with the 384kB memory seem to be difficult to find. We couldn’t find them at Digikey or Farnell (Radiospares is offline today). So we know nothing about the price now. The lower memory versions are availlable but don’t allow flashing from USB.
With the connectivity line devices:
They consume a little more than the low power devices (obviously). While the low power needs a supply current of 230 µA per MHz, the connectivity line needs 393 µA per MHz.
One option is STM32F105RB, featuring 128kB flash, 64 pins. It is available at Digikey for 7,50 €. There is also the F105RC, for 8,60 €, featuring 256kB flash, 64 pins.
To choose memory size, we checked our communication challenge’s program size, imagining we would have for our robot something at least this complex. Its about 100kB, so we thought that 128kB might not be enough.
Having all this in mind we are deciding for the F105RC. It’s only one euro more for double the flash of the F105RB, and we have clear documentation about the system boot mode for USB programming. Also, if we use a clock as low as the low-power’s , we won’t be consuming so much more current.
If you have any suggestions don’t hesitate to leave a comment =)
I spent the weekend working with my group in order to chose components and better define our Tutobot. Some components weren’t exactly chosen yet, tough we narrowed them down to 2 or 3 options.
I mostly focused on searching the mechanical part: chassis, motors, wheels. It took me a lot of time to understand how to choose the motors, and still I cant say I’m completely sure about it. At the end we choose a motor we believe is going to make our robot fast enough, but I couldn’t find yet the wheels that fit the motor axis.
There is another motor that has compatible wheels, and it’s even half the price, but it’s a bit slow, only 65 RPM free rotation (at 9V). In our calculations, considering wheel size, motor’s stall torque and estimated robot’s weight, it would give a maximum speed of 19 cm/second. We felt it to be slow in comparison to what we expected to do in the beginning.
I found out about H bridges used in motor drivers. I didn’t know they existed, now I have to study more about how they work, because the way they apparently boost current into the motor seems a little magical to me. At least I need to understand how to choose a bridge-H IC.