Jump to content

roadrunner84

Members
  • Content Count

    1,370
  • Joined

  • Last visited

  • Days Won

    33

Reputation Activity

  1. Like
    roadrunner84 got a reaction from Fmilburn in EXP430(G2553) Problem with Timer1 using ACLK (SOLVED)   
    I think your problem is related to the crystal.
    The crystal is connected to P2.6 and P2.7, but you overwrite P2SEL and P2DIR with non-default values.
    As a result, the crystal is not controlled correctly anymore and ACLK is dead.
    To avoid this problem, try to use |= and &=~ as much as possible to set or clear bits.
    P1SEL |= BIT1; // set SEL1 bit 1 P1SEL &= ~BIT2; // clear SEL1 bit 2 P1SEL |= (BIT1 | BIT2); // set SEL1 bit 1 and 2 P1SEL &= ~(BIT1 | BIT2); // clear SEL1 bit 1 and 2 P1SEL = (P1SEL | BIT1) & ~BIT2; // set SEL1 bit 1 and clear bit 2
  2. Like
    roadrunner84 got a reaction from Fmilburn in SPI and I2C on same pin   
    No you can't, since your SPI device can send data through P1.6 to your MSP430, you can't make certain that no accidental START token is present on the pins during SPI mode.
    Also, I2C pins are common-collector; they use a pull up resistor and only pull the line down. While SPI is push-pull; it driver the line either high or low. Driving the line high while your I2C device (accidentally, after interpreting a START token) pulls it low might cause damage to the driver on either side of the line.
    A way to maybe make it possible is by having some external hardware to disable SCL while in SPI mode. Since in SPI mode you'd have your CS# line low, you could use a single transistor to have P1.6 disconnect from your SCL net during SPI mode.
    +3v3 | | +-+ |2| |k| |2| +-+ | +-+----------> to device SCL pin | |/ C MSP430 CS# pin--| NPN-transistor |\ E | | MSP430 P1.6 ------+------------< to device MISO pin
  3. Like
    roadrunner84 got a reaction from Fmilburn in SPI and I2C on same pin   
    No you can't, since your SPI device can send data through P1.6 to your MSP430, you can't make certain that no accidental START token is present on the pins during SPI mode.
    Also, I2C pins are common-collector; they use a pull up resistor and only pull the line down. While SPI is push-pull; it driver the line either high or low. Driving the line high while your I2C device (accidentally, after interpreting a START token) pulls it low might cause damage to the driver on either side of the line.
    A way to maybe make it possible is by having some external hardware to disable SCL while in SPI mode. Since in SPI mode you'd have your CS# line low, you could use a single transistor to have P1.6 disconnect from your SCL net during SPI mode.
    +3v3 | | +-+ |2| |k| |2| +-+ | +-+----------> to device SCL pin | |/ C MSP430 CS# pin--| NPN-transistor |\ E | | MSP430 P1.6 ------+------------< to device MISO pin
  4. Like
    roadrunner84 got a reaction from tripwire in RANT: Cloud of this, IoT of that . . .   
    This makes me think about a book I read a decade or so back: When Things Start to Think. For me, this book was a complete paradigm shift about what connectivity could be used for. There's lot of anecdotes in the book about things that are, that were and failed and where the future (which is now) is heading. I agree that a lot of IoT is just screaming to get pushed onto the market, but there are products that actually add a benefit to your life which are or might be classified as IoT.
     
    I think there is a slight difference between M2M and IoT. M2M is about machine interaction and machine monitoring, while IoT is about human interaction with machines in a more immersive way than the mouse/keyboard/screen. Alas, most IoT solutions nowadays interact through smartphones, which are these stupid screens again.
    Genuine Things (note the capital T) do not interact through a smartphone or website, they interact through other Things. For example, I do not want to switch on my coffeepot through scheduling it in my calendar, I want my coffeepot to figure out when I want coffee and have coffee ready when I want it. The pot can do so by querying my phone, watch (which monitors when I am asleep or not), my door lock, my alarm clock, my car, etc. I think Things are about smartness, not about connectivity.
     
    Cloud is different from servers, although just slightly. Cloud is about virtualization. Cloud is a server(park) that allows clients (or yourself) to use a virtual machine (IaaS), virtual back end (PaaS) or virtual application (SaaS) while not paying for the physical servers. Cloud is about being able to migrate machines from one cloud provider to another, unlike renting a dedicated server, which must be either physically moved or backuped and restored in another physical location. I still think a virtualization pool is a better name than a cloud, but cloud just has a better ring to it.
  5. Like
    roadrunner84 got a reaction from tripwire in RANT: Cloud of this, IoT of that . . .   
    This makes me think about a book I read a decade or so back: When Things Start to Think. For me, this book was a complete paradigm shift about what connectivity could be used for. There's lot of anecdotes in the book about things that are, that were and failed and where the future (which is now) is heading. I agree that a lot of IoT is just screaming to get pushed onto the market, but there are products that actually add a benefit to your life which are or might be classified as IoT.
     
    I think there is a slight difference between M2M and IoT. M2M is about machine interaction and machine monitoring, while IoT is about human interaction with machines in a more immersive way than the mouse/keyboard/screen. Alas, most IoT solutions nowadays interact through smartphones, which are these stupid screens again.
    Genuine Things (note the capital T) do not interact through a smartphone or website, they interact through other Things. For example, I do not want to switch on my coffeepot through scheduling it in my calendar, I want my coffeepot to figure out when I want coffee and have coffee ready when I want it. The pot can do so by querying my phone, watch (which monitors when I am asleep or not), my door lock, my alarm clock, my car, etc. I think Things are about smartness, not about connectivity.
     
    Cloud is different from servers, although just slightly. Cloud is about virtualization. Cloud is a server(park) that allows clients (or yourself) to use a virtual machine (IaaS), virtual back end (PaaS) or virtual application (SaaS) while not paying for the physical servers. Cloud is about being able to migrate machines from one cloud provider to another, unlike renting a dedicated server, which must be either physically moved or backuped and restored in another physical location. I still think a virtualization pool is a better name than a cloud, but cloud just has a better ring to it.
  6. Like
    roadrunner84 reacted to spirilis in RANT: Cloud of this, IoT of that . . .   
    The real problem always boils down to the ownership IMO. Cloud this, cloud that smells offensively to me of greedy entrepreneurs trying to shoehorn a rent-seeking paradigm into something that should be anything but. It's stunting the widespread adoption IMO by keeping it only within the realm of the wealthy and early-adopting type of folks. The terms themself in combination with the verbiage used around it defines the space of what people know and think about, to the marketer's advantage.
  7. Like
    roadrunner84 reacted to zeke in RANT: Cloud of this, IoT of that . . .   
    Ten years ago, IoT used to be labeled M2M or machine to machine. It was a fad as well.
     
    It's crazy how marketing can make me feel like my work is worthless unless I implement "that one killer feature".
     
    I think it's best for me to ignore the false sense of inadequacy and just be awesome at doing and making the things that I like.
  8. Like
    roadrunner84 reacted to tripwire in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  9. Like
    roadrunner84 reacted to greeeg in msp430 security fuse blow   
    @@roadrunner84 Only devices requiring High-voltage fuse blow feature a real 'fuse' I know that the FRAM line is just a software 'fuse' which disabled JTAG access, using the BSL with an unknown password allows you to erase the device, and in the process unlock the device.
     
    I believe the really early devices (FR5739) had this problem with mspdebug, since this 'fuse' was located in the interrupt vectors... I had to use a launchpad to enter the BSL and erase the device a few times.
    I didn't think this was a problem with newer devices.
  10. Like
    roadrunner84 reacted to terjeio in PCB Laser Exposer/Printer   
    Here are the files for my PCB Exposer/Printer, it is the complete package including mechanical design files.
     

    The printer itself.
     

    Example - a power control PCB for Raspberry Pi - 40 x 40 mm.
     
    Code includes driver for MCP4725 DAC, buffered serial port driver, stepper motor control and command parsing for the MSP430G2553 used as the main controller.
     
    Code and design files:
     
    PCB Exposer - controller code for MSP430G2553.zip
    PCB Exposer - desktop application.zip
    PCB Exposer - mechanical design files in Vectric format.zip
    PCB Exposer - schematics and PCBs.zip
     
    Desktop application is coded in C#, schematics and PCBs in KiCad format.
     
    There is some more information to be found in this tread:
    http://forum.43oh.com/topic/4990-what-are-you-doing-right-now/page-5
     
    Terje
     
     
  11. Like
    roadrunner84 reacted to zeke in The Marquee Clock   
    The Ikea clock is the light diffuser. It's installed in the second video.
     
    These pcb's were made in China. The Korean board house was on a very long holiday when I wanted them to make them. So I jumped to a different fab house because I was under pressure to get them done before a deadline.
     
    The Canadian flag is just me showing my pride. It's staying on there.
  12. Like
    roadrunner84 got a reaction from tripwire in Detecting msp430g2553 package (28/20 pins)   
    You'll need to wire the pin to detect it. But you could wire it to (for example) the Rx pin on the debugger's UART, then you would be able to detect it when using a script. If the UART pin is space (1) the line will report it to be idle, when the line is mark (0) for at least 10 bit times the line will report frame error. So you could upload one firmware for a frame error, and the other for an idle line.
    For such a script, use anything like, bash, power shell or python. This script will first upload the "set a pin" firmware, then read the Rx UART line and then flash a conditional firmware using the command line tools provided by TI.
  13. Like
    roadrunner84 got a reaction from curtis63 in Access to all MSP430 timers.   
    There are multiple types of timers, of which one, more or no peripherals may be present in any specific msp430.
    For example, the msp430g2553 has the WDT+ module, in addition to two Timer_A modules. Each of those timers has three capture/compare registers.
    The msp430fr2532 on the other hand has four Timer_A modules, of which two have two CC registers, and two have three CC registers.
    As you can see, the existence of a certain module does not mean it is present in your specific type.
  14. Like
    roadrunner84 got a reaction from abecedarian in Putting a While Loop within a While Loops   
    That is not my code, that's OP's code, but with nice indentation
    As I said directly below that code block:
    Eventually the values of OP's code would settle to 0 and 255 or mean out to anything that's a sum of those. Since I later optimize fadeValue2 away, the only thing undefined is fadeValue, but that's limited to the 0 to 255 range because of the constrain() call. This means the only thing undefined is where in the settling/oscillation loop the sketch begins, which is okay-ish.
     
    A little more speedy, based on my latest code example.
    As you know you can haul values to the other side of the equation
    a / b = c a = c * b You can do this too to the voltage variable, allowing for you to get rid of the float variable alltogether:
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= 12 * 55.0 ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } See how I moved the / 55.0 to the other side of the equation in the ternary operator.
    Now since voltage is always an integer value (analogRead gives us an integer value), we can know for sure that the float behaviour is not required:
    int voltage; void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= 12 * 55 ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } see how I changes 55.0 to 55, no float constants, so no float calculations.
    Now consider that 55 is a bit magic, (as is 12), consider moving those to constants.
    #define Threshold (12) #define VoltScale (55) /* 5.65 times the voltage at the analog pin ( 3.3 * 5.65 / 1024) */ int voltage; void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= Threshold * VoltScale ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } Well, now there is really no good use for the voltage temporary variable:
    #define Threshold (12) #define VoltScale (55) /* 5.65 times the voltage at the analog pin; 1/(3.3 * 5.65 / 1024) */ void loop() { fadeValue += (analogRead(voltPin) >= Threshold * VoltScale ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); }
  15. Like
    roadrunner84 got a reaction from greeeg in MSP430 USB Bootloader   
    No, yes, maybe.
    The msp430 controllers have either JTAG or SbW for programming. In addition to that, some have a UART bootloader that allows you to update it over a single specified UART, but only after using a specific startup sequence on the reset and test pins.
    So in this case; no, you cannot flash the msp430 over SPI or I2C.
     
    Since the msp430 uses a Von Neumann architecture, you can reprogram the flash memory from the application running inside the msp430 itself. So if you'd make an application that runs from RAM, you can reprogram the flash memory from inside your application. If you write an application that acts as an I2C or SPI slave, you could make it flash the msp430, but there is no default option to do so.
    So in this case; yes, but you'll have to make it yourself.
  16. Like
    roadrunner84 reacted to spirilis in Low energy API: reduced transmit power, reduced clock ?   
    fwiw, this is something everyone gets a little wrong (and/or make up the details if they didn't already know), but on MSP430's Energia core, delay() always used LPM0 ;-)  Not a terribly "power efficient" sleep but a LPM mode nonetheless.  SMCLK would stay running for proper UART I/O etc.
     
    It's the new sleep, sleepSeconds, suspend calls that use LPM3/4 or whatever the Tiva, other ARM equivalents have.
     
    I do believe delay() always ran a busy-wait on Tiva and other ARM platforms though.
  17. Like
    roadrunner84 got a reaction from zeke in Stupidest Thing you had to Troubleshoot?   
    printf and friends are very hungry beasts, for integer to hex string and vice versa I prefer manual conversions.
    const char *const hex = "0123456789ABCDEF"; unsigned long input = 10; char output[9]; char *result = output; for(unsigned int ctr = 28; ctr; ctr -= 4) *result++ = hex[(input >> ctr) & 0xF]; *result = '\0'; something like this.
  18. Like
    roadrunner84 got a reaction from Pat in Low energy API: reduced transmit power, reduced clock ?   
    Yeah, that part of my signature might become obsolete. delay() used to loop until the set time has elapsed, essentially "burning" CPU time. Better to set a timer and go to low power mode. The low power mode you can use depends on which functions you need to operate while in pow power.
    Newer Energia releases use low power during delay(). Delay cycles still burns CPU time, so you shouldn't use that.
  19. Like
    roadrunner84 reacted to greeeg in Stupidest Thing you had to Troubleshoot?   
    Just yesterday I was battling with a atmega328pb (more internal peripherals than standard atmega328p). Specifically I wanted to use the UART1 port to receive data from a GPS. My old setup uses a software serial implementation.
     
    After a whole day of debugging this second port not working. I'd concluded UART0 TX and RX worked fine. UART1 TX worked fine, but no RX. My scope was showing the serial stream from the GPS. All the pins were correct.
     
    Turns out the AVR wasn't registering the HIGH level from the GPS (3v) as HIGH because it's running from 5v. /facepalm
    Didn't even consider it a factor since the atmega328p worked with the 3v signal fine.
     
    Adding a level translator and everything just works.
  20. Like
    roadrunner84 got a reaction from Pat in Low energy API: reduced transmit power, reduced clock ?   
    I'm not an expert on the CC320, but I do know a little about low power.
    Reducing clock speed can work two ways:
    1) it elongates the time spent in wake mode, causing more battery drain. Thus upping the clock might be beneficial. This is called run to completion.
    2) upping the clock speed causes higher currents, which in turn may cause a lower voltage. A lower voltage may result in brown outs, thus your battery will be too empty to use earlier on, while it would have lasted in a lower current mode.
    Which approach is best for you depends on your requirements, but keep both of these in mind.
  21. Like
    roadrunner84 got a reaction from Derekspeegle in Putting a While Loop within a While Loops   
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin) / 55.0; //If the priority is high while(voltage >= 12) { fadeValue = constrain(fadeValue, 0, 255); fadeValue2 = constrain(fadeValue2, 0, 255); voltage = analogRead(voltPin) / 55.0; fadeValue = fadeValue + 10; fadeValue2 = fadeValue2 - 10; analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, fadeValue2); } // If priority is low while(voltage < 12) { fadeValue = constrain(fadeValue, 0, 255); fadeValue2 = constrain(fadeValue2, 0, 255); voltage = analogRead(voltPin) / 55.0; fadeValue = fadeValue - 10; fadeValue2 = fadeValue2 + 10; analogWrite(voltoutPin2, fadeValue2); analogWrite(voltoutPin, fadeValue); } } I cleaned up the spacing in your code, as you can see, the only difference between the two blocks is the sign of the changes to fadeValue and fadeValue2. You could consider moving the rest of the code to a common place. Or, to move the constrain() call into the update of fadeValue(2).
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin) / 55.0; //If the priority is high while(voltage >= 12) { voltage = analogRead(voltPin) / 55.0; fadeValue = constrain(fadeValue + 10, 0, 255); fadeValue2 = constrain(fadeValue2 - 10, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, fadeValue2); } // If priority is low while(voltage < 12) { voltage = analogRead(voltPin) / 55.0; fadeValue = constrain(fadeValue - 10, 0, 255); fadeValue2 = constrain(fadeValue2 + 10, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, fadeValue2); } } Also, I guess you're trying make some kind of fade in/out function, which is not what you're really doing. The while loops will be so fast that there is no real fading. The gross result will be that the outputs will drift to some mean point, or maybe oscillate a little around that value at a very high frequency. I assumed in this that voltoutPin and voltPin are tied together, an analog lagging filter would of course result in some kind of slower sinoid signal.
    It triggers me that your two cases seem to be exactly opposite in behavior. You might consider removing those while loops alltogether, since loop() is a loop itself.
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin) / 55.0; if(voltage >= 12) // high priority { fadeValue = constrain(fadeValue + 10, 0, 255); fadeValue2 = constrain(fadeValue2 - 10, 0, 255); } else // low priority { fadeValue = constrain(fadeValue - 10, 0, 255); fadeValue2 = constrain(fadeValue2 + 10, 0, 255); } analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, fadeValue2); } Then, in setup() you set either fadeValue or fadeValue2 to 255, the other to 0. Why not do that calculation on the spot, since you'd always have the sum of fadeValue and fadeValue2 be 255.
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin) / 55.0; if(voltage >= 12) // high priority fadeValue = constrain(fadeValue + 10, 0, 255); else // low priority fadeValue = constrain(fadeValue - 10, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } And lastly, I'd like to introduce you to the ternary operator, use it with care, also it might make your code a little more obscure.
    The ternary operator is written like this
    (condition) ? (true-value) : (false-value) In contrast to the if() ... else ... construction, the ternary operator returns a value, it is not intended to run statements. Example:
    food = (animal == monkey) ? banana : grass; so if the animal variable is monkey, food becomes banana, otherwise it becomes grass.
    Another example, now with real values
    abs_val = (val > 0) ? val : -val; This will check is val is positive, then abs_val becomes that val, otherwise abs_val becomes the negative of val, and the negative of a non-positive number is a positive number itself. So now we have abs_val containing the absolute value of val.
     
    In your code, you either add 10 or subtract 10 depending on a condition (voltage >= 12), adding -10 is the same as subtracting 10, so we could either add 10 or -10 depending on your condition:
    fadeValue = constrain(fadeValue + ((voltage >= 12) ? 10 : -10), 0, 255); Note that for readabilities sake I put the ternary operator between braces, though that's not necessary.
    Your code would become:
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin) / 55.0; fadeValue = constrain(fadeValue + (voltage >= 12 ? 10 : -10), 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } You see that the code might become a little harder to read, also it does not speed your code up; the compiler will do something very similar to what it already did.
    Note that voltage is now only used once, so you could slide that in too, but your code would become even more obscure and it would not speed anything up either.
    A little more readable:
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin) / 55.0; fadeValue += (voltage >= 12 ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); }
  22. Like
    roadrunner84 got a reaction from abecedarian in Putting a While Loop within a While Loops   
    That is not my code, that's OP's code, but with nice indentation
    As I said directly below that code block:
    Eventually the values of OP's code would settle to 0 and 255 or mean out to anything that's a sum of those. Since I later optimize fadeValue2 away, the only thing undefined is fadeValue, but that's limited to the 0 to 255 range because of the constrain() call. This means the only thing undefined is where in the settling/oscillation loop the sketch begins, which is okay-ish.
     
    A little more speedy, based on my latest code example.
    As you know you can haul values to the other side of the equation
    a / b = c a = c * b You can do this too to the voltage variable, allowing for you to get rid of the float variable alltogether:
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= 12 * 55.0 ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } See how I moved the / 55.0 to the other side of the equation in the ternary operator.
    Now since voltage is always an integer value (analogRead gives us an integer value), we can know for sure that the float behaviour is not required:
    int voltage; void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= 12 * 55 ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } see how I changes 55.0 to 55, no float constants, so no float calculations.
    Now consider that 55 is a bit magic, (as is 12), consider moving those to constants.
    #define Threshold (12) #define VoltScale (55) /* 5.65 times the voltage at the analog pin ( 3.3 * 5.65 / 1024) */ int voltage; void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= Threshold * VoltScale ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } Well, now there is really no good use for the voltage temporary variable:
    #define Threshold (12) #define VoltScale (55) /* 5.65 times the voltage at the analog pin; 1/(3.3 * 5.65 / 1024) */ void loop() { fadeValue += (analogRead(voltPin) >= Threshold * VoltScale ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); }
  23. Like
    roadrunner84 got a reaction from abecedarian in Putting a While Loop within a While Loops   
    That is not my code, that's OP's code, but with nice indentation
    As I said directly below that code block:
    Eventually the values of OP's code would settle to 0 and 255 or mean out to anything that's a sum of those. Since I later optimize fadeValue2 away, the only thing undefined is fadeValue, but that's limited to the 0 to 255 range because of the constrain() call. This means the only thing undefined is where in the settling/oscillation loop the sketch begins, which is okay-ish.
     
    A little more speedy, based on my latest code example.
    As you know you can haul values to the other side of the equation
    a / b = c a = c * b You can do this too to the voltage variable, allowing for you to get rid of the float variable alltogether:
    void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= 12 * 55.0 ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } See how I moved the / 55.0 to the other side of the equation in the ternary operator.
    Now since voltage is always an integer value (analogRead gives us an integer value), we can know for sure that the float behaviour is not required:
    int voltage; void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= 12 * 55 ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } see how I changes 55.0 to 55, no float constants, so no float calculations.
    Now consider that 55 is a bit magic, (as is 12), consider moving those to constants.
    #define Threshold (12) #define VoltScale (55) /* 5.65 times the voltage at the analog pin ( 3.3 * 5.65 / 1024) */ int voltage; void loop() { //Obtain RAW voltage data voltage = analogRead(voltPin); fadeValue += (voltage >= Threshold * VoltScale ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); } Well, now there is really no good use for the voltage temporary variable:
    #define Threshold (12) #define VoltScale (55) /* 5.65 times the voltage at the analog pin; 1/(3.3 * 5.65 / 1024) */ void loop() { fadeValue += (analogRead(voltPin) >= Threshold * VoltScale ? 10 : -10); fadeValue = constrain(fadeValue, 0, 255); analogWrite(voltoutPin, fadeValue); analogWrite(voltoutPin2, 255 - fadeValue); }
  24. Like
    roadrunner84 reacted to Ymir in Guitar Tuner   
    Hi everyone!
     
    im trying to create a guitar tuner with my tm4c1294 but im having some problems. I also would like to use Systick .
     
    The problem is that it not detect well the frecuency, "tiempo" variable doesnt increment as fast as it should. It should detect frequencies between 80 - 330Hz but doesnt detect anything
     
    Could any one help me?
     
    Thanks
    #include <stdint.h> #include "driverlib\systick.h" #include "driverlib\systick.c" #include "driverlib/sysctl.h" #include "driverlib/adc.h" unsigned long start_times[10]; unsigned long stop_times[10]; int long Vin; int datoA; float frecuencia; float pendiente; float tiempo; int contador;                                     #define TickerPeriod 16777215 #define ADCpin1 27 void setup() {   SysTickDisable();                      // Deshabilita SysTick durante la configuracion   SysTickPeriodSet(TickerPeriod);             // Define el periodo del contador. Al llegar a cero genera la intrrupcion   SysTickIntRegister(&Ticker);   // Se vincula a la ISR de la interrupción causada por el SysTick   SysTickIntEnable();                    // Se habilita la interrupción del SysTick   SysTickEnable();                       // Se habilita el SysTick, después de haber sido configurado   IntMasterEnable();                     // Se habilitan todas las interrupciones   Serial.begin(9600);   //ADC configuration   ROM_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC0); //enables a peripheral                     ROM_ADCSequenceConfigure(ADC0_BASE, 3, ADC_TRIGGER_PROCESSOR, 0); // Configures the trigger source and priority of a sample sequence.   ROM_ADCHardwareOversampleConfigure(ADC0_BASE,0); //Configures the hardware oversampling factor of the ADC.   ROM_ADCSequenceEnable(ADC0_BASE, 3); //enables a sample sequence.            ROM_ADCIntClear(ADC0_BASE, 3); //Clears sample sequence interrupt source. } void loop() {   frecuencia = (stop_times[1] - start_times[1])*float(tiempo); if (contador = 20) {   Serial.print("\nADC = ");      Serial.print(Vin);   Serial.print("\tTiempo captura = ");      Serial.print(stop_times[1] - start_times[1]);   Serial.print("\tPendiente = ");      Serial.print(pendiente);   Serial.print("\tFrecuencia = ");      Serial.print(frecuencia);      contador = 0; } } void Ticker()                           {   start_times[1] = micros();   Vin = analogRead1(ADCpin1);   pendiente = Vin - datoA;      datoA = Vin;   if (pendiente > 1 && Vin > 2047)   {     tiempo++;   }   if (Vin < 2047)   {     tiempo = 0;   }   if(pendiente < 0 && Vin > 2047)   {     tiempo = 0;   }   contador++;   stop_times[1] = micros(); } uint16_t analogRead1(uint8_t pin) {   uint16_t value[1];   uint32_t channel = digitalPinToADCIn(pin);   ROM_ADCSequenceStepConfigure(ADC0_BASE, 3, 0, channel | ADC_CTL_IE | ADC_CTL_END); // This function configures the ADC for one step of a sample sequence.   if (channel == NOT_ON_ADC)    { //invalid ADC pin     return 0;   }   ROM_ADCProcessorTrigger(ADC0_BASE, 3); // Causes a processor trigger for a sample sequence.   while(!ROM_ADCIntStatus(ADC0_BASE, 3, false))   { //Gets the current interrupt status.   }   ROM_ADCIntClear(ADC0_BASE, 3); //Clears sample sequence interrupt source.   ROM_ADCSequenceDataGet(ADC0_BASE, 3, (unsigned long*) value); //Gets the captured data for a sample sequence.   return value[0]; }
  25. Like
    roadrunner84 got a reaction from energia in Ultra sonic is limited range   
    Soft surfaces absorb a lot of sound, is your surface hard enough?
×