Journal StarWreck's Journal: REVO... Revo... revo 1
Did the first "formal review" for our car. Demonstrated the Micro-Controller turning the wheels left and right instead of the Remote Control Receiver. Did a pointless power-point presentation that had a couple of pictures, some of our flow-chart, and a couple examples of the code we're using.
After the review, tried all day to get the GPS to come in 1 serial port, and go out the other... again. Its been a whole week now! We did make some minor progress, however, we got the hardware configuration of the interface between the GPS module and the micro-controller down correct beyond any reasonable doubt. Unfortunately it still dosen't work... so it HAS TO BE the program. Sophy sent an email to me:
After the review, tried all day to get the GPS to come in 1 serial port, and go out the other... again. Its been a whole week now! We did make some minor progress, however, we got the hardware configuration of the interface between the GPS module and the micro-controller down correct beyond any reasonable doubt. Unfortunately it still dosen't work... so it HAS TO BE the program. Sophy sent an email to me:
"The microcontroller uses a uart chip. You can't do it with a uart chip, you have to use a usart because the gps module sends out burst of transmissions every second. It uses synchronized serial communication and you would need a 8251 USART chip."
Tried somethinglike this (Score:2)
Have a remote cutout. Somehow. When the mcu gets stuck in an infinate loop, and your servos are set to full gas, full straight, you are screwed.
Linux is not a real-time OS. The parallel port when guided by a user controlled application does *not* provide enough precision for the pulse widths we're working with. You need to lock the system by setting your priority to realtime while you are doing that sort of time-critical stuff.
A VIA EPIA has more than enough power to guide