SPI communications UM6-LT
3dogpottery
Posts: 78
I am about to attempt communicating with the UM6-LT Orientation Sensor using SPI. However, I see a major problem in that the minimum SPI clock speed specified for the UM6 is 200 KHZ (a clock period of 5 uS). It seems to me that, even with the propeller runing at 80MHz, with the time it would take for the propeller to shift bits in, update a counter, and toggle the clock pin, the propeller would not be fast enough. Any information anybody has would help. Thanks.
Comments
80Mhz is 12.5nS (12.5x10^-9). Most PASM instructions are 4 clocks.
code.google.com/p/anzhelka/source/browse/software/spin/lib/um6.spin
http://arduino.cc/forum/index.php?topic=108689.0
I have no idea if seeing his meathod helps or not.
I wrote the SPI driver in assembly, and it operates at a clock frequency of 340K Hz (I picked a frequency between the minimum and maximum as per the datasheet). I realize that there are routines that communicate through the UART; however, I don’t want the latency and the parsing overload.
I also discovered that my particular UM6 has a problem with the accelerometers. I was able to graph the raw accelerometer data using their free serial interface software, and send it to them. They analyzed the data, and immediately volunteered to send me a new unit. When I get the new unit, and do some more-fine tuning on the SPI driver, I will attempt to publish it on the OBEX site. However, I have read that it takes a long time before uploaded objects actually appear on the site.
I haven't tried to query the status register, although all zeros seems to indicate that none of the self test failed.
Since this is my first attempt at writing assembly code, let alone an SPI routine, my learning curve was rather steep. I didn't get any results until I realized that there should not be any delay between the 16 bits written to the UM6 and the 32 bits sent back to your microcontroller. In other words, when querying a register, the UM6 is clocked 48 cycles with no pause. I use the assembly waitcount instruction to time each half cycle. This insures that the clock transitions at precise time intervals, even though there are intervening instructions. Thus, querying a register is accomplished with just one function. My assembly routine reads data on the MISO pin immediately after the last bit is sent on the MOSI pin.
I hope some of this helps.
SPI Driver for UM6 and UM6-LT UMI
I don't know how long it will take to appear. From some of the comments I have read on this forum, it may never? In any event, the assembly object allows you to send a command, write to a configuration register, or read from a data register.
SPI Driver for UM6 and UM6-LT UMI
You are most certainly welcome, joshccna. I really like the UM6 from CH Robotics because it has an on board Extended Kalmen Filter, and relieves the processer (and me!) from having to do all the work. Additionally, you can modify the filter variables for fine tuning.
Incidentally, I have found an excellent book for understanding the Kalman filter. It is titled "Kalman Filter for Beginners" by Phil Kim. I purchased it on Amazon. Previous to this book, I spent countless hours perusing the understanding of the Kalman filter. I read articles about State Models, Matrix Math, Stochtic Models, and Statistics. I also read many articles with titles like "A Beginners Understanding of Kalman Filtering.” However, I was always left more confused that I was in the beginning. Everything I read always had a very analytical approach where mostly I was presented with a lot of abstruse math. I just wanted an intuitive approach, and one that enabled me to use the damn filter! As far as the UM6 IMU, it will help you understand how you can change some variables to better utilize their product. Incidentally, I am not in any way affiliated with their IMU. I am just a dumb retired guy 63 years of age.
Unfortunately for CH Robotics, they had the SPI mode wrong in their datasheet, and many people, including me, struggled over an attempt to implement the SPI protocol. If you read all the blogs from the beginning, it documents my struggle. I received many kind suggestions to use a routine that works using the USART. However, I found it a challenge to write an assembly routine for SPI, especially since it is my first Propeller assembly routine.
If you find any problems with it, please email me. I am not, by any means, a professional programmer, but I am very trying..At least my wife tells me that.
I am in the process of making a "ballbot", and considered the various microcontrollers that are available provide the “brains”. I have not read a lot about the arduino, but I don't believe that it is not capable of parallel processing like the Parallax Propeller is. My present robot uses the 386Ex by JK Microsystems. It is programmed in c. I fake true parallel processing by using an operating system called Ertos. Each process is allowed to run a short time. Continuity between runs is preserved by saving the process variables on a "stack". Each process is allowed to run a short time in a round robin fashion. Like an eight millimeter motion picture, the processes run so fast that it blurs before the eyes and everything seems to be running at once. It is fast, but not that fast. The clock speed of the 386Ex is 25 MHz. Getting back to the point: The problem is that my 386Ex is not well suited for a "ballbot" where very-very fast sampling is in order. The CH Robotics UM6 needs a clock input of at least 200 KHz, preferable 350 Khz. The Parallax Propeller is well suited for this. And, it can actually run several processes at the same time! For instance, the balancing algorithm can run in a "cog", and the motor drive can run in another "cog". A robot needs to sense its environment... so a camera routine can run in a "cog", sonar sensors can run in another "cog", and bumper sensors can run in another "cog". A "prioritizing" algorithm can run in another cog. The prioritizing algorithm arbitrates which sensor takes control of the motors. For instance, let’s say that that the camera commands the robot towards a target. The sonar assigned a higher priority and sensing an obstacle, would immediately take over and steer the robot clear of the obstacle. This is called "Behavioral Programming", and lends a robot a "lifelike" quality. It’s going to take me awhile to get all the programming written. When I do, I will post it on the Parallax Forum. However, I am still sidetracked by my desire of implementing a Kalman filter on a standalone accelerometer and gyroscope. Anyway, I have bloviated enough.
Thanks