[Dprglist] Arduino Code Troubles
Rud Merriam
rudmerriam at gmail.com
Fri Dec 17 19:10:49 PST 2021
This is why using /const uint32_t MaxDistance{200}/ is advisable. As a
/const/ it obviously can't be changed. The changes in the wayward
function would have been caught by the compiler.
-73 -
*Rud Merriam K5RUD*
/Mystic Lake Software/ <http://mysticlakesoftware.com/>
On 12/17/21 8:48 PM, Pat Caron via DPRGlist wrote:
> Getting old is no fun. I would have found that 2 days ago if I was 10
> years younger!
>
> On Fri, Dec 17, 2021 at 9:39 PM Rud Merriam via DPRGlist
> <dprglist at lists.dprg.org <mailto:dprglist at lists.dprg.org>> wrote:
>
> Good to hear. Glad you found the problem.
>
>
> -73 -
> *Rud Merriam K5RUD*
> /Mystic Lake Software/ <http://mysticlakesoftware.com/>
>
> On 12/17/21 7:42 PM, Pat Caron via DPRGlist wrote:
>> Thanks everyone for the help. This is now working as expected.
>> maxDistance was being overwritten to 0 in what I thought was a
>> disabled function.
>>
>> if ((cm[x] == 0) or (cm[x] > maxDistance)) {
>> cm[x] = 999;
>> }
>> Output:
>> --- Miniterm on /dev/ttyUSB-sensors 115200,8,N,1 ---
>> --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
>> maxDistance = 200
>> cm[0] = 0
>> cm[1] = 92
>> cm[2] = 91
>> cm[3] = 90
>> cm[4] = 249
>> | us_Left = 999cm | us_Mid = 92cm | us_Right = 91cm | ir_Left =
>> 90cm | ir_Right = 999cm | Time = 46mS
>> ...Pat C.
>>
>> On Fri, Dec 17, 2021 at 8:16 PM Pat Caron <patcaron at mail.com
>> <mailto:patcaron at mail.com>> wrote:
>>
>> I did another quick test removing the cm[x] == 0 condition &
>> leaving the > 200 instead of maxDistance.
>> if ((cm[x] > 200)) {
>> cm[x] = 999;
>> }
>> This also worked as expected.
>> Output:
>> --- Miniterm on /dev/ttyUSB-sensors 115200,8,N,1 ---
>> --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by
>> Ctrl+H ---
>> cm[0] = 0
>> cm[1] = 92
>> cm[2] = 91
>> cm[3] = 90
>> cm[4] = 248
>> | us_Left = 0cm | us_Mid = 92cm | us_Right = 91cm | ir_Left =
>> 90cm | ir_Right = 999cm | Time = 46mS
>>
>> I then put maxDistance back in without the cm[x] == 0 and it
>> failed!
>> if ((cm[x] > maxDistance)) {
>> cm[x] = 999;
>> }
>> --- Miniterm on /dev/ttyUSB-sensors 115200,8,N,1 ---
>> --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by
>> Ctrl+H ---
>> cm[0] = 0
>> cm[1] = 93
>> cm[2] = 91
>> cm[3] = 90
>> cm[4] = 250
>> | us_Left = 0cm | us_Mid = 999cm | us_Right = 999cm | ir_Left
>> = 999cm | ir_Right = 999cm | Time = 46mS
>>
>> ...Pat C.
>>
>> On Fri, Dec 17, 2021 at 7:34 PM Pat Caron <patcaron at mail.com
>> <mailto:patcaron at mail.com>> wrote:
>>
>> So I did a quick test removing the second condition
>>
>> if ((cm[x] == 0)) { // or (cm[x] > maxDistance)) {
>> cm[x] = 999;
>> }
>>
>> This is working! Now I need to find out why the >
>> maxDistance condition is causing the failure.
>> Output:
>> --- Miniterm on /dev/ttyUSB-sensors 115200,8,N,1 ---
>> --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed
>> by Ctrl+H ---
>> cm[0] = 0
>> cm[1] = 93
>> cm[2] = 91
>> cm[3] = 90
>> cm[4] = 252
>> | us_Left = 999cm | us_Mid = 93cm | us_Right = 91cm |
>> ir_Left = 90cm | ir_Right = 252cm | Time = 46mS
>>
>> On Fri, Dec 17, 2021 at 5:35 PM Rud Merriam via DPRGlist
>> <dprglist at lists.dprg.org
>> <mailto:dprglist at lists.dprg.org>> wrote:
>>
>> Okay, so we know it is happening in the handling of
>> the conditional. Run it twice. Once with the test for
>> maxDistance removed and once with the test for
>> equality removed. Also, add a print out of
>> /maxDistance/. Need to make sure it is not being
>> changed although the test with '200' there should
>> show it isn't.
>>
>> If you get the same results I'm going to start drinking.
>>
>> Actually, I'll start wondering about the build
>> process. I'm not familiar with PlatformIO. The
>> Arduino IDE takes all the files, rearranges them, and
>> then compiles the resulting file. That's unlike most
>> C++ build systems. The "rearranging" can lead to some
>> strange issues.
>>
>>
>> -73 -
>> *Rud Merriam K5RUD*
>> /Mystic Lake Software/ <http://mysticlakesoftware.com/>
>>
>> On 12/17/21 3:18 PM, Pat Caron via DPRGlist wrote:
>>> Here is the output from Rud's changes:
>>>
>>> --- Miniterm on /dev/ttyUSB-sensors 115200,8,N,1 ---
>>> --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T
>>> followed by Ctrl+H ---
>>> cm[0] = 0 0 999 999
>>> cm[1] = 95 95 999 999
>>> cm[2] = 91 91 999 999
>>> cm[3] = 84 84 999 999
>>> cm[4] = 251 251 999 999
>>> cm[0] = 0 0 999 999
>>> ...Pat C.
>>>
>>> On Fri, Dec 17, 2021 at 4:04 PM John Swindle via
>>> DPRGlist <dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>> wrote:
>>>
>>>
>>> From: Rud Merriam via DPRGlist
>>> <dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>>
>>> To: dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>
>>> Cc: Rud Merriam <rudmerriam at gmail.com
>>> <mailto:rudmerriam at gmail.com>>
>>> Sent: Fri, Dec 17, 2021 2:35 pm
>>> Subject: Re: [Dprglist] Arduino Code Troubles
>>>
>>> Obviously somethine strange happening. Grasping
>>> at a straw try replacing the 'or' in the
>>> conditional with '||'. It shouldn't make a
>>> difference but....
>>> Started to make othere suggestions to localize
>>> the problem but to much verbiage. Here is what I
>>> would try:
>>>
>>> for (uint8_t x = 0; x < (SONAR_NUM + IR_NUM); x++) {
>>> Serial.print("cm[");
>>> Serial.print(x);
>>> Serial.print("] = ");
>>> Serial.print(cm[x]);
>>> Serial.print(" ");
>>>
>>> if ((cm[x] == 0) || (cm[x] > maxDistance)) {
>>> Serial.print(cm[x]); //
>>> Serial.print(" ");
>>>
>>> cm[x] = 999;
>>>
>>> Serial.print(cm[x]); //
>>> Serial.print(" ");
>>>
>>> }
>>>
>>> Serial.println(cm[x]);
>>> }
>>>
>>>
>>>
>>> -73 -
>>> *Rud Merriam K5RUD*
>>> /Mystic Lake Software/
>>> <http://mysticlakesoftware.com/>
>>>
>>> On 12/17/21 10:13 AM, Pat Caron via DPRGlist wrote:
>>>
>>> What I meant to say last night is the array size
>>> is cm[8]. The values for SONAR_NUM == 3 and
>>> IR_NUM == 2
>>> This should not be overrunning the array as it
>>> only loops through 5 times.
>>> I have tried setting maxDistance as uint32_t
>>> without any difference.
>>> I have commented out the sendData() function and
>>> added some Serial.print statements prior to
>>> reassigning the values. (shown in output)
>>>
>>> #define SONAR_NUM 3
>>> #define IR_NUM 2
>>> uint32_t cm[8] = {0,0,0,0,0,0,0,0}; // Create array
>>> uint16_t maxDistance = 200; // Also used with
>>> NewPing.h libraray
>>> char *position[] = {"us_Left", "us_Mid",
>>> "us_Right", "ir_Left", "ir_Right", "cm[5]",
>>> "cm[6]", "cm[7]"};
>>> .
>>> . // Other code here
>>> .
>>>
>>> void oneSensorCycle() { // Sensor ping cycle
>>> complete, do something with the results.
>>> for (uint8_t x = 0; x < (SONAR_NUM + IR_NUM);
>>> x++) {
>>> Serial.print("cm[");
>>> Serial.print(x);
>>> Serial.print("] = ");
>>> Serial.println(cm[x]);
>>> if ((cm[x] == 0) or (cm[x] > maxDistance)) {
>>> cm[x] = 999;
>>> }
>>> }
>>> if (troubleshoot) {
>>> for (uint8_t i = 0; i < (SONAR_NUM +
>>> IR_NUM); i++) {
>>> Serial.print("| ");
>>> Serial.print(position[i]);
>>> Serial.print(" = ");
>>> Serial.print(cm[i]);
>>> Serial.print("cm ");
>>> }
>>> Serial.print("| ");
>>> Serial.print("Time = ");
>>> Serial.print(elapsedMillis);
>>> Serial.print("mS");
>>> Serial.println();
>>> }
>>> //else {
>>> // sendData();
>>> //}
>>> }
>>>
>>>
>>> Loop() {
>>> .// other code
>>> oneSensorCycle()
>>> . // more code
>>> }
>>>
>>> Serial output:
>>>
>>> -- Miniterm on /dev/ttyUSB-sensors 115200,8,N,1 ---
>>> --- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T
>>> followed by Ctrl+H ---
>>> cm[0] = 0
>>> cm[1] = 95
>>> cm[2] = 91
>>> cm[3] = 85
>>> cm[4] = 246
>>> | us_Left = 999cm | us_Mid = 999cm | us_Right =
>>> 999cm | ir_Left = 999cm | ir_Right = 999cm |
>>> Time = 44mS
>>>
>>> ...Pat C
>>>
>>>
>>> On Fri, Dec 17, 2021 at 10:07 AM Chris Netter
>>> <netterchris at gmail.com
>>> <mailto:netterchris at gmail.com>> wrote:
>>>
>>> The for loop stops at x < 8, so it won’t
>>> overrun.
>>> What if you remove the sendData() call?
>>> Does that help?
>>> Also, make sure you have declared any
>>> global variables which are modified by
>>> interrupts or other tasks as “volatile”,
>>> otherwise the compile may decide to optimize
>>> away parts of your code.
>>> Chris
>>> *From: *Doug Paradis <mailto:paradug at gmail.com>
>>> *Sent: *Thursday, December 16, 2021 11:46 PM
>>> *To: *Chris Netter
>>> <mailto:netterchris at gmail.com>
>>> *Cc: *Pat Caron <mailto:patcaron at mail.com>;
>>> dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>
>>> *Subject: *Re: [Dprglist] Arduino Code Troubles
>>> Pat,
>>> for (uint8_t x = 0; x < (SONAR_NUM +
>>> IR_NUM); x++) {
>>> If SONAR_NUM _ IR_NUM = 8 then you are
>>> overrunning the array which goes 0 to 7.
>>> Regards,
>>> Doug P.
>>> On Thu, Dec 16, 2021 at 8:53 PM Chris Netter
>>> via DPRGlist <dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>> wrote:
>>>
>>> So Markus and Karim already pointed out
>>> that the original code snipped works as
>>> designed.
>>> It’s also been pointed out already that
>>> you are mixing data types. I don’t think
>>> that’s the issue, but worth trying to
>>> make both the array and maxDistance uint16_t
>>> As for this new code snippet:
>>> I don’t see any obvious issue with the
>>> for loop. Are you positive that
>>> SONAR_NUM + IR_NUM == 8 ? if not, you
>>> are overshooting the array and that can
>>> cause all kinds of non-obvious issues.
>>> Also, what does sendData() do? Could it
>>> have some side-effects? Maybe its
>>> causing a stack overflow, array bounds
>>> overflow, or similar, which in turn
>>> causes non-obvious issues?
>>> *From: *Pat Caron via DPRGlist
>>> <mailto:dprglist at lists.dprg.org>
>>> *Sent: *Thursday, December 16, 2021 9:04 PM
>>> *To: *dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>
>>> *Subject: *Re: [Dprglist] Arduino Code
>>> Troubles
>>> Hi guys, here is a better example to
>>> show what is happening taken from actual
>>> code:
>>> .... other code
>>> for (uint8_t x = 0; x < (SONAR_NUM +
>>> IR_NUM); x++) { // SONAR_NUM + IR_NUM = 8
>>> if ((cm[x] == 0) || (cm[x] >
>>> maxDistance)) {
>>> cm[x] = 999;
>>> }
>>> sendData();
>>> }
>>>
>>> Printed values cm[0] to cm[5] (us_Left
>>> to ir_Right) without the above if statement
>>> | us_Left = 0cm | us_Mid = 95cm |
>>> us_Right = 51cm | ir_Left = 84cm |
>>> ir_Right = 252cm | Time = 45mS
>>>
>>> Printed values cm[0] to cm[5] with the
>>> above if statement
>>> \| us_Left = 999cm | us_Mid = 999cm |
>>> us_Right = 999cm | ir_Left = 999cm |
>>> ir_Right = 999cm | Time = 44mS
>>>
>>> ...Pat C
>>> On Thu, Dec 16, 2021 at 8:45 PM Karim
>>> Virani <pondersome64 at gmail.com
>>> <mailto:pondersome64 at gmail.com>> wrote:
>>>
>>> It's doing what it's coded to do
>>> On Thu, Dec 16, 2021 at 7:42 PM Pat
>>> Caron via DPRGlist
>>> <dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>> wrote:
>>>
>>> Hi Murray, I did try that with
>>> the same results. NewPing.h
>>> library is looking for a
>>> uint16_t although it didn't
>>> complain when I tried that.
>>> ...Pat C
>>> On Thu, Dec 16, 2021 at 8:35 PM
>>> Murray Altheim via DPRGlist
>>> <dprglist at lists.dprg.org
>>> <mailto:dprglist at lists.dprg.org>>
>>> wrote:
>>>
>>> Hi Pat,
>>>
>>> What if you define
>>> maxDistance as uint32_t?
>>>
>>> Cheers,
>>>
>>> Murray
>>>
>>> On 17/12/21 2:27 pm, Pat
>>> Caron via DPRGlist wrote:
>>> > Hi guys, I'm looking for
>>> help with the following
>>> Arduino code.
>>> >
>>> > uint32_t cm[8] =
>>> {0,0,0,0,0,0,0,0}; // Create
>>> array
>>> > uint16_t maxDistance =
>>> 200; // Also used with
>>> NewPing.h library
>>> > .
>>> > . // Other code here
>>> > .
>>> > irSensorL.read(); // Read
>>> IR sensor... This is working!
>>> > cm[3] =
>>> irSensorL.ranging_data.range_mm/10;
>>> // This returns 268
>>> > if (cm[3] >
>>> maxDistance) {
>>> > cm[3] = 999; /
>>> > }
>>> > Serial.println(cm[3]); /
>>> cm[3] value is always = 999
>>> > sendData();
>>> >
>>> > The cm[3] value is always
>>> 999 when I run this.
>>> > If I comment out the if
>>> cm[3]... statement cm[3]
>>> value is then 268.
>>> >
>>> > ...Pat C
>>> >
>>> >
>>> _______________________________________________
>>> > DPRGlist mailing list
>>> > DPRGlist at lists.dprg.org
>>> <mailto:DPRGlist at lists.dprg.org>
>>> >
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>> >
>>>
>>> --
>>>
>>> .........................................................................
>>> Murray Altheim <murray18 at
>>> altheim dot com> = = ===
>>> http://www.altheim.com/murray/
>>> <http://www.altheim.com/murray/>
>>> === ===
>>> = = ===
>>> In the evening
>>> The rice leaves in the
>>> garden
>>> Rustle in the autumn wind
>>> That blows through my
>>> reed hut.
>>> -- Minamoto no
>>> Tsunenobu
>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org
>>> <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org
>>> <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org
>>> <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>>
>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org
>>> <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org
>>> <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>>
>>>
>>> _______________________________________________
>>> DPRGlist mailing list
>>> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>> _______________________________________________
>> DPRGlist mailing list
>> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>>
>>
>> _______________________________________________
>> DPRGlist mailing list
>> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
>> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org <mailto:DPRGlist at lists.dprg.org>
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
> <http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org>
>
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20211217/815fbef7/attachment.html>
More information about the DPRGlist
mailing list