Jump to content
43oh

Fmilburn

Members
  • Content Count

    618
  • Joined

  • Last visited

  • Days Won

    81

Posts posted by Fmilburn

  1.  

    the second code (water flow) is to ARDUINO IDE.

    i have to integrate this two codes to work in energia..

    Have you tried getting the Arduino code working in Energia by itself?   If not, try to get it working in Energia before combining the two.  It does not look like you have done basic "porting" to get it to work in Energia. 

     

    For example, this: 

    byte sensorInterrupt = 0;  // 0 = digital pin 2
    

    The comment says it is supposed to be digital pin 2 but the variable says 0.  And there is no pin 0 in Energia.  You are also writing to pin 13 and calling it the status LED.  Pin 13 is the red LED on an Arduino.  In Energia it is RED_LED.  The code looks like it should be easy to get it going but you must carefully map the pins.

  2. I agree.  Maybe upon issuing a userid there is a notice directing them to a post about netiquette.  In addition, many of them don't know how to provide the basic information needed to get a meaningful response to their questions.

  3. If you are using Energia, try this one which I have used with success: http://playground.arduino.cc/Code/PIDLibrary

     

    There are some very good links behind it on practical use and the derivation. Also do a search for PID on 43oh for posts on everything from balancing robots to sous-vide. Your implementation will depend on how fast the system you are trying to control reacts and how stable it is.

  4. This post covers my experiences with a Sharp IR sensor marked 2YOA2I F 7I  I received courtesy of @@bluehash clearing his desk a while back.

    post-45284-0-13260500-1486779027_thumb.jpg

    Sharp IR sensors can be obtained that cover ranges from 4 - 30 cm up to 100 - 550 cm.   This one has a listed range of 10 - 80 cm. The coverage envelope / angle was not listed in the data sheet but seemed relatively narrow. Current consumption is around 30 mA on average.   Response time is listed as 39 ms.  The output from the sensor is an analog voltage which is inversely proportional to the distance in a nonlinear manner.

     

    Of particular note to those using TI microcontrollers is that it is a 5V device (the datasheet gives 4.5 to 5.5 V as the operating range for Vcc).  Most of my gizmos run off of 2 batteries at nominally 3V so I was interested in how it would work at lower voltages and ran a series of tests.  A bench power supply was used to supply constant voltage at 5.0, 4.5, 3.3, 3.0, and 2.5 Volts (accurate to better than 0.1 V).  I used a tape to measure the distance from the face of the sensor to a wall (distance accurate to 2 mm).  The voltage was measured with a digital multimeter and plotted against the inverse of distance to give a more linear curve.

     

    Here are the results:

    post-45284-0-23082900-1486779168_thumb.jpg

    With Vcc set to 5.0 V and 4.5 V the output difference was minimal - the results are for all practical purposes the same and are in line with the datasheet.  The data for Vcc at 3.3 V and 3.0 V might be usable with the understanding that the curves began to offset some as Vcc drops, and that at 3.0 V the accuracy falls off at 15 cm, and at 3.3 V it falls off at 10 cm.  The sensor is not usable at 2.5 V.

     

    If highest accuracy is required, a test like the one described here can be undertaken instead of just using the curve in the datasheet.

  5. Per the error message, 'yield' was not declared in this scope

     

    If you look in the code....

    long HX711::read() {
    	// wait for the chip to become ready
    	while (!is_ready()) {
    		// Will do nothing on Arduino but prevent resets of ESP8266 (Watchdog Issue)
    		yield();
    	}
    

    So it appears that yield() is only needed for the ESP8266.  You can try going through and commenting out yield() wherever it occurs.

  6. dAISy Hat for the Raspberry Pi

     

    I have been using the new dAISy hat for the Raspberry Pi for a while now with OpenCPN and thought I would make a post.  I find it very usable on a RPi 3 (much improved over the RPi 2) and have seen improved reception with the two channel dAISy receiver as well.  Below is a screenshot of the most recent version of OpenCPN (4.5.0) running on a Raspberry Pi 3 with the latest Raspbian and

    post-45284-0-59931800-1486509915_thumb.jpg

  7. @@Deep97

     

    It isn't really possible to tell what the problem is from the information you have provided.  I am going to assume that you are able to have serial print elsewhere without a problem using Energia.   I had a quick peek at the code and it seems reasonably well structured and commented.  Now that it compiles you have a couple of choices.  There is debug print in the code - try turning that on and see what it tells you.  You can insert your own debug print.  The Code Composer Studio debugger is very useful for problems like these.  There is a learning curve to Code Composer Studio but it is well worth it when debugging.

  8. I recently became interested in Finite State Machines and ended up writing a tutorial which has been posted on the 43oh blog:  http://43oh.com/2017/02/how-to-implement-finite-state-machines-using-energia/

     

    The example uses Energia but adapting it to C / C++ for use with Code Composer Studio or other IDEs would be simple.  While conceptually easy, working through the details and applying the concepts in a more structured manner were instructive for me.  The tutorial is just an introduction but there are additional references at the bottom.  If you are aware of other good resources feel free to post them below.

  9. I never noticed before, but Arduino has a setClock member for Wire that Energia does not have. Try finding that call and comment it out. The compiler output you attached lists this as an error and gives the location. The rest of it on quick inspection seemed to be warnings.

  10. I have an older model of one of those commercial ultrasonic meters for measuring rooms and such - even it gives spurious results at times - and that is in a room with flat walls and not moving.  There are commonly used with slow moving robots by hobbyists and I've seen them used as an aid to park a car at slow speed in a garage and avoid hitting a wall.  I don't have any real expertise in this area though and can't make any recommendations....

  11. I find Energia suitable for many most of my projects. Much of the time direct register access is not needed.   But if you keep at it long enough and stretch the boundaries of what others have done and posted, then expect to encounter the limitations of Energia / Arduino or at least the need to understand what is happening at the register level.  It may be in terms of the software, the libraries, slow execution, lack of access to features, or that your desired microcontroller does not have an Energia port.  If you learn to directly access registers then all peripherals and capabilities are available. If you want to understand and port other libraries that use direct register access then clearly a deeper understanding is needed as well.  As long as you don't introduce a conflict then direct register programming and Energia work together fine and it is not one or the other.

     

    I would start with CCS and the workshop that L.R.A suggests if using the G2553.  There are also tutorials on using CCS.  I find the debugger in CCS invaluable even when using Energia.  Gaining familiarity with the datasheets, the family user guides, and header files was the most difficult part for me as I have no microcontroller or C/C++ background - but they are key.  My approach was to become proficient in Energia and then add the more traditional approach as I went along.  I even find that myself writing everything in CCS without Energia from time to time now ;)

  12. Hi @@speed07,

     

    The description in the link you provided states that the range is 2 cm to 450 cm which is similar to the inexpensive Chinese models.  You should not expect it to work well out to 4 meters.  The Chinese models I experimented with in small robots do "work" but have a relatively wide beam pattern that makes it hard to pick out objects and sometimes just giving spurious results.  Fun to play with but not reliable safety devices.  It will lack the rigorous testing and specifications of an automotive quality device - things like resistance to vibration, temperature, dust and dirt, moisture ....  

     

    It is interesting to see what the manufacturers are doing, e.g. http://newatlas.com/bmw-advanced-safety-concept-motorcycle/19119/

     

    EDIT:  Sorry, I should explain my thoughts better.  Here is a link on beam patterns: http://www.robot-electronics.co.uk/htm/sonar_faq.htm

     

    For the wider patterns, you may pick up unwanted lateral targets.  I found the models I had unreliable past about 2 meters and also if there was anything to the sides that might cause reflection.  Lidar is more accurate and more expensive.  Cameras are also used in the high end systems.

  13. Hi @@russellrdover and welcome to 43oh.

     

    The FR6989 is a really nice LaunchPad.  The firmware that comes on the LP demonstrates the temperature sensor and LCD of course and source is provided for Code Composer Studio and IAR:  http://software-dl.ti.com/msp430/msp430_public_sw/mcu/msp430/MSP-EXP430FR6989/latest/index_FDS.html

     

    Energia also has a library for the display and there is discussion here on 43oh on using the internal temperature sensor for the MSP430 family.

  14.  

    You used UCA0 in your example, whats the difference between it and UCB0? If i take your configuration settings and apply it to my code as UCB0 on P1.7, it *seems* to work, but eventually messes up. Could it be because my device isnt calibrated properly? or would it be because of the capacitor you mentioned

     

    From the family user guide, slau144j, pg 436:

     

    The USCI_Ax modules support:

     

  15. I had a quick look at your code and I suspect there are multiple problems.  For example, in main_working_95.c

        // DCO Speed Divider
        UCB0BR0 = 3.2;
    
    

    You can't put a floating point number into a register and I don't think this is doing what you want it to.  If you are new to registers on microcontrollers I suggest The TI workshop at http://processors.wiki.ti.com/index.php/Category:CCSv6_Training#Workshops_and_Modules

     

    I think you can modify the CCS code I posted in the link @@LiviuM referred to and make it work.  Here is my quick edit of the code:

    // Runs on G2553 at 8 MHz
    // Output is on pin P1_2 (MOSI)
    
    #include <msp430.h>
    
    #define SPIDIV     0x02                         // 8 MHz/2 gives ~250 ns for each on bit in byte       <=====
    #define SPILONG    0b11111000                   // 1250 ns on, 750 ns off                              <=====
    #define SPISHORT   0b11100000                   // 750 ns on, 1250 ns off                              <=====
    
    void initClock();
    void initSPI();
    void initWS2812();
    void sendByte (unsigned char ;
    void sendPixel (unsigned char r, unsigned char g, unsigned char ;
    void show();
    
    int main(void)
    {
      WDTCTL = WDTPW + WDTHOLD;                     // Stop watchdog timer
    
      initClock();
      initSPI();
      initWS2812();
    
      while(1){
          sendPixel(0xFF, 0xFF, 0xFF);               // show all ones                                     <======
    //    sendPixel(0x00, 0x00, 0x00);               // show all zero                                     <======
          show();
      }
    }
    
    void initClock(){
        BCSCTL1 = CALBC1_8MHZ;                       // load calibrated data for 8 MHz                    <======
        DCOCTL = CALDCO_8MHZ;                        //                                                   <======
    }
    
    void initSPI(){
        P1SEL = BIT1 + BIT2 + BIT4;
        P1SEL2 = BIT1 + BIT2 + BIT4;
        UCA0CTL0 |= UCCKPL + UCMSB + UCMST + UCSYNC;  // 3-pin, 8-bit SPI master
        UCA0CTL1 |= UCSSEL_2;                         // SMCLK
        UCA0BR0 |= SPIDIV;                            // clock divider
        UCA0BR1 = 0;                                  //
        UCA0MCTL = 0;                                 // No modulation
        UCA0CTL1 &= ~UCSWRST;                         // **Initialize USCI state machine**
        IE2 |= UCA0RXIE;                              // Enable USCI0 RX interrupt
    }
    
    // Sends one byte to the LED strip by SPI.
    void sendByte (unsigned char {
        unsigned char bit;
        for (bit = 0; bit < 8; bit++){
          if (b & 0x80) // is high-order bit set?
              UCA0TXBUF = SPILONG;     // long on bit defined for each clock speed
          else
              UCA0TXBUF = SPISHORT;    // short on bit defined for each clock speed
          b <<= 1;                     // shift next bit into high-order position
        }
    }
    
    // Send a single pixel worth of information.  Turn interrupts off while using.
    void sendPixel (unsigned char r, unsigned char g, unsigned char {
        sendByte (g);        // NeoPixel wants colors in green-then-red-then-blue order
        sendByte (r);
        sendByte (;
    }
    
    // latch the colors
    void show(){
        __delay_cycles(72);            // 18 micro seconds
    }
    
    void initWS2812(){
        show ();                       // in case MOSI went high, latch in whatever we sent
        sendPixel (0, 0, 0);           // now change back to black
        show ();                       // and latch that
    }
    
    

    The main changes I made are:

    • In the function initClock() the clock speed is set to 8 MHz using the factory stored defaults.  The workshop linked above has a good overview of how to do this for the MSP430 family.
    • At the very top SPIDIV is set to 2 which means it is ticking at 4 MHz - a period of 250 ns.
    • Accordingly, the bytes defined in the next two lines will have the on/off periods that are shown - these happen to fall within the specifications given by the datasheet.

    You can test this with your oscilloscope.  In main() there is a line that sends all ones and another (commented out) that sends all zeros. This is what I see on my oscilloscope when the output is set to all ones:

    post-45284-0-92650500-1485205518_thumb.jpg

    The time divisions are set to 250 ns and  you can see that the wiggles are high for 1250 ns and then low for 750 ns.  Right on the money.  There is a lot of overshoot - that is why a 0.1 uF capacitor between the signal and ground is probably a good idea.  You can check your scope to see if it is doing what it should.

  16.  

    I tried these configuration settings but unfortunately it didnt work. It was outside the ranges for it to work right i guess. 

     

    I did 16Mhz / 10 to get 1.6MHz for 625ns. With LONG having 2 bits on, and SHORT having 1.

     

    The LEDs just turned on (white) even though i was sending it colors, so it was to far outside the range.

    I have learned not to comment on devices I haven't worked with before but here goes anyway ;)

     

    How did you set the clock and are you sure you got that correct?  If it is 625 ns then it would appear to be OK with LONG and SHORT as you have described it.  Did you post your code?  I didn't see it.

     

    What code are you using that gives 90-95% correct?  The schematic in the datasheet shows a capacitor between Vcc and GND - did you place that in your circuit?  Could possibly be something flaky because of that.

     

    It is really useful to have a logic analyzer for this type work, unfortunately mine isn't working at the moment.

  17. @@ZenClide

     

    The labels can be confusing.  Energia uses a pin numbering system that is consistent on all boards.  It starts with 3V3 (number 1) in the upper left, goes down to number 10 at lower left, and then starts up again on the other side at the bottom.  See for example the pin map at Energia for the CC3200:  http://energia.nu/wordpress/wp-content/uploads/2014/06/LaunchPads-CC3200-%E2%80%94-Pins-Maps-12-28.jpeg

     

    The pin map excerpt you have posted shows the same pin numbers right after the /* comments.

     

    So, pin 4 in Energia on the CC3200 is the same one that is labelled P03 on the board.  Energia pin 3 is labelled P04 on the board.  For Energia always use the Energia pin map and not the PCB labels.    The CC3200 User Manual refers to the PCB labels as the "Dev Pin#".  Use of port.pin type markings on LaunchPads has been deprecated in Energia.

×
×
  • Create New...