View previous topic :: View next topic |
Author |
Message |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Jul 17, 2020 12:34 pm |
|
|
I didn't know you were 80. Ok, sorry. |
|
|
rovtech
Joined: 24 Sep 2006 Posts: 262
|
|
Posted: Fri Jul 17, 2020 1:06 pm |
|
|
Me too, I'm in the high risk category for Covid19.
So you actually had to write a function because C in general does not have one? Is it really not defined in ANSI C? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9134 Location: Greensville,Ontario
|
|
Posted: Fri Jul 17, 2020 4:22 pm |
|
|
comments...
gee, at 80 you've probably forgotten more stuff than I've learned, and I'm 67 !
Chem Teacher in Grade 13 said we'll forget lots BUT if you rememeber what BOOK the answer's in, then you're ahead of the next guy !!
As for rounding.. every language is evolving, so maybe 'next week', some C committee will put 'rounding' in the official book. Though which accepted method will be the official method ??
I'm wondering if you could get rid of the complex ( time comsuming ) math. Only 360* in a circle, so maybe a precomputed table would be faster, perhaps smaller code ??
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Jul 17, 2020 4:26 pm |
|
|
rovtech wrote: |
So you actually had to write a function because C in general does not
have one? Is it really not defined in ANSI C?
|
CCS has an ANSI compliance document here:
https://www.ccsinfo.com/downloads/ansi_compliance.pdf
This pdf refers to C90 compatibility. CCS doesn't claim to be compatible
with C99.
Here's a page that summarizes what's in math.h for C90 vs. C99.
You can see there are rounding functions in C99 and CCS just
doesn't implement those, because CCS is compatible with C90:
https://en.wikibooks.org/wiki/C_Programming/math.h#Pre-C99_functions
Therefore you have to write your own function (as was posted here)
when using CCS. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19260
|
|
Posted: Sat Jul 18, 2020 1:19 am |
|
|
Yes. The definition of 'round', is very much a standard C subroutine/ For
example:
<https://www.geeksforgeeks.org/write-a-c-function-to-round-floating-point-numbers/>
Doing it as a genuine 'function', as opposed to the #define shown here.
Given how simple it is, I'm slightly surprised CCS haven't added this to
the standard maths library yet.
However it is a thing it is easy to just have in your own library. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9134 Location: Greensville,Ontario
|
|
Posted: Sat Jul 18, 2020 4:07 am |
|
|
Maybe a request to CCS and they'll add it into the next version of the compiler ? I can see it having been so simple to do that it was put 'on the back shelf' while more complicated and time consuming features and functions ( say SIN() or COS() ) were created, and they never got back to doing it.
We've all done that right !! |
|
|
rovtech
Joined: 24 Sep 2006 Posts: 262
|
|
Posted: Sat Jul 18, 2020 8:02 am |
|
|
Thanks everyone for the patience and understanding.
Good suggestion Jay but unfortunately it is not that simple. This project is to be a scanning sonar for my ROV.
My processing is distributed between master and slave PICS both at the surface and in the ROV. Communications is by RS485 on a twisted pair of wires.
The Sonar PIC is an I2C slave in the ROV that sets the transducer motor direction, sends a ping, and looks for echos as a calibrated time base counter starts. 0 to 63 represents 0 to 630cm range (about 20ft). A fixed number of echos can be captured per ping, say three, in three 16 bit bytes. The 63 times 10 cm range requires 6 bits for echo start, 6 bits for echo end, and the other 4 can be amplitude. The 3 bytes are sent each transmission cycle between ROV and Surface and represent the echos from one direction. (the format can also be start + length + amplitude).
At the surface the 3 bytes are sent to a display slave PIC which has to calculate which part of the line to display from the angle and start and end points. The maximum scan width is 18 times 10 degrees for 180 deg. The mechanical movement of the transducer is the speed limit, not the ROV communications or display calculations.
The project started a few weeks ago with water tests with an old spinning-wheel/flashing-neon depth sounder to analyze the signals. I am about to add an in-air sonar module ($2 EBay) to develop the time base. It is easier than working in water. Packaging a steered transducer for underwater will be a challenge.
Typically: I select auto pitch and -90 degrees and full speed and the ROV hurtles down vertically at about 1 ft/sec. When the sonar detects an echo it slams the brakes on and changes to -45 deg pitch and hover mode. I take over manual control and widen the Sonar scan to see what is ahead.
Yes I can buy one for $2000, or a ROV for $50,000 but then I would have no fun. My ROV works well and continues to evolve.
Peter. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9134 Location: Greensville,Ontario
|
|
Posted: Sat Jul 18, 2020 9:16 am |
|
|
re: Quote: | Packaging a steered transducer for underwater will be a challenge. | How about magnetic coupling ? I've got THREE pool cleaning robots here and all failed the same way...shaft seals leak..in 4'( 1.5m) of pool water......grr
or maybe a double chambered sealing system with a 'water sensor' in the secondary chamber to detect when the outer seal leaks( it will...) 2nd(inner seal) should keep 'internals' dry.....
or ( and this DOES work..) make the transducer steering shaft 4" long( longer is better), squirt 100% silicon between shaft and tubing, let cure(!!!!). Now you have a 100% seal for the 4" (or more). As long as the shaft turns at low RPM, the silicon seals. This is an old Ford 9N tractor 'trick' to keep oil out of the brakes. |
|
|
|