Jump to content
43oh

Sir Ferdek

Members
  • Content Count

    17
  • Joined

  • Last visited

Everything posted by Sir Ferdek

  1. //****************************************** //Description: Random number generation using MSP's internal clocks //based on TI's slaa338 //****************************************** //ACLK - set to LFXT1 = VLO BCSCTL3 |= LFXT1S_2; //clear OSCFault flag //wait for clock fault system to react do{ IFG1 &= ~OFIFG; // Clear OSCFault flag } while(BCSCTL3 & LFXT1OF); //DCO default @1MHz, //MCLK - default DCO/1 //SMCLK - default DCO/1 //prepare timer TACCTL0 |= CM_1 + CCIS_1 + CAP; TACTL |= TASSEL_2 + MC_2; //workaround for DCO freeze problem void setRSELx(unsigned char target){ unsigned
  2. OK, no matter what, tommorow you'll have your piece of code
  3. You can install Windows on virtual machine and give him exclusive access to the usb port where one of your launchpad is connected. That's how I sniffed usb communication when I've needed linux tools but device worked only under windows . Inception...
  4. Yes, of course. I just need to find some time to refactor and comment it (you know, exam session is coming ). What's more, there are some drawbacks which should be mentioned before implementing. First of all, it modifies DCO (modulation, RSELx) to add some randomness. Secondly, generating one number, then returning to original frequency, then generating number again makes runstest() think they are less random (no idea why, but it made HUGE difference).The solution to that problem was to batch generate whole table of random numbers and read them one after another when needed. Unfortunately
  5. http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=slaa338&docCategoryId=1&familyId=914 [tipdf]slaa338[/tipdf] I have it rewritten in plain C, so let me know if you want it. This method of generating random numbers satisfy requirements for noncritical systems. I have done some accurate tests on 1M samples of bits and compared it to other methods as my project for course assesment and results are quite satisfactory: - 50.19% of zeroes, 49.81% of ones - FFT is smooth and even without serious frequency peaks - runstest() in MA
  6. Just after reading your post I've realized I was reading it some time ago, but it seemed to me I won't be using any other frequency settings than precalibrated... Yeah, right. Thank you.
  7. Snippet: //... //DCO 1MHz if(CALDCO_1MHZ == 0xFF || CALBC1_1MHZ == 0xFF){ P1OUT |= BIT0; while(true); } else { BCSCTL1 = CALBC1_1MHZ; DCOCTL = CALDCO_1MHZ; } //... BCSCTL1 = 0x8F; Can anyone reasonably explain to me why setting all bits of RSELx stops DCO in this configuration? I've found this when implementing random number generator based on drift of VLO and DCO clocks. It took me 3 hours to finally figure out that it was crashing my almost finished app . Thx in advance.
  8. *(fontset * (c - 0x20) + i); it's a variable under addres (fontset * (c - 0x20) + i), written in this form, there is a multiplication inside EDIT: Ahh, now I get it
  9. ROFL! I've just remembered -> " was the name of the problem on my PC. :wave:
  10. Argh, mother of Europe, can't get it here even if I build miracles of technology out of this :/
  11. How about running mspdebug with root privileges? :roll: I'm on Linux Mint Debian Edition and had to add udev rule TWICE, dunno why but first time it just didn't work, probably some kind of typo.
  12. Correct me if I'm wrong, but... I can't find debouncer on 1.3 xD And pushing the switch creates a few interrupts, not just one.
  13. I'm not sure, but shouldn't you enable ADC first in order to activate the ADC12CLK? It's just a hunch, but msp430 has many energy-saving features that may affect that. Try setting ADC12CTL to some correct values, especially the ADC12ON bit then report again, please
  14. ROFL. I'm not the admin, but I'm pretty sure it's ISP's fault... (according to tracert) :roll: The question is: which one? 43oh hosting or zubiaur's. Interesting...
  15. If you want to connect ADC12OSC to oscilloscope you need to: 1) set ADC12CLK to use ADC12OSC (this is default, so no need to do that) 2) using P2SELx and P2SEL2x change function of P2.7 to give you the output of ADC12CLK For instance, when using launchpad, I would have to: P1DIR |= BIT3; P1SEL |= BIT3; P1SEL2 &= ~BIT3; Be warned: "The ADC10OSC, generated internally, is in the 5-MHz range, but varies with individual devices, supply voltage, and temperature. See the device-specific data sheet for the ADC10OSC specification."
  16. In your case (single channel single-conversion mode) the answer is: no, not automaticaly. You start ADC by setting ADC12SC bit, which is automagicaly cleared after the conversion. And you set it in the while(1) loop, after waking up from LPM0 Try this: if (CALBC1_16MHZ ==0xFF || CALDCO_16MHZ == 0xFF) while(1); // If calibration data is erased // trap CPU BCSCTL1 = CALBC1_16MHZ; // Set range DCOCTL = CALDCO_16MHZ; // Set DCO step + modulation
  17. Hello. First of all, set GIE bit only once, before the 'while(1)' loop: __bis_SR_register(GIE); while (1) { ADC12CTL0 |= ADC12SC; // Start sampling/conversion __bis_SR_register(LPM0_bits); // LPM0, ADC12_ISR will force exit } Next, rewrite your interrupt procedure and learn some GNU C tricks (dunno if it works with IAR/CCS, but if they call them C compilers, it should :think: ). Honestly, this is the part of your code that makes sampling so freaking slow. You're simply killing CPU with unneeded calculations and memory operations. Try this (not tested ): #pragma vector = ADC12_V
×
×
  • Create New...