Could I get some help on this timing issue. Basically i just want to know if the SVP1284 and your Encoder Library with its ISR’s can handle
the following setup. Can it be tweaked? Or should i consider a more powerful processor - thats the question? . When i ran the setup
it generated errors on both channels. Thats not my concern right now. Just want to run through theoritical max calcs to see if the processor is capable.
I have a tracked robot with two 7.2V DC motors, which can spin at 291 RPM max (GMH03 motor). (from the lynx motion johnny five robot kit).
Each motor has a USDigital Encoder (E4 model - URL : http://www.usdigital.com/products/encoders/incremental/rotary/kit/E4)
Supposedly they can generate 100 cycles per revolution, which translates to 400 pulses per revolution (ppr).
If spinning at a max of 291 RPM ==> translates to 4.85 RPS (revolutions per second).
400 ppr x 4.85 rps = 1940 pps (pulses per second). Lets round off to 2000 for simplicity.
2000 pulses per second from one encoder would mean pulses coming in every 0.5ms. For two encoders running at the same speed, it would be every 0.25ms (4000 pulses max).
Looking at your encoder library and descriptions it says " The interrupt service routine (ISR) will take about 20-30 us. ". So if I was to compare 0.02-0.03ms
versus 0.25 ms (period between ISR calls), there should enough time for the processor to ‘rest’ or ‘do other things’ between positive and negative going transitions.
Obviously, the robot will run no where near that and i could always speed limit via software. The orangutan will be used to only manage low level controls so it will not be
overloaded with number crunching or anything like that, so as not to overload the processor.
However, the question remains are my calculations correct. Or have I missed something ?
I have been able to track both encoder outputs on my 16032 Zeroplus cube logic analyser and the signals are there, and behaving as expected. Although i would not know
what sampling rate i would need to set it up as to emulate to estimate what the 1284 processor might see. That was my round about way to find out what is going on at
the orangutan input end.
Your calculations make sense and I do not see any reason why the SVP-1284 wouldn’t work for you. However, on the datasheet of that encoder, it looks like the voltage for HIGH is not well defined (it only specifies a 2.4V minimum). You might want to measure the encoder outputs and find out how high the voltage goes. If it is significantly below 5V, the AVR on the SVP-1284 might not read it as HIGH.
Thank you for your suggestion. I thought since the LogicAnalyzer was reading the signals reliably, so might the digital inputs on the Orangutan.
Don’t currently have an oscilloscope to verify voltage levels, but i can understand where are you are coming from. However, from your
response, can i confirm that there is no need to modify the currently library for reading encoders from your website??
I had one other quick query - I recently purchased an Mbed application board. What connections would I need to make from ZigBy/WiFly headers
so that I can use the WIXEL which I purchased from you. Seeing as i have two in my possession, it would be better to make use of them.
You should not have to modify our library to read the encoder.
You should be able to use the Wixel by connecting it to the TX and RX pins of the mbed Application Board, which are p9 and p10, respectively. You can find more information about connecting a microcontroller to the Wixel in the “Connecting a Microcontroller via TTL Serial” section of the Wixel User’s Guide.
After some testing…finally figured out the problem (and with help from experienced college teacher)
The encoder that i am using is generating way too many pulses for the orangutan to keep up.
Ended up having to buy a 2032 Quadrature Encoder interface (arduino shield - from robogaia),
then plug that to a SX1509 i2c breakout board from sparkfun (as the 2032 chip has 8 data IO , plus 8 control lines).
That way I could get all 16 pins on 2 i2c lines (SDA and SCL). The HCL2032 does all the hard work including the counting and
converting data to an 8 bit register.
It is worth noting that it is the long way around, however, if someone from Pololu could write the library interface for the SX1509
you may well benefit. Its a nifty little board that may well go hand in hand with your I2C line extender.
Obviously this is where i am stuck. Cannot see to get a good library for i2c that will work reliably for the orangutan. Any suggestions here?
Peter Fluery one is somewhat confusing. Could you confirm if Pololu have developed their own?
We have not developed our own I2C library for the Orangutan. Some people on our forum have used that I2C Master Software Library by Peter Fleury with their Orangutan with success. What kinds of problems are you experiencing with that library and Orangutan? If you post the particular parts you find confusing, I might be able to clarify it for you.
1st question I had is - even though the SVP has internal pull ups (pins C0 & C1 - at least I think so) - is it still recommended to put external in (say 2.2 Kohms)
Just really wanted to know whether Pololu have developed an i2c library that is suitable for the orangutan range of controllers.
Lastly, I came across this website (ftp download link --> bdmicro.com/code/srf08/src/srf08/) --> which seems to have very good compatibility
with the orangutan controllers. And this is more of a sharing with everyone who is looking to interface with i2c and the ultrasonic sensor. This library was
developed in C for the atmega, and not the Arduino. Looking through the code, do you see any problems with using on orangutan SVPs (open ended question i know!)
In the process of implementing this in my code at the moment.
Thank you for your quick reply and look forward to your advice.
Using the internal pull-up resistors might work, but they might also be too weak depending on the speed you are using. This article that talks about the effect of different pull-up resistor values might be helpful.
I did not look too much into the library that you posted, but I would expect most I2C libraries written for an ATMega to be able to be adapted to work with the Orangutan SVP. I would be interested to hear how the library works for you.