Jump to content


  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    gsutton reacted to nickn in The great question about the ESP8266 has been answered!   
    The CEO of Espressif has confirmed on Facebook that the I/O pins of the ESP8266 are 5V tolerant  . He also mentioned that the ESP32 and the ESP8285 I/O are also 5V tolerant.
  2. Like
    gsutton reacted to chicken in Need help understanding this code   
    @@ak96 Nothing wrong with preferring bare metal, my preference as well
    Take a look at the innards of the counter library, even if you don't plan to use Energia. It basically sets up a timer to count up when a pin changes from 0 to 1. Using the timer, you don't need an interrupt for the counting itself.
    The source code of the library may look a bit cryptic, because it tries to accommodate many different MSP430s. The gist is:
    1. Set GPIO pin as input and select it's function (PxSEL) as timer input. The timer input (TxxCLK) is only available on a few pins, consult your MCUs datasheet.
    2. Configure timer for external clock and continuous mode
    3. Functions to start, stop and reset the timer as well as reading out the current timer value.
    Run the timer for a known time, and the number of pulses will allow to determine the rate.
    That being said, not sure if that's the best approach for a heart rate monitor. Measuring the time between pulses might be more sensible:
    1. Start the timer, driven by one of the MSP's internal clocks. Use a divider to avoid overflowing the 16bit timer for the expected heart rate.
    2. Wait for a pulse on a pin. A busy loop reading the pin is probably good enough for a beginner project.
    3. When a pulse arrives, read the timer value.
    4. Calculate the rate using clock frequency, timer divider and measured timer value.
    I don't know what output signal heart rate monitors provide. If it's an analog wave form, you may need some circuitry to convert it to something that is usable for digital inputs and/or use the built-in comparator or ADC peripherals. 
  3. Like
    gsutton reacted to cubeberg in Need help understanding this code   
    At least in the MSP430 line, each mcu family has a bunch of examples that go with it.  If you're looking to go lower level than Energia (I prefer code composer for MSP430 as it's a pretty simple chip) - there are some great examples there.  There should be some timer examples - which allow you to count the number of ticks between events.  They also come with comments at the top of the file that explain what it does.  
    http://www.ti.com/product/MSP430G2553/toolssoftware#softTools - download the "Code Examples".
  4. Like
    gsutton reacted to chicken in Need help understanding this code   
    PS: If you're new to programming, take a look at Energia.
    There's a library for Energia, that makes it easy to count pulses with the MSP430.
  5. Like
    gsutton reacted to chicken in Need help understanding this code   
    The code in main.txt sets up interrupts that are triggered when pins change from high to low (falling edge). A counter J is increased by some of these interrupts.
    That being said, the code has quite a few issues. If this is not your code, I would look for a better example as this one will cause a lot of grief to get working. If it is your code, I suggest to first think about the structure of the program before reattempting the implementation.
    A few issues:
    - the variable j used by the interrupt routine to keep track of the pulses should be declared as volatile.
    - the setup of interrupts that configure interrupts is very convoluted and without further documentation, it will be hard to figure out how they interact and how the program is supposed to work
    - there are several interrupt routines that include printing out of date, this is bad practice and almost certainly will create issues.
  6. Like
    gsutton reacted to cubeberg in Trying to alternate blinking of two LEDs   
    My guess would be because you're not setting the initial state - you should set them explicitly instead of assuming state when your code executes.  Try P1OUT = 0x00; when you set P1DIR. or instead of P1OUT ^= 0x01, use P1OUT = 0x01;
  7. Like
    gsutton reacted to dubnet in Analog Devices RF Detector Kit offer for $5   
    I did order two, hesitated at the unknown shipping charges but proceeded thinking domestic ground shipping on less than a pound shouldn't be much. Bad assumption. The shipping weight was actually 2 pounds due to the marketing material included (at my expense) in each board's box. Long story short...the $5 boards ended up costing just under $14 each. I won't be using RichardsonRFPD again.
    You were wise to abort.
  8. Like
    gsutton reacted to cubeberg in Having trouble installing Code Composer.   
    Just "MSP ultra low power MCU" is what you need for the MSP430.  You can leave the rest of the options at their default (the normal debugger option is usually greyed out - you don't need any of the optional debuggers).  
    You don't have to install any of the app center tools - if anything seems interesting you can install - but you can always install those later as well.  
  9. Like
    gsutton reacted to bluehash in Have feedback for TI? Please share here.   
    Hello 43oh Members and Guests!
    In a few weeks, I'll have a chance to meet people within TI. Among them are those who work on the Launchpad platform, marketing, web team and designers of their micro-controllers+other chips that they offer.
    Do you have any good feedback for them? Do you have any critical feedback for them?(They would appreciate this) Any new features you would like them to add to their Launchpad platform?(pins/form-factor/buttons/debuggers/LED feedback) Any BoosterPack inputs? Any Energia inputs/concerns. The TI Store. The TI website(I'll have a chance to meet the web team too, feedback will be helpful) Web presence. Any more that you can think of.  
    TI is one of the few companies I know that try to get close the community. A few of them are members of 43oh, some helping out, some in stealth mode. So please use this opportunity to let them know your views. 
    Thank you all!
  10. Like
    gsutton reacted to Fmilburn in FFT   
    I am running out of suggestions and this is a bit out of my league but try this...
    Select File -> Preferences from the pulldown menu in Energia and select "Include debug information in the output ELF file" Look in the output window of Energia for wiring_analog.c - it may help to copy everything in the window and then paste it into a text editor and do a search You should find the location for wiring_analog.c (hopefully the same place you checked above) and the location where it put the object file Then select Sketch -> Show Compilation Folder where wiring_analog.c.d and wiring_analog.c.o should be present Can you see the files?  Do you see any new errors that might be pertinent?
  11. Like
    gsutton reacted to Fmilburn in FFT   
    Look inside your Energia folder for wiring_analog.c.  It will be located at \hardware\lm4f\cores\wiring_analog.c.  Do you see the following function inside it?
    void analogReadResolution(int res) { _readResolution = res; } I think this is what the TM4C129 should be calling.  If not, maybe someone else can tell us.
  12. Like
    gsutton reacted to NickTompkins in FFT   
    Here is some C code I have used to make the sine table for the fix_fft function if I wanted to change the size of the FFT
    #include <stdio.h> #include <math.h> #define POINTS 128 #define BITS   16 int main(void) {   int n;   int a=0;   int TF_FLAG=POINTS-POINTS/4; printf("#define N_WAVE      %d    /* full length of Sinewave[] */\n",POINTS); printf("#define LOG2_N_WAVE %d      /* log2(N_WAVE) */\n",(long)log2(POINTS)); printf("/* 3/4 of N_WAVE = %d  */\n",TF_FLAG); printf("const int8_t Sinewave[N_WAVE-N_WAVE/4] = {\n");   for (n=0; n<POINTS; n++){         if(n==TF_FLAG){           printf("/*");         }   if(a<15){     printf("%d,", (int)floor(0.5 + ((1 << (BITS-1)) - 0.50001) * sin(2 * 3.1415926535897932 / POINTS * n)));         a++;}        else{         a=0;         printf("%d,\n", (int)floor(0.5 + ((1 << (BITS-1)) - 0.50001) * sin(2 * 3.1415926535897932 / POINTS * n)));         } } printf("*/"); printf("};\n");   return 0; } You can copy and paste the output into your fix_fft.c file ;-)
  13. Like
    gsutton reacted to veryalive in FFT   
    @@Fmilburn.....  A very interesting writeup, thanks.   What a coincidence;   I am working with the AD9850 DDS module this week !
    Although your writeup is on FFTs done on ARM MSPs in the KHz range, here are some data and thoughts on the AD9850 DDS I captured which you, or others, may find useful.   Note that the DDS frequency range here is 7.0 MHz.   For instance, DDS spurs are not big at KHz, but being aware of them (as I'm sure you are!) is handy --  see 1 C    below.
    This info may be useful to folks embedding DDS into radio / signal processing devices and is part of an investigation I'm doing around :
     -- DDS - AD9850 module and breadboarded cousins: AD5930 (sweep); AD5933 (impedance); AD9834c (DDS); AD9835 (DDS).
     -- 'clock generator' Si5351  -  a rather interesting, tiny device with 3 high frequency outputs and an I2C interface.
     -- analog PLL - own designs.
    1- Spectral performance of AD9850 sine wave.
    Attached is a screenshot of the close-in spectrum output of the AD9850 as measured on a high-end-hobbyist SDR (software defined radio).   Although the sinusoid AD9850 on a scope can look nice, a spectrum analyser can show us a bit more.       Some notes....
    a)  The SDR is tuned to 7,000,000 Hertz with resolution bandwidth at 0.5 Hz, so two spectral lines are 1.0 Hertz. (yes, RBW = 0.5 Hz !)
         The DDS output has been trimmed (see 2a, below) and is seen to be about 1 Hz lower.
         The SDR frequency readout had been previously trimmed against a time-and-frequency standard long wave transmitter.
    B        The fundamental DDS output at 7.0 MHz is at -60 dBm.  Vertical divisoins are 10dBm.
    c)  Spurs (spurious) frequencies are seen at +- 100 Hz consistently around 7.0 MHz.  These are -90 dBm, only 30dB down from the fundamental - rather strong, but can be typical for such a DDS setup.  The other two spurs come and go at other DDS fundamentals.  
     (DDS spurs are complex, BUT - Analog Devices has a nice spur calculator with graphics of the step-waveform and the resulting spectrum)
    2- MSP430/432 code size reduction.    Integer arithmetic.
    Using integer arithmetic to generate the AD9850 frequency word. I also started with floating point.  For the 2553, the flash saved is important.
        This line of code worked on both the 2553 and 432 in CCS:    (not tested for overflows across all input to this function call).
    void sendFrequency(unsigned long frequency) { int b; P4OUT &= ~DATA; // use DATA line to time the following calculation P4OUT |= DATA; unsigned long freq_32val = ((frequency * 4294967296) / 125001340) ; // nominal 125000000 xtal P4OUT &= ~DATA; Some things to note:
    a) - the DDS clock divisor is 125,001,340 MHz instead of the nominal 125MHz.  This was determined empirically and is important for accuracy.
         This offset from nominal will be measured periodically with respect to temperature and stored in a 2553 Flash Info Segment.  SW trim.
    B   - code size : On a 2553 in CCS6.1, this calculation, setups and a few blinking LEDs was around 2.2 K bytes
      c) - execution time : the same setup as in   B   , with the 2553 set to the calibrated 1 MHz clock.                    The DATA line was raised during the routine's execution ...   Time =  about 13 mSec, I recall.  
    3- Environment
    - coded for MSP430G2553 LP (Energia17 and CCS6.1)      and MSP432 LP (CCS6.1)
    - SDR receiver and spectrum analysis on 'Perseus SDR'
    - signal coupling from the AD9850 to the SDR was through the air - about 50 cm distance.
        The SDR was connected to a short outdoor antenna, so the (quiet) background level of about -110dBm is local airwaves.
    None of this is particularly new, but I hope someone will find this writeup of use.
    This is intended for learning, possibly make a small, battery powered signal generator for my workbench.  As such, next steps are:
    - test other devices (esp Si5351)         - LCD freq display       - UART interface       - rotary encoder freq knob        - attenuator           - etc
           ..............    all driven by the MSP430/2

  14. Like
    gsutton reacted to Fmilburn in FFT   
    I was inspired a while back by the simplicity of the FFT application written by Shane Ormond and featured on the 43oh blog.  It was easy to duplicate and I've made a few changes, additions, and such that seemed worth documenting.
    I didn't have a signal generator other than the 1kHz square wave on my oscilloscope and some clunky code that I wrote for a microcontroller so I ordered an inexpensive AD9850 and hooked it up to a FR6989 LP so I could use the LCD to display frequency.  I've been pleased with the AD9850 and it is hard to beat it for the price.  The sine wave is more than sufficient for my needs up to 40 MHz - I don't see any deviation from the scope.  The code is here.  This is a picture of the setup being tested on the oscilloscope and nailing it:

    I need to make a little boosterpack for this so it is a little handier to use.
    I made several modifications to Shane's code:
    Number of samples can be specified Bin readings are matched with corresponding frequency interval Frequency resolution of bins can be set Frequencies of up to 5 kHz or more can be measured I used a MSP-EXP432 for the most part but the code was also tested and works on the TM4C123.  You really need an ARM to get this granularity.  The code is here.
    To increase the sample size and allow measurement up to higher frequencies I used Energia's delayMicroseconds instead of millis.  The right way to do this would be with timers and I hope to come back and address this at some point.  To calibrate the bins to their actual frequencies I used a simple one step approach with a single pass that measures the deviation in the sampling time from expected to actual.  Deviations occur due to the lag associated with Energia code and the actual time it takes to sample.
    Precision depends on the bin size and number of samples as well as inaccuracies in using delayMicroseconds.   I posted the serial output into a spreadsheet to get some plots...

    1000 Hz Square Wave

    1000 Hz Sine Wave

    5000 Hz Sine Wave
    My original goal was to create something that could process sound in the range of human hearing and this pretty much gets there.  I need to clear my desk for another project but hopefully I get back to it some day or perhaps someone else will find it interesting and report back
    This is my list of potential improvements:
    use timer for sampling times add a microphone improve the graphical display / GUI It would be neat to get this working on an Educational BoosterPack.
  15. Like
    gsutton reacted to Rei Vilo in [Energia Library] Very Basic Software Serial TX Only Library   
    Thank you for your comments and the correct value -1 for read() and peek().
    The initialiser list trick doesn't seem to reduce memory size.
    I've updated the library accordingly. See new release 1.07 on the initial post.
    Next goal is a software I2C library...
  16. Like
    gsutton reacted to bluehash in Original Educational BoosterPack   
    Darn. Sorry about that.
    I did  a little more digging and found out that Rev1 of the the educational boosterPack did not come with any code. @@Rei Vilo described the same issue on his blog page. He's published a few examples for you to try.
  17. Like
    gsutton reacted to bluehash in Original Educational BoosterPack   
    You can find it on CircuitCo's github. Seems like there are two revisions.
    https://github.com/CircuitCo/Educational-BoosterPack-RevA1 https://github.com/CircuitCo/Educational-BoosterPack-RevA2 Attached zip files... just in case the github page goes away.
  18. Like
    gsutton reacted to monsonite in Forth on the MSP430   
    Over the last  couple of days  Matthias Koch  has ported his Mecrisp MSP430 Forth 2.03 across to my MSP430FR2433 ChipStick design.
    I am now happy to report that the first testing happened earlier this evening - so now we have a good native assembly language Forth running on the ChipStick.
    There will be an update to my GitHub - in the next couple of days.

  19. Like
    gsutton reacted to monsonite in Forth on the MSP430   
    I have been intrigued with Forth since I was at school in the early 80s.
    There has been a renewed interest in Forth as a lightweight language with lightweight development tools - especially in these days of open source , where there is a backlash against the huge IDE tool chains needed to develop and debug code - even on the smallest of microcontrollers.
    As part of my recent investigation of MSP430 I have found a number of free, open source Forth implementations - which may be worth a look.
    1. Fast Forth by Jean Michel Thoorens   https://gitlab.com/Jean-Michel/FastForthForMSP430fr5xxx
    This is coded in MSP430 assembly language, is aimed at the newer MSP430 devices with FRAM and has the unique ability to mix Forth and asm in the source code.
    As a result of clever coding in asm - it really is fast, and has some nice features.
    It comes with an integral symbolic assembler, and support for accessing a SD card.
    It needs a minimum of 8K to 11K of FRAM - depending on the build options selected.
    It communicates with the PC using TeraTerm (or similar) at an astounding 921600 baud. It can load and compile Forth source code faster with a $2 USB- serial adaptor, faster than a FET can load a hex file.
    2.  Mecrisp - By Matthias Koch  http://mecrisp.sourceforge.net/
    Another Forth written in native MSP assembly language.  (ARM Cortex version also available).  Out of the box versions available for the following G and FR processors - plus a special for the MSP430F1612 on the G2 Launchpad
    MSP430F2274 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430G2553 (9600 Baud, 8 MHz, TX on P1.2, RX on P1.1) MSP430G2955 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430G2855 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430G2755 (9600 Baud, 8 MHz, TX on P3.4, RX on P3.5) MSP430F5529 (115200 Baud, 8 MHz, TX on P4.4, RX on P4.5) MSP430FR4133 (115200 Baud, 8 MHz, TX on P1.0, RX on P1.1) MSP430FR5969 (115200 Baud, 8 MHz, TX on P2.0, RX on P2.1) MSP430FR6989 (115200 Baud, 8 MHz, TX on P3.4, RX on P3.5) Special Mecrisp for MSP430F1612 with initialisations for Launchpad hardware is included to conquer your Launchpad completely.  
    Matthias is working on a version for the new ChipStick MSP430FR2433 device - see news in post below.
    3.  4E4th by Dirk Bruehl & Michael Kalus   http://www.4e4th.com/
    An educational package aimed at high-school/university students or makers/hobbyists. Runs on G2 LaunchPad.
    Comes with a simple GUI to allow saving and loading of source code.  Versions for FRAM based MSP430 devices available on request.
    Dirk Bruehl describes the package in his 2012 EuroForth conference paper
    4. Camel Forth by Brad Rodriguez      http://www.camelforth.com/download.php?view.32
    Brad has written extensively about the mechanics of writing Forth interpreters over the years, and was probably one of the first to port Forth to the MSP430.   It uses Mike Kohn's "Naken" lightweight cross assembler.
    There are other MSP430 Forth implementations available AmForth,  eForth and MPE VFX Forth - with a cross platform GUI for Win, Linux  and  Mac OS X
  20. Like
    gsutton reacted to bluehash in noForth for MSP430   
    In addition to @@monsonite's Forth research, I found noForth. Mentioning it separately here as it is a MSP430 project.
  21. Like
    gsutton reacted to monsonite in noForth for MSP430   
    noForth appears to be a very nice implementation - written by Dutch developers,  Albert Nijhof & Willem Ouwerkerk
      It is a good implementation for the MSP430 - especially if you are working with G2 Launchpad , '5739 EXP or '5969 EXP.
    noForth also supports the following boards  with noForth C or noForth V - which has support for the FRAM
    Documentation about the boards (.pdf) 
    Lp, Mc, Du, Mv, Ex   intel hex files (.a43) of actual 
    noForth versions (160401) MSP430G2553 Launchpad 
    16kB FROM Lp noForth C   noForth V 
    noForth C-   noForth V- MSP430G2553 Egel Kit 
    16kB FROM, Baud rate 38k4 Ek noForth C   noForth V 
    noForth C-   noForth V- MSP430F149 Minim Core Board 
    61kB FROM Mc noforth C   noforth V MSP430F149 Dupont board 
    61kB FROM Du noForth C   noForth V MSP430F149 Mini-V3 board 
    61kB FROM Mv noForth C   noForth V MSP-EXP430FR5739 Experimenter Board 
    16kB FRAM Ex noForth C   noForth V MSP-EXP430FR5969 Experimenter Board 
    64kB FRAM, Baud rate 38k4 Ex noForth C   noForth V
    See this page for links to the above  
    For Linux users - the writers of noForth have produced the  e4thcom "Forth Terminal"  - which is an integrated solution to communications and file save/load for writing Forth source code. 
    There is definitely increasing interest in Forth for small embedded microcontrollers - especially the MSP430.   Most of the implementations are free to download -  and there is a good community around the German Forth group 
    If you don't speak German - then much of the group's content is in English  - or you can very easily use Google Translate on their web pages, wiki etc.
  22. Like
    gsutton reacted to simpleavr in Educational BoosterPack 8 bit FFT Spectrum Analyzer Attempt   
    Happy holidays! It turns out great.

    Button press cycles through sleep, 1 dot, 2 dots and 3 dots.
    Press and hold for cycles through the following 3 menu options
    Hamming windows choice; none, low, mid, high (via short presses)
    Dimmer choice; 0...3
    Sampling rate; 0...7 (0 is fastest)
    This is the smallest spectrum analyser I built.
    I managed to use 1 gpio for ADC, and left 15 pins for the 8x8 matrix (63 pixels used).
  23. Like
    gsutton reacted to sq7bti in Educational BoosterPack 8 bit FFT Spectrum Analyzer Attempt   
    Having a nice matrix led display laying around with no use of I assembled a test circuit with launchpad and modified the code of @simpleavr to run on it.

    The display is driven by four MAX7219 chips chained on SPI bus. I noticed that the only floating point operation that your code was using is a square root operation in line 257. Once I added a fixed-point square root routine, linking with math lib is not necessary anymore - spared a lot of flash space. The fixed-point routine is also 3 times faster than mathlib floating point one: 50us vs 150us
    #ifdef FLOATING_POINT // sqrt: 150us #include <math.h> #else // FLOATING_POINT // 50us unsigned char sqrt16(unsigned short a) { unsigned short rem = 0, root = 0; int i; for(i = 0; i < 8; ++i) { root <<= 1; rem = ((rem << 2) + (a >> 14)); a <<= 2; ++root; if(root <= rem) { rem -= root; ++root; } else { --root; } } return (unsigned char)(root >> 1); } #endif // FLOATING_POINT Further I've added Hamm windowing to minimize spectral leakage:
    // scilab 255 * window('kr',64,6) //const unsigned short hamming[32] = { 4, 6, 9, 13, 17, 23, 29, 35, 43, 51, 60, 70, 80, 91, 102, 114, 126, 138, 151, 163, 175, 187, 198, 208, 218, 227, 234, 241, 247, 251, 253, 255 }; // scilab 255 * window('kr',64,4) const unsigned short hamming[32] = { 23, 29, 35, 42, 50, 58, 66, 75, 84, 94, 104, 113, 124, 134, 144, 154, 164, 174, 183, 192, 201, 210, 217, 224, 231, 237, 242, 246, 250, 252, 254, 255 }; // scilab 255 * window('kr',64,2) //const unsigned short hamming[32] = { 112, 119, 126, 133, 140, 147, 154, 161, 167, 174, 180, 186, 192, 198, 204, 209, 214, 219, 224, 228, 232, 236, 239, 242, 245, 247, 250, 251, 253, 254, 255, 255 }; Applying windowing on 32 samples uses fixed point math:
    for (i=0;i<Nx;i++) { int hamm = hamming[i<(FFT_SIZE-1)?i:(Nx-1)-i] * data[i]; data[i] = (hamm >> 8); } Finally the display buffer is filled in with output of FFT function:
            unsigned long mask = 1UL;         for (i=0; i<32; ++i, mask <<= 1) {             for(j=0;j<8;++j) {                 if(j<plot[i])                     dbuff.ulongs[j] |= mask;                 else                     dbuff.ulongs[j] &= ~(mask);             }         } where dbuff is display buffer organized as:
    typedef union { unsigned long longs; unsigned int ints[2]; unsigned char chars[4]; } longbytes; union { unsigned char bytes[8*4]; longbytes lbytes[8]; unsigned long ulongs[8]; } dbuff; which make it easy to manipulate:
    unsigned char spibuff[8]; void SPI_Write(unsigned char* array) { P2OUT &= ~LED_CS; __delay_cycles(50); unsigned int h = 8; while(h) { UCB0TXBUF = *array; while (UCB0STAT & UCBUSY); ++array; --h; } P2OUT |= LED_CS; } void update_display() { unsigned char i; for(i = 0; i < 8; ++i) { spibuff[0] = spibuff[2] = spibuff[4] = spibuff[6] = i+1; spibuff[1] = dbuff.lbytes[i].chars[3]; spibuff[3] = dbuff.lbytes[i].chars[2]; spibuff[5] = dbuff.lbytes[i].chars[1]; spibuff[7] = dbuff.lbytes[i].chars[0]; SPI_Write(spibuff); } } BTW I got a second 8x32 led matrix displays from the same ebay offer, and it turned out to be mirrored - LED matrix is turned around 180deg, so the update_display() routine for the other one have to push bytes in order 0 through 3, and bit-shift operations ( << and >> ) yield opposite display reaction (left vs right scroll).
    Edit: correct photo attachement and source code snippets
  24. Like
    gsutton reacted to simpleavr in Educational BoosterPack 8 bit FFT Spectrum Analyzer Attempt   
    I had summarized this thread and created a write-up on my site that contains everything and is a bit more descriptive for whoever is interested.

  25. Like
    gsutton reacted to simpleavr in Educational BoosterPack 8 bit FFT Spectrum Analyzer Attempt   
    Thanks for your comment. It would look great on one of your proto plates. You may want to put one together, it only requires a few common components.
    I just added buzzer support (don't understand why I had missed that). Now the P1.3 button will cycle thru (1) no output, (2) P1.6 green LED output, (3) P2.6 buzzer output. The buzzer output you will see the bars not showing up at what it should be. I would suspect it being the frequency response / limit of both the buzzer and the condenser microphone.
    You may want to do another pull if you are building. Also we need the -lm flag to link the math library.
    Code is not optimized. They are places that could use some in-line assembler to speed things up if anyone is interested.
  • Create New...