Announcement

Collapse
No announcement yet.

Combining Demonstration Routines Kills Performance

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Combining Demonstration Routines Kills Performance

    Greetings,

    After getting the 4D/Arduino RGB LED demonstration project to work, I added a fourth channel and all was good. I then wanted to try to move other information across the serial line and combined the basic Arduino code and library for a DHT11 temperature/humidity chip.

    Here is the problem . . . the DHT11 has a couple lines of code in the void loop and then addresses some WRITEOBJ statements. The LEDs read data based upon switch/case statements, also in the void loop. No matter what, the DHT11 always reads and reports back to the 4D. Up until added that code segment in the void loop, the RGBW LED demonstration worked flawlessly. When the DHT11 data is in the void loop, te LEDs fail to track the 4D sliders, except in the slowest possible way.

    I know that I am doing something wrong (duh!, I just do not know what. Any pointers would be greatly appreciated.

    Regards - Baran


    // This code is a combination of 4D's Arduino RGB LED demonstration example and basic DHT11 code for Arduino. // The DHT11 code works no matter what (when uncommented) but it stops the LEDs on my Arduino from tracking // sliders through a switch/case routine. As included (with commented-out DHT11 code), the RGB demo works great.// My guess is that I am overwritting buffers somewhere, but that just sounds good to my ear - I do not have a clue. #include "SoftwareSerial.h"#include "Arduino.h"#include int sensorPin = 4;DHT11 dht11(sensorPin); SoftwareSerial mySerial (2,3); #define RED_PIN 9#define GREEN_PIN10#define BLUE_PIN11#define WHITE_PIN 6 #define READ_OBJ 0x00#define WRITE_OBJ 0x01#define REPORT_OBJ 0x05#define REPORT_EVENT 0x07int val; const uint16_t buttonSelect = 0x061B;const uint16_t buttonReset= 0x061C; const uint16_t sliderRed= 0x0400;const uint16_t sliderGreen= 0x0401;const uint16_t sliderBlue= 0x0402;const uint16_t sliderWhite = 0x0403;const uint16_t sliderHumid= 0x0404;const uint16_t sliderTemp = 0x0405;const uint16_t coolgauge0 = 0x0800;const uint16_t led1 = 0x0F01;const uint16_t led3 = 0x0F03;const uint16_t led4 = 0x0F04;const uint16_t led5 = 0x0F05;uint8_t on;uint8_t off;uint8_t command, red, green, blue, white;uint16_t object, value;boolean flag; uint8_t nacAck() {delay(50);while (!mySerial.available());return mySerial.read(); // 0xc6 or 0xd5} bool readMessage(uint8_t &command0, uint16_t &object0, uint16_t &value0) {bool flag0 = false;uint8_t buffer[6];uint8_t checksum = 0x00;uint8_t i=0;if (mySerial.available()>0) {buffer[i] = mySerial.read();command0 = buffer[0];i++;checksum = command0;if (command0==REPORT_EVENT) {if (mySerial.available()>3) {buffer[i] = mySerial.read();checksum ^= buffer[i];i++;buffer[i] = mySerial.read();checksum ^= buffer[i];i++;object0 = buffer[1]
    /Baran G Galocy/

  • #2


    Try changing your code to only send the message(s) when the values change.
    Mark

    Comment


    • #3


      Your code includes delay(DHT11_RETRY_DELAY) which adds a one second 'do nothing' delay. This will have a direct impact on the speed of the loop.

      Instead of a delay, you may want to try the following which uses the millis() command:


      unsigned long oldTime = 0; //declare as global at top of file float temp, humi, oldtemp = 0.0, oldhumi = 0.0; if ((millis() - oldTime) > DHT11_RETRY_DELAY)//skip if "DTH11_RETRY_DELAY" ms have not gone by { dht11.read(humi, temp);// Read DHT11 and convert to Fahrenheit oldTime = millis();// Reset oldTime to start new delay if (temp != oldtemp) {// If temp has changed, convert to F and write values outoldtemp = temp;int tempf = temp * 9 / 5 + 32;sendMessage(WRITE_OBJ, led1, tempf);sendMessage(WRITE_OBJ, led3, temp); } if (humi != oldhumi) {// If humi has changed, write values outsendMessage(WRITE_OBJ, coolgauge0, humi);sendMessage(WRITE_OBJ, led4, humi); }}delay(100); rest of code....

      Comment


      • #4


        "Try changing your code to only send the message(s) when the values change."

        I don't have a clue about how to do that. Also, I do not think that is an issue. The reason is the DRASTIC non-compliance of the LEDS in response to the sliders when I have the DHT11 code uncommented. I am certain I have conflicting functions or statements or two variables trying to use the same porta-potty simultaneously. Basically the sliders work fine when the DHT11 code is commented out. They fail, in entirety, when the DHT11 code is uncommented. This is a MAJOR clashing of code, but I cannot tell how

        "Your code includes delay(DHT11_RETRY_DELAY) which adds a one second 'do nothing' delay. This will have a direct impact on the speed of the loop.

        Instead of a delay, you may want to try the following which uses the millis() command:"

        Good call, but no googoo doll. I removed that delay line entirely. The temperature and humidity still read fine (and that was the section from which I removed the delay line) but the LEDs still do NOT respond to the sliders when the DHT11 code (including WRITEOBJ) is uncommented. Something in the switch/case sequence is clashing with the sendmessage commands. I guess it is back to trial and ERROR.

        Regards - Baran

        "
        /Baran G Galocy/

        Comment


        • #5


          Save the values in a global variable, initting them to -1 in setup, or wherever.

          I think you end up spending so much time updating these variables (the update process is not instantaneous) to the same value that the rest of your code bogs down.
          Mark

          Comment


          • #6


            Can you please tell me which DHT11 library you are using, I can't seem to find your version? Are you running this code on an Uno?

            Comment


            • #7


              Greetings,

              In response to pkourany:

              Here is a link for the DHT11 library that I have. It includes a demo from which I have extracted most of the guts to combine with the RGB LED demo.

              https://drive.google.com/uc?export=download&id=0B3L4pZE60Jv0SzRsTTMxZGZNblU


              In response to our Moderator and all others:

              The MOST IMPORTANT piece of the puzzle has come to light. If I comment out ALL of the sendMessage statements, the RGB LED demo works perfectly. If even ONE sendMessage line is active, the RGB LED demo stops working, even if all the other DHT11 code lines are commented out. Conversely, I can uncomment ALL DHT11 code lines save for the sendMessage lines. I even took a raw RGB LED demo sketch and inserted one sendMessage line into the void loop (with defined variables for the object and value) and the program halted!!!

              I have a conflict between my sendMessage lines of code and my readMessage code line in the switch/case routine but I am at a dead end. I even tried moving the DHT11 code and sendMessage lines to the void update () section to no avail. The code still jammed.

              What is needed to make readMessage and sendMessage code lines exist in harmony and peace?

              Perplexed minds want to know
              /Baran G Galocy/

              Comment


              • #8


                SoftwareSerial uses interrupts for receiving data but not for transmitting (bit banging). It disables ALL interrupts during bit transmissions which means it also disables receive interrupts. Because of this, SoftwareSerial is not truly asynchronous (receive and send at the same time). This is the major issue with SoftwareSerial and the reason most prefer HardwareSerial.

                I am not sure why a single sendMessage should kill the code but in a loop, the disabling of interrupts during transmission may be enough to cause receive data corruption.

                I have a DHT22 and use a more recent library from https://github.com/markruys/arduino-DHT which works with several sensors including the DHT11.

                Because this has peaked my curiosity, I will be prototyping and testing your code later today. I have a serial data analyzer so I can look at the serial 4d display traffic to get some insights.

                CAN YOU PLEASE POST YOUR VISI-GENIE FILE for the 4D Display.

                Paul

                Comment


                • #9


                  Hi Paul,

                  My first post on this subject has that code at the end of my rant. The offensive parts have been commented out.

                  Thank you so much for your information about the softwareserial failure. Wowzer - I would have never seen that!

                  I will now go play with said same code while shifting my serial communications back to pins 0 & 1 and see what happens.

                  Thanks - Baran
                  /Baran G Galocy/

                  Comment


                  • #10


                    Oops, the Visi-Genie file. Right.

                    Here it is. It will read the temperature (F) and humidity on the first page, temperature (C) on the third page, and humidity set and read (gauge reads - digits show set) on the fourth page. The second page (lights) has my four sliders and reset button.

                    OK - here it is not. I can open it in my Windows Explorer to edit in word++, but it is too long 169kb to cut and paste and the file attachment device on this web site does not "see" the Visi-Genie folder.

                    Suffice it to say that I combined the thermometer sketch and the RGB LED sketch and adjusted a few addresses for different widgets. You can take the thermometer sketch and change the degrees (C) [does anybody really use that;] to humidity.
                    /Baran G Galocy/

                    Comment


                    • #11


                      Just do an "Attach Files" at the bottom of the reply dialog.

                      Comment


                      • #12


                        /Baran G Galocy/

                        Comment


                        • #13


                          Hmmm.... nothing attached!

                          Comment


                          • #14


                            Sorry, the "Attach files" function DOES NOT "see" the file for the Visi-Genie like my Windows Explorer does - the folder is void of the same files shown in W.E., but I can not attach through Windows Explorer. The Visi-Genie search window only sees folders in my library folder, whereas my WE sees both folders and files, showing the 4D project file as a brown (round) icon.

                            I am now trying to re-write the Arduino code to simply use the built-in serial port on pins 0 & 1 and call it good - providing that works. WTF - Look ma, no hands . . .

                            Paul - you wrote: " SoftwareSerial is not truly asynchronous (receive and send at the same time). This is the major issue with SoftwareSerial and the reason most prefer HardwareSerial."

                            Thank You, THANK you, thank YOU, THANK YOU, et nauseum . . .

                            When I removed every "my" from the beginning of every "serial", things started working as they should have, all along. I would have gone to my grave believing in the wonders of SoftwareSerial, only to be disappointed in the "deadware" nature of it.

                            Your input has re-put me back onto my project.

                            Oh yeah, thanks - Baran
                            /Baran G Galocy/

                            Comment


                            • #15


                              Baran,

                              I am very happy to hear that! Now, you can use the full VisiGenie library which is WAY more robust and easily goes to 115Kbaud. I did some tests and found I could do 80-140 writeObjects per second depending on the size of the object on the screen (bigger takes longer) and the complexity of the object (LED Digits take less time than a cool gauge for example).

                              The library uses HardwareSerial in the background and can work on any port if your board has more than one (Mega 2560 for example). I highly recommend using it.

                              Cheers!

                              Paul

                              Comment

                              Working...
                              X