Quote:
Originally Posted by biojae
the rio wouldn't have to send anything, only receive. so if i have a very fast loop in a separate thread, could i conceivably catch the data?
|
Receiving is actually much harder than sending when writing a bit-banged serial port. I can say this because I wrote my own software serial implementation for the ATmega168 (so I could have 2 UARTs on it).
If your code is just a while() loop running in a task, you need to consider that other tasks will be constantly interrupting you and taking the processor from you (for many milliseconds at a time). So you can't count on a while() loop to catch the first edge. So, you might be able to use an edge-triggered interrupt, but you have to be ready to sample the I/O line at 1.5 times the bit clock after the edge interrupt. I haven't looked into the pin change interrupts too closely. I don't know if your code would actually be running in the CPU's interrupt handler or if the RTOS catches the interrupt and just sends a signal to your task. If it's the latter, then it's very unlikely that you'll get the interrupt fast enough. Even if it's the former, you need to know exactly when that first edge occurred so you can know when to sample your first bit, and then you need to loop, waiting precisely 1 bit time, sampling the input pin and looping again until you have all 8 bits. It may be possible, but my point is that it will be incredibly difficult to get all the timing right on a multitasking RTOS. Keep in mind that at 115200 bps (which is what the 6DOF uses), each bit is only 8.7 microseconds long. Usually the scheduler on an RTOS like VxWorks runs at 1, 5, or 10ms, so if your task gets interrupted it'll be way too long before you get control back.
Quote:
thats a great idea except the arduino uses analog pins 5 and 6 for I2C communication, and all 6 pins are used (3 for x y z) (3 for roll pitch yaw)
what about SPI? it was finished for labview but not for windriver
|
SPI might be an option. I haven't looked into how that works on the cRIO. Alternatively, I think you'd be better off trying to bit-bang I2C on the 6DOF with some of the unused pins. People have done it before; you can find code out on the Internet that might work for you (a quick Google search turned up
this which might be promising).
Another option would be to add an additional AVR microcontroller - program that to act as an I2C-to-serial bridge and place it between the 6DOF and the sidecar. You can get pre-made AVR or Arduino boards for <$20 that would probably work well. Still not a trivial programming challenge, but much more straightforward than the bit-banged serial.
Like I said before, it might be possible to get bit-banged serial working on the cRIO, but I think it will be difficult and frustrating. I wouldn't want to try it myself, but if you really want to then maybe it's worth a shot. I'm just trying to point out that there might be some other options for you, some of which might offer an easier solution.