Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Reputation Activity

  1. Like
    pabigot reacted to gordon in TI MSP430 and open source   
    A huge thanks for taking up this issue.
     
    The MSPGCC toolchain works really well, and Peter is doing a really wonderful job on it. I do not know how much is TI involved in the development; Peter hinted somewhere (don't remember if it was on IRC or one of the MSPGCC lists or maybe somewhere else) that someone is funding the development, but it is unclear if it's TI or if they are involved at all (never asked, though).
     
    It would certainly make a warm fuzzy feeling if they'd get involved, should Peter think to need some assistance of any form. I know that MSPGCC has and distributes TI's headers (they are licensed standard 3-clause BSD), which is a nice touch.
     
    Toolchain-wise, the other side of the coin is MSPDebug. I don't know of any other actively-developed thing that bridges the gap between compiling an application and actually talking to the device, so, without this, there's really no life . I am also reasonably sure Daniel develops MSPDebug on his own, without any TI involvement or anything.
     
    There's then the open source release of MSP430.dll v3, which is a very nice thing, except so far it looks more like a code dump rather than open development. Granted, it is pretty fresh meat as of now, so it could turn out to be anything, but for now my limited understanding is people don't yet know what to make of it on the long run (don't think there's any documentation except for some reference, no real vision of how its future will look like, non-Windows build things are separate, off the top of my head ). But, as said, it's a start.
     
    Libraries- and such things-wise, I don't know but I'm hazarding a guess that they are at best free beer, though some are definitely worse: both the Eagle library and the code examples come without any sort of license at all (which means full copyright and only full copyright, no additional rights granted whatsoever). Technically speaking, this makes the distribution of any such nice improvements borderline illegal. This is not only sad, but also counterintuitive and -productive, since TI's version is generally rather unusable (for their use of a non-standard grid setting, head to head against all CadSoft/Eagle recommendations and best practices).
     
    I am not (yet?) using any TI-provided libraries (so no opinion here), but for, say, the examples (SLAC017, but possibly all app note code), a friendly license would be more than useful in, say, porting them to MSPGCC and also distributing these ports.
     
    The fact that TI doesn't currently pursue such violations is their goodwill, but they are not legally bound not to (as would be the case with a suitable license).
     
    This is (my best current understanding of) how things are at the moment. It's not bad, we've seen worse, they also apparently mean good, but it's still a long road ahead.
     
    Ed.: I just read your blog entry wrt. Microchip vs. open source, allow me to quote a bit for the context:
     
  2. Like
    pabigot got a reaction from bluehash in Timer initialization and external oscillator problem   
    You may be selecting the source before it stabilizes, causing it to fall back to an alternative source. Make sure XT2OFFG is clear in UCSCTL7. The TI example program msp430x54x_UCS_8 from the 5418 example programs shows how to configure for XT2 and includes the loop below; there's probably an equivalent one for your chip in the code examples available at http://www.ti.com/product/msp430f5510#toolssoftware.
     

    // Loop until XT1,XT2 & DCO stabilizes do { UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG); // Clear XT2,XT1,DCO fault flags SFRIFG1 &= ~OFIFG; // Clear fault flags }while (SFRIFG1&OFIFG); // Test oscillator fault flag UCSCTL6 &= ~XT2DRIVE0; // Decrease XT2 Drive according to expected frequency UCSCTL4 |= SELS_5 + SELM_5; // SMCLK=MCLK=XT2
  3. Like
    pabigot got a reaction from bluehash in Help with Reset Process/Instruction   
    The traditional approach is something like:

    WDTCTL = 0;
    which uses the absence of the watchdog password to result in a power-up clear that includes a jump to the reset vector. On machines that support it (5xx/6xx with the power management module) it is significantly better to do:

    PMMCTL0 |= PMMSWPOR;
    which executes a power-on reset.
     
    See the System Reset and Initialization section in the first chapter of the family users guide for your chip for details on how these differ and what pending interrupts and configuration might still need to be cleared.
     
    Peter
  4. Like
    pabigot got a reaction from Morgan Meader in Timer initialization and external oscillator problem   
    You may be selecting the source before it stabilizes, causing it to fall back to an alternative source. Make sure XT2OFFG is clear in UCSCTL7. The TI example program msp430x54x_UCS_8 from the 5418 example programs shows how to configure for XT2 and includes the loop below; there's probably an equivalent one for your chip in the code examples available at http://www.ti.com/product/msp430f5510#toolssoftware.
     

    // Loop until XT1,XT2 & DCO stabilizes do { UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG); // Clear XT2,XT1,DCO fault flags SFRIFG1 &= ~OFIFG; // Clear fault flags }while (SFRIFG1&OFIFG); // Test oscillator fault flag UCSCTL6 &= ~XT2DRIVE0; // Decrease XT2 Drive according to expected frequency UCSCTL4 |= SELS_5 + SELM_5; // SMCLK=MCLK=XT2
  5. Like
    pabigot got a reaction from timotet in Timer initialization and external oscillator problem   
    You may be selecting the source before it stabilizes, causing it to fall back to an alternative source. Make sure XT2OFFG is clear in UCSCTL7. The TI example program msp430x54x_UCS_8 from the 5418 example programs shows how to configure for XT2 and includes the loop below; there's probably an equivalent one for your chip in the code examples available at http://www.ti.com/product/msp430f5510#toolssoftware.
     

    // Loop until XT1,XT2 & DCO stabilizes do { UCSCTL7 &= ~(XT2OFFG + XT1LFOFFG + XT1HFOFFG + DCOFFG); // Clear XT2,XT1,DCO fault flags SFRIFG1 &= ~OFIFG; // Clear fault flags }while (SFRIFG1&OFIFG); // Test oscillator fault flag UCSCTL6 &= ~XT2DRIVE0; // Decrease XT2 Drive according to expected frequency UCSCTL4 |= SELS_5 + SELM_5; // SMCLK=MCLK=XT2
  6. Like
    pabigot got a reaction from stepman in Hello   
    A lot of fairly cheap multimeters include frequency measurement up to 30MHz: I'm no expert but am pretty happy with the Aldetek VC97, which is about $30. Certainly up to about 4MHz it's done well for me, though the modulation scheme used by the MSP430 to simulate specific frequencies by interleaving two "fundamental" frequencies can confuse them.
  7. Like
    pabigot got a reaction from bluehash in Hello   
    A lot of fairly cheap multimeters include frequency measurement up to 30MHz: I'm no expert but am pretty happy with the Aldetek VC97, which is about $30. Certainly up to about 4MHz it's done well for me, though the modulation scheme used by the MSP430 to simulate specific frequencies by interleaving two "fundamental" frequencies can confuse them.
×
×
  • Create New...