Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Lyon

  1. Hi,

    A few words about your problem:

    1) since you need a sd-card example, maybe the best way is to download the Tiva package from TI - there is an example which run on CCS (and i suggest to move to CCS, since the Energia does not have a debugger, AFAIK). The sd-card configuration starts by sending some data at the rate of 400KHz, in SPI mode 0, toggling CS on every byte. Then after that, when the communication is established, the frequency is changed to 12MHz.

    2) since you  made some test on another device type (and function) - many devices uses mode 0 and mode 3 or mode 1 and mode 3, so you can check also the SPI MODE 3, which is recognised to keep CS low until you finish sending a burst of data. Keep in mind you need to read each data after sending one - this is SPI nature, there are two synchronous shifting register under the same clock, connected  as a ring, so two data are moved at once.

  2. Hello,


    I am writing a program to use LoRa RN2483 with MSP430G2553 sending to LoRa the readings from some sensors. First I had a temperature sensor DS18B20 (digital reading), the internal temperature from MSP, the internal supply voltage from MSP and the code worked great, the readings we're good and were succesfully sent to LoRa using UART.


    Now I am trying to add a humidity sensor on P1.4 and a photoresistor on P1.5 ( using a 10k resistor like this: Vcc --- photoresistor -- P1.5 --- 10k resistor --- GND). These sensors are analogue so that I need 2 ADC to read them. I made something like this:

    void humInit(void)
    	ADC10CTL1 = INCH_4 + ADC10DIV_3 ;         // Channel 4, ADC10CLK/3
    	ADC10CTL0 = SREF_0 + ADC10SHT_3 + ADC10ON + ADC10IE;  // Vcc & Vss as reference, Sample and hold for 64 Clock cycles, ADC on, ADC interrupt enable
    	ADC10AE0 |= BIT4;                         // ADC input enable P1.4
    int humOut(void)
    	float value;
    	__delay_cycles(1000);				// Wait for ADC Ref to settle
    	ADC10CTL0 |= ENC + ADC10SC;			// Sampling and conversion start
    	while (ADC10CTL1 & BUSY);             //waiting for conversion to finish
    	value = ADC10MEM;				// Assigns the value held in ADC10MEM t
    	ADC10CTL0&=~ENC;                     //disable adc conv
        return (unsigned int)(100-(value/1023 * 100));

    and in the Main() function I have something like this:

      hum = humOut();

    where hum is a global variable.


    The transmission part is something like this:

    #if defined(__TI_COMPILER_VERSION__) || defined(__IAR_SYSTEMS_ICC__)
    #pragma vector=USCIAB0TX_VECTOR
    __interrupt void USCI0TX_ISR(void)
    #elif defined(__GNUC__)
    void __attribute__ ((interrupt(USCIAB0TX_VECTOR))) USCI0TX_ISR (void)
    #error Compiler not supported!
    	if (f == '1')
    			UCA0TXBUF = string1[i++];       // TX next character
    			 if (i == sizeof string1 - 1)              // TX over?
    				 P1OUT|= BIT6;
    			    f = '2'; i = 0;
    		if (f == '2')
    			UCA0TXBUF = string2[i++];
    			if (i == sizeof string2 - 1)
    				P1OUT|= BIT6;
    			    f = '3'; i = 0;

    where f is a flag to know which string to send.


    The transmission stars in Main() like:

      i = 0;
      f = '1';
      IE2 |= UCA0TXIE;   // Enable USCI_A0 TX interrupt
      UCA0TXBUF = string1[i++];

    The problem is that after I'm adding the ADC for the humidity and read it (the reading is correct) the transmission stops after the first character of the first string. I tried to put a breakpoint in the TX interrupt and it doesn't seem to reach it. 


    It seems that the ADC is somehow affecting the TX interrupt.


    Any ideas on this ?


    Thank you


    After (f=='2'), f is changed to '3' where there is not any option to process for that. Shouldn't be f=1 again to toggle between the two options?


  3. Hi,

    Please see this link: http://www.elecfreaks.com/wiki/index.php?title=Bluetooth_Bee#Programming

    It is stated that your device is/ has AT compatible protocol, so your commands should be prefixed by AT. The link has a test program written in Energia, you may try that.

    As for your code, while you claim starting with qs-rgb, your file is uart-stdio, which may be unsuitable for your purpose. Depending on ypur real application, you must make new software functions to include these AT commands.


  4. Hi,

    But the driverlib functions are consistent with the user manual! In general, it is useful to use these instead direct register addressing, for fast programming. This will ease your work. Some other people may comment that this is time consuming. If it is your case, at least look at them and use the function content, without wrapping (some time is really spent in those functions - the ASSERT takes some time, but once the program is debugged, these can be removed). Sometime it is really more convenient to use direct registers - but after you have more experience with this micro.

    In your case: to get your result, use the code generated by Pinmux utility. take care and look/use at all #include declarations in those files. Add the following global symbols to avoid any compilation/linking errors:


    gcc if you use GCC/Energia, ccs="ccs" (CCS), ewarm (IAR), rmvdk (Keil).
    MAP_ prefix can be removed and in this case pure driverlib functions will be used or if you keep it, then functions available in ROM will be used if available, otherwise from driverlib.
    Try and tell the result (and the tools used if still with problems)
  5. Hi,

    In this case, I suggest to download/install/run the application Pinmux from TI - select then your micro type, configure the pins as you need and the application will generate the initialization code for you. Then compare with your code. Take care will be different, since the Pinmux uses driverlib - you may replace your code or you may inspect the functions used there to see the registers used to initialize the pins.


  6. Hi,

    For the moment you can trust the samples. Try to test/check other pins also, try an UART or SPI.

    Since it is your board, check/ double check your board for shorts with other pins/traces - sometimes it may happen to have small, near invisible shorts...

    Worth to try also a second board if you have.


  7. Hi,

    First of all, your JTAG pins must have a pull-up resistors mounted on-board.

    Second, if you use your Lauchpad board as debug-out ( to debug another board) then you must disable your LP target micro ( the test/target micro from LP board, the debug one should be active). You can do that by short-circuit of reset capacitor on LP board.


  8. Hi,

    For your temperature sensor you may search this forum or TI's Tiva forum, it is possible to find out some posting related to this. The alternative is to use TI's I2C libray and of coarse to dig into the data sheet of your sensor. I know it is bulky, but that is for all specialized sensors. And the interface it is not a simple one, but can be used.


  9. Hi,

    At the motobike battery voltage, the ADC offset mostly does not matter, or is within a good accuracy. It can be measured and used into a formula to get better results, but at the expense of some external components. More, you must scale down the voltage to be within the ADC range, (the maximum scaled battery voltage should be less than maximum ADC range) and the scaling is better to be done with resistors and an op-amp, since the ADC input impedance is not so high.

    TI has all sort of components to make measurements, including temperature sensors. Choose whatever is convenient to you. I prefer ones giving scaled results (degC/mV inmy case) since I only measure the voltage without too much calculations.


  10. Hi,

    We need more info from you - what is your battery voltage (i.e. CR2032, or car battery, or other? We have in production line battery systems even for 110V dc ) and also what kind of themperature do you need to measure - ambient one, battery temperature, chip temperature (there is a temperature sensor on-chip). And what is your temperature sensor?


  11. Hi,

    For TM4C129x micros, the function SysCtlClockFreqSet() returns the running frequency if the setting was OK or 0 if the result is not OK, so you may have the possibility to save the value and check it in a separate statement. SysCtlClockGet() function should be used only with Tiva123 series, but note there is a small bug inside.

    Another possibility is the 129 series allow a special pin to be configured as to get out the clock, so you can check it or use it for other purposes. Take care, for testing should be OK, but for production/qualification could be wrong, since this may induce EMC related problems.


  12. Hi,

    Nothing is wrong, all is perfect as it should be. This is the usual behaviour of Cortex-Mx micros, where the interrupt routines (all, including reset_isr) gets an odd address when placed into interrupt vector routines, for signalling the fact the micro should use thumb(2) instructions, and not original ARM.

    It would be an error to get even address in interrupt vector, and that would lead to interrupt fault.


  13. Hi,

    Well, mostly No!

    When counting up in one-shot or periodic modes, the prescaler acts as a timer extension and holds the most-significant bits of the count. In input edge count, input edge time and PWM mode, the prescaler always acts as a timer extension, regardless of the count direction. (From user manual)

    Since the counting is up and both edges are selected, then the pulse duration is measured - seems this was the goal, reading the code snippet.

    But: you may verify this with an oscilloscope to confirm the results.

    Also: since both edges are enabled for capture, then to have always consistent results, you need to know which edge comes first -either the positive one, either the negative one. Assume the pulse is not 50%of duration.


  • Create New...