Jump to content

russm

Members
  • Content Count

    4
  • Joined

  • Last visited

Everything posted by russm

  1. Again, those are for calibrating the DCO against a 32kHz crystal if your exact timing is important. slau144
  2. It looks like that is designed to give you a nicely calibrated clock against the 32KHz crystal, but I just want "AS FAST AS POSSIBLE THANKS"... I've gone back and counted up the per-instruction cycles for the compiled source, and it's 22 clocks per loop, so that fits with what I was seeing. Oh well. I may be able to hand-code an inner loop that's fast enough by dumping a bunch of the compiler's "useful" extras (no, I don't actually care if carry was set). Not confident I can fit enough of the required smarts in the cycles that are available though. (on preview) Hmmm, OK, I'll have to check that out. My timings were assuming the clock was running ~16MHz, but if I can push it that high (even if it's flaky) I might be in business. Cheers!
  3. I'm toying with using an msp430 as an in-line protocol converter between a couple of busses, and am trying to confirm if it's even viable. As a simple test, I'm using the code below to pass signals from inputs (P1.6, P1.7) to outputs (P1.4, P1.5) and it seems capable of relaying signal features down to a size of ~2.5us. Unfortunately, that's not fast enough for what I want - I need to handle features down to 0.5us or so. Assuming I'm running MCLK at 16MHz, this means I'm needing ~40 clocks just to copy an input GPIO to an output GPIO with some trivial bit manipulation - I'm not sure if this is expected, or if I'm just not clocking the device correctly. Given what I'm doing in the loop I'd expect only ~10 clocks or so. From my reading of the SLAU144 Basic Clock Module chapter I think I'm running it as fast as I can, but aren't really sure how to confirm that. I believe I'm setting RSELx and DCOx to their maximum values, and MCLK to DCO with a divider of 1, but is this the right way to force the fastest MCLK possible? #include #include void main(void) { WDTCTL = WDTPW + WDTHOLD; // stop watchdog BCSCTL1 = RSEL0|RSEL1|RSEL2|RSEL3; // RSELx = 0xF = AS FAST AS POSSIBLE DCOCTL = DCO0|DCO1|DCO2; // DCOx = 0x7 = AS FAST AS POSSIBLE BCSCTL2 |= SELM_0 + DIVM_0; // MCLK = DCO, divider = 1 P1DIR |= 0x30; // P1.4 and P1.5 are output P1DIR &= ~0xC0; // P1.6 and P1.7 are input while(1) { register unsigned char a, b; a = P1OUT; // current output values a &= ~0x30; // zero P1.4, P1.5 b = P1IN; // current input values b &= 0xC0; // zero all but P1.6, P1.7 P1OUT = a | (b >> 2); } }
  4. Does anyone know if it's possible to make mspgcc (either 3 or 4) produce objects that follow the same EABI as CCS/IAR do? I'd like to use some existing assembly that has been written for IAR in a GCC project, but it looks like these compilers use different calling conventions. Porting the assembly is possible, but if possible I'd like to avoid that. While translating the source to msp430-as I noticed that IAR passes function arguments starting in r12 and counting up, where gcc is starting in r15 and counting down, and that's the point where I decided that I probably don't want to put too much more effort in before I know whether I need to do a full port or not.
×
×
  • Create New...