No.
Even hardware clocks are configured by software after initial boot.
I remember seeing something somewhere about the i2c clock. Maybe in the gpg libraries?
Since I am in the hospital, I can’t help you find it.
1 Like
Jim, thank you for thinking about this, but I have to limit “my job” to reporting the issues and trying “my darndest” to make sure the issue is not in my code. Simple elimination of possible causes like running the same test with and without the software I2C interfaced IMU running can provide additional information, but going deep into the guts of the ModRobotics I2C code is above my pay grade.
1 Like
You’re getting PAID?!!
I’m not so good at what you do. Since this is a persistent issue, and there are corollary issues with firmware updates, my first reaction is to look at signal timing.
I’ll look at this again once I get home and feel better.
It probably won’t be until after the holidays.
Maybe Santa will leave a 'scope and logic analyzer under the tree.
1 Like
Actually, we’d make a pretty boss team!
I can make hardware dance jigs and you can make software play The Great Gates of Kiev in 5.1 Dolby surround sound.
We’ll whip it.
1 Like
Maybe Santa will leave you a 3-D printer?
No way! Those things eat time and money.
Carl has dibs on my time, and my (next week) 23rd wedding anniversary called dibs on my money already!
2 Likes
I’m not holding my breath about my tree either.
A good Saelae logic analyzer costs like oil-rights, and a 'scope with the precision I would need costs like a battleship too.
2 Likes
Congrats on #23.
3D printers have come down in price, and can be really handy for both prototyping and making real parts. It’s the Fusion360 (or whatever you use for design) that’s the real time suck. There’s a bit of a learning curve. But even with modest skills you can make useful things (even without a heated bed - I can only use PLA).
/K
2 Likes
Looking forward to hearing you are an the back side of your unplanned “vacation”
1 Like
I’ve toyed with a usb scope thing for several years now, but I think having a spare “stock” GoPiGo3 that I could test only stock R4R code on would get a lot more use than a scope for me. I’m watching to see if the new GoPiGo3 board will pass initial purchasers’ usages.
1 Like
Ditto.
There ought to be a “masterpiece of understatement” emoji for things like this.
1 Like
My two centavos:
The two big reasons I don’t have a 3-D printer are the cost:
First-cost and follow-on costs.
Anything that looks like it will be worth the time to take home and unpack/setup/calibrate is in the $300+ range, and I’d get better use from a decent high-bandwidth scope.
It would (IMHO, based on what I’ve read if I understand correctly), cost at least half again that for supplies and scrap to get it accurately set-up, adjusted, and calibrated.
I live in the European version of a “studio” apartment.
(In Europe, divide expectations for space by about 1/2.)
The entire downstairs of the “house” I live in is smaller than the kitchen and living room where I live in Worcester Ma. - and this is considered a “generously” sized place that people drool over.
I can’t give something the size of a 3-D printer its own home so it needs to be setup, recalibrated, one or two pieces printed, cooled, cleaned, and then put back out of the way after each use.
The actual learning curve is (IMHO) like climbing Mt. Everest to get a learner’s permit. I don’t see enough on-going use to justify the cost.
I’d really like a reasonably well calibrated 100mhz 'scope, (though nowadays it might need to be closer to 1ghz), but I don’t have a place to keep it either.
What say ye?
Or are there things I’m not understanding rightly?
I’ve looked at those too.
This seems to be one of those “buy nice or buy twice” things.
An inexpensive 'scope to use as a learning tool is one thing. Trying to use a $50/$100 USB scope to troubleshoot sub-millimeter impedance mis-matches is something else entirely!
I guess we all will just have to make do.
1 Like
Update on I2C testing:
- tests without IMU / software I2C in use can still cause fatal error case
- multi-process test to distance sensor with new (threaded) easy PiCam sensor can cause error case
- multi-process software I2C distance sensor only accesses do not cause error case
Building multi-threaded distance-sensor-only test to see if di_i2c mutexes are perhaps not thread safe.
1 Like
Sounds like space would be an issue. And you’re right - you’d spend at least $300 to have something worthwhile. I’ve heard good things about the Prusa MINI+ (https://shop.prusa3d.com/en/3d-printers/994-original-prusa-mini.html), which isn’t too much of a space hog, but may still take more space than you have. And I don’t know how much filament is where you are. It’s reasonably cheap for me to get decent PLA, but that may not be the case where you are.
Also sounds like your focus is really on hardware testing, so a good scope probably would be a better investment. All depends on what you enjoy spending your time on.
Happy holidays. 
/K
2 Likes
I like software testing too. It’s fun! It’s like Chess as a Turing test. (Not that I’m even punter-level at Chess.)
I know hardware design and testing. With people like yourself and Alan who have so much more talant holding down the software side, I’m not so concerned about leaving the gnarly and nobby software glitches in your capable hands and concentrating on what I do well:
- Being an idiot noob user
- Forensic “Pi-tholohy”
- Being nosey.
1 Like
Further thinking:
Since the “Easy Pi Camera Sensor” does not use the I2C bus, I need to use pure Python mutex, rather than the di_i2c mutex. Guessing that will prevent the threaded camera sensor from killing the i2c distance sensor.
1 Like
SOLVED! (Don’t use di_i2c mutex unless protecting I2C bus.)
Here is Carl using my new EasyPiCamSensor.light_left_right() as cross connected steer(left_percent,right_percent) stimulus with no I2C error.
2 Likes
Great detective work!
2 Likes
Cool. Congrats on getting it sorted!
/K
2 Likes
This it really cool!!
2 Likes