Jump to content
43oh

pabigot

Members
  • Content Count

    577
  • Joined

  • Last visited

  • Days Won

    30

Reputation Activity

  1. Like
    pabigot got a reaction from GeekDoc in Be aware : Launchpad can retain old code in memory   
    It's also not surprising. PxOUT is not cleared on reset; since you enabled the pin for output, the previous setting is left unchanged. This is documented in the 2xx family user's guide (Table 8-2 Digital I/O Registers) from slau144j. A sufficiently long power-down might cure the problem, but in general if you're going to change the configuration of a GPIO from its power-up state you should set all the relevant registers.
  2. Like
    pabigot got a reaction from veryalive in New BoosterPacks - CC3100 & CC3200   
    Or not.
     
    I think there's going to be too much functionality on this device that's locked down in the no-source-provided ROM interface to allow development of any real advanced applications.
     
    For example, the CC3000 is useless in low power solutions: I get maybe 1500 one-shot UDP transmissions with CC3000 shutdown and LPM3 between them before two AAs drain on a EXP430F5529LP+CC3000 demo. Somewhere TI claimed the CC3100 could run for a year on two AA batteries, which means they must have done a whole lot of enhancements. If you read the CC3100/CC3200 Wi-Fi Network Processor Subsystem guide swru368.pdf section 4.6.1, the details on exactly what behavior is promised when in low power mode are lacking: "Long Sleep Interval" is clearly related to the IEEE 802.11 FCS Power Management bit, but some of the effects they describe are "extra" features TI's apparently chosen to enforce unnecessarily; and "Low latency power" is completely uninformative as to its behavior.
     
    I think this is supporting evidence for @@jpnorair's observation that nobody's making money on IoT yet, and that this explains why everybody's trying to lock down everything in their solutions in hope that their magic beans are the ones that will hatch the goose that lays the golden egg (to abuse some metaphors). Personally, I think that's absolutely the wrong approach, but I have this non-entrepreneurial focus on providing long-term value rather than snatching at short-term profit.
     
    But yes, at this point it's pretty much all speculation. If the CC3200 LP is still available cheap in mid July when I might have a chance to play with one maybe I'll buy one. I probably won't invest in much CC3100 technology, since TI has not demonstrated an ability to make the CC3000 work. When I read the last couple paragraphs of this post carefully I conclude that the CC3000 is EOL, having served its purpose of getting external users to spend the necessary tens of thousands of hours required to beta-test everything. My last hope is the final firmware release 1.14 for the CC3000 will make the thing robust enough to deploy. That hope is pretty slim.
  3. Like
    pabigot got a reaction from tripwire in Be aware : Launchpad can retain old code in memory   
    Specific devices (MSP430G2553, MSP430FR5739) have datasheets. These provide pin mappings, power consumption, available peripherals. Families of devices (2xx, FR57xx) have user's guides. These provide descriptions of each peripheral, what registers are available, and the effect of manipulating those registers. You need to be familiar with both to develop non-trivial applications. Look for them here.
     
    Energia provides a familiar interface and lowers the barrier to entry for people familiar with Arduino. From everything I've heard it's a great solution; it's just not one that accommodates my control issues. For that, I developed BSP430.
  4. Like
    pabigot got a reaction from tripwire in Be aware : Launchpad can retain old code in memory   
    If Energia is to provide the same interface as the Arduino API it emulates, it may be appropriate that it provide an initial configuration when invoking the pinMode command. Or it may not; I have no idea what sort of behavioral promises are made by either Arduino's normal API or Energia.
     
    There could even be times when the value set before a reset is exactly what you want to inherit after a reset: that need is why there's the more general LOCKLPM5 feature on the chips that support LPM3.5 and LPM4.5 modes. Getting that level of control is why I prefer to interface directly with the hardware for things as trivial as this: then there's only one reference document I need to check.
  5. Like
    pabigot got a reaction from tripwire in Be aware : Launchpad can retain old code in memory   
    It's also not surprising. PxOUT is not cleared on reset; since you enabled the pin for output, the previous setting is left unchanged. This is documented in the 2xx family user's guide (Table 8-2 Digital I/O Registers) from slau144j. A sufficiently long power-down might cure the problem, but in general if you're going to change the configuration of a GPIO from its power-up state you should set all the relevant registers.
  6. Like
    pabigot got a reaction from KatiePier in Be aware : Launchpad can retain old code in memory   
    It's also not surprising. PxOUT is not cleared on reset; since you enabled the pin for output, the previous setting is left unchanged. This is documented in the 2xx family user's guide (Table 8-2 Digital I/O Registers) from slau144j. A sufficiently long power-down might cure the problem, but in general if you're going to change the configuration of a GPIO from its power-up state you should set all the relevant registers.
  7. Like
    pabigot got a reaction from spirilis in New BoosterPacks - CC3100 & CC3200   
    Or not.
     
    I think there's going to be too much functionality on this device that's locked down in the no-source-provided ROM interface to allow development of any real advanced applications.
     
    For example, the CC3000 is useless in low power solutions: I get maybe 1500 one-shot UDP transmissions with CC3000 shutdown and LPM3 between them before two AAs drain on a EXP430F5529LP+CC3000 demo. Somewhere TI claimed the CC3100 could run for a year on two AA batteries, which means they must have done a whole lot of enhancements. If you read the CC3100/CC3200 Wi-Fi Network Processor Subsystem guide swru368.pdf section 4.6.1, the details on exactly what behavior is promised when in low power mode are lacking: "Long Sleep Interval" is clearly related to the IEEE 802.11 FCS Power Management bit, but some of the effects they describe are "extra" features TI's apparently chosen to enforce unnecessarily; and "Low latency power" is completely uninformative as to its behavior.
     
    I think this is supporting evidence for @@jpnorair's observation that nobody's making money on IoT yet, and that this explains why everybody's trying to lock down everything in their solutions in hope that their magic beans are the ones that will hatch the goose that lays the golden egg (to abuse some metaphors). Personally, I think that's absolutely the wrong approach, but I have this non-entrepreneurial focus on providing long-term value rather than snatching at short-term profit.
     
    But yes, at this point it's pretty much all speculation. If the CC3200 LP is still available cheap in mid July when I might have a chance to play with one maybe I'll buy one. I probably won't invest in much CC3100 technology, since TI has not demonstrated an ability to make the CC3000 work. When I read the last couple paragraphs of this post carefully I conclude that the CC3000 is EOL, having served its purpose of getting external users to spend the necessary tens of thousands of hours required to beta-test everything. My last hope is the final firmware release 1.14 for the CC3000 will make the thing robust enough to deploy. That hope is pretty slim.
  8. Like
    pabigot reacted to spirilis in New BoosterPacks - CC3100 & CC3200   
    They keep touting OpenOCD support in the product page for the LaunchPad, fwiw.  https://estore.ti.com/cc3200-launchxl.aspx
    I can't imagine it needs anything more than arm-none-eabi-gcc and the correct linker+driver headers... but who knows.
  9. Like
    pabigot got a reaction from yosh in Be aware : Launchpad can retain old code in memory   
    It's also not surprising. PxOUT is not cleared on reset; since you enabled the pin for output, the previous setting is left unchanged. This is documented in the 2xx family user's guide (Table 8-2 Digital I/O Registers) from slau144j. A sufficiently long power-down might cure the problem, but in general if you're going to change the configuration of a GPIO from its power-up state you should set all the relevant registers.
  10. Like
    pabigot got a reaction from spirilis in Be aware : Launchpad can retain old code in memory   
    It's also not surprising. PxOUT is not cleared on reset; since you enabled the pin for output, the previous setting is left unchanged. This is documented in the 2xx family user's guide (Table 8-2 Digital I/O Registers) from slau144j. A sufficiently long power-down might cure the problem, but in general if you're going to change the configuration of a GPIO from its power-up state you should set all the relevant registers.
  11. Like
    pabigot got a reaction from jsolarski in FatFS on MSP430G2744   
    Just a reminder: in addition to a 43oh FatFS port that I believe @@bluehash has made available somewhere around here, I maintain a github repository that tracks all releases of FatFS and Petit FatFS and the sample code, including patches, updated whenever I happen to remember. This may be useful to people who want to see how it changes over time, since ChaN only publishes packaged releases. (For example, R0.10 introduced an API change to f_mount.)
     
    BSP430 has an example fatfs interface that may also be useful, as the FatFS sample package dropped the generic example back in 2013.
  12. Like
    pabigot got a reaction from uberscientist in FatFS on MSP430G2744   
    Just a reminder: in addition to a 43oh FatFS port that I believe @@bluehash has made available somewhere around here, I maintain a github repository that tracks all releases of FatFS and Petit FatFS and the sample code, including patches, updated whenever I happen to remember. This may be useful to people who want to see how it changes over time, since ChaN only publishes packaged releases. (For example, R0.10 introduced an API change to f_mount.)
     
    BSP430 has an example fatfs interface that may also be useful, as the FatFS sample package dropped the generic example back in 2013.
  13. Like
    pabigot got a reaction from bluehash in FatFS on MSP430G2744   
    Just a reminder: in addition to a 43oh FatFS port that I believe @@bluehash has made available somewhere around here, I maintain a github repository that tracks all releases of FatFS and Petit FatFS and the sample code, including patches, updated whenever I happen to remember. This may be useful to people who want to see how it changes over time, since ChaN only publishes packaged releases. (For example, R0.10 introduced an API change to f_mount.)
     
    BSP430 has an example fatfs interface that may also be useful, as the FatFS sample package dropped the generic example back in 2013.
  14. Like
    pabigot got a reaction from oPossum in New BoosterPacks - CC3100 & CC3200   
    Interesting; thanks for the pointer. The big problem is that over the last couple years TI has completely failed to make the CC3000 robust enough to be deployable solution, and their support for it has diminished significantly over the last couple months. Maybe the CC3100 is intended to magically fix all the CC3000's problems, but my expectations aren't high.
  15. Like
    pabigot reacted to spirilis in New BoosterPacks - CC3100 & CC3200   
    Ok, so CC3100 = CC3000 + TLS engine built-in.  CC3200 = CC3100 + .... some vaguely-Tiva-ish Cortex-M4 (not F?) MCU built in.  Technical Ref. Manual isn't available for d/l yet.
  16. Like
    pabigot reacted to RobG in New BoosterPacks - CC3100 & CC3200   
    Visited TI store this morning and noticed few new BPs
     
    CC3200-LAUNCHXL - SimpleLink Wi-Fi CC3200 LaunchPad
     
    CC3100BOOST - SimpleLink Wi-Fi CC3100 BoosterPack
     
    CC31XXEMUBOOST - Advanced Emulation BoosterPack for SimpleLink Wi-Fi CC3100 BoosterPack
     
     
    More info:
     
    CC31xx & CC32xx Wiki
     
    CC31xx Quick Start
     
    CC32xx QucikStart
  17. Like
    pabigot got a reaction from tripwire in USCI_B0 in SPI mode   
    A frequent issue with I2C/SPI on the Launchpad is that P1.6 (MISO/SCL) is wired to the green LED. On at least some LP revisions you have to remove the jumper, or the USCI signals don't work work properly. FWIW, you also generally don't have to set PxDIR when in peripheral mode: the PxSEL setting has that effect (but check the port schematic pages in the data sheet because it's not true for every peripheral function).
  18. Like
    pabigot got a reaction from OppaErich in and again weird errors - Keil uVision   
    Is the posted code complete? Certainly placing functional statements such assignments to SYSCTL_RCGC1_R at functionfile level is not valid C, so perhaps that's inside a code block that was removed (or was not added as it needs to be).

    It's unusual in pre-C99 code to intersperse variable declarations like the one for tictac with code, so that warning may be a different issue.
  19. Like
    pabigot got a reaction from robomon in How to send 1MSPS 12bit ADC samples via USB FS   
    Also note the 12-bit samples are packed into 16-bit half-words, so unless you have the MCU intervene to pack them tighter you're actually talking a data rate of 2 MiBy/s.
  20. Like
    pabigot got a reaction from bluehash in __delay_cycles   
    The code is here; the analysis is here.
     
    The resolution of the prediction is I learned several things---among them, that MOV R8, R8 takes two cycles---but the null hypothesis holds.
     
    The conclusion is:

  21. Like
    pabigot got a reaction from GeekDoc in Newbie general C code question   
    I see that happening more and more; I blame it on injudicious application of MISRA rule 6.3.
     
    It's absolutely the case that types with specific sizes should be used when the range is potentially beyond the native word size of the processor or data is exchanged over a communication link, including via a file.
     
    I have yet to see a cogent argument why specific-size types should be used in preference to "int" and "unsigned int" for indexes and offsets where the native word size is appropriate, or when you're manipulating a processor peripheral that is known to be that native word size.
     
    On one hand, you might select a type that's too large for a target processor, impacting portability. TI did this recently to the CC3000 host interface, changing it so every parameter is a uint32_t even if its value range is less than one octet. This unnecessarily bloats code and hampers performance on the MSP430. Sure, when it goes out over SPI it needs to be 4 octets: but that's an encoding issue and should not propagate up to the library API.
     
    Or you might go too small, and select uint8_t. Two problems: (1) it's a pain if you wrote code to index over an array, and somebody increases the array size above 255. (2) A uint8_t value will promote to the signed type int when used in expression calculations. I've got some discussion of this on my blog; the non-C++ stuff related to uint8_t is at the end. tl;dr: -x doesn't mean what you probably think it does.
     
    The advice @@roadrunner84 gave is better, though if the "appropriate type" argument is applied consistently one should use size_t for all variables used as indexes as well as sizes. Which will hurt you badly on the MSP430 if you're using a memory model that supports objects larger than 64 kiBy, so I prefer unsigned int there too.
     
    Note: If you are going to use the size-specific types, get in the habit of explicitly including either <inttypes.h> or its lesser cousin <stdint.h>. Yes, for MSP430 and ARM the vendor headers provide it for you, but if you don't remember that it comes from the C library, not the C language, you'll be confused when you graduate to host platforms where it's not part of the null context.
  22. Like
    pabigot got a reaction from roadrunner84 in Newbie general C code question   
    I see that happening more and more; I blame it on injudicious application of MISRA rule 6.3.
     
    It's absolutely the case that types with specific sizes should be used when the range is potentially beyond the native word size of the processor or data is exchanged over a communication link, including via a file.
     
    I have yet to see a cogent argument why specific-size types should be used in preference to "int" and "unsigned int" for indexes and offsets where the native word size is appropriate, or when you're manipulating a processor peripheral that is known to be that native word size.
     
    On one hand, you might select a type that's too large for a target processor, impacting portability. TI did this recently to the CC3000 host interface, changing it so every parameter is a uint32_t even if its value range is less than one octet. This unnecessarily bloats code and hampers performance on the MSP430. Sure, when it goes out over SPI it needs to be 4 octets: but that's an encoding issue and should not propagate up to the library API.
     
    Or you might go too small, and select uint8_t. Two problems: (1) it's a pain if you wrote code to index over an array, and somebody increases the array size above 255. (2) A uint8_t value will promote to the signed type int when used in expression calculations. I've got some discussion of this on my blog; the non-C++ stuff related to uint8_t is at the end. tl;dr: -x doesn't mean what you probably think it does.
     
    The advice @@roadrunner84 gave is better, though if the "appropriate type" argument is applied consistently one should use size_t for all variables used as indexes as well as sizes. Which will hurt you badly on the MSP430 if you're using a memory model that supports objects larger than 64 kiBy, so I prefer unsigned int there too.
     
    Note: If you are going to use the size-specific types, get in the habit of explicitly including either <inttypes.h> or its lesser cousin <stdint.h>. Yes, for MSP430 and ARM the vendor headers provide it for you, but if you don't remember that it comes from the C library, not the C language, you'll be confused when you graduate to host platforms where it's not part of the null context.
  23. Like
    pabigot got a reaction from igor in __delay_cycles   
    The code is here; the analysis is here.
     
    The resolution of the prediction is I learned several things---among them, that MOV R8, R8 takes two cycles---but the null hypothesis holds.
     
    The conclusion is:

  24. Like
    pabigot reacted to oPossum in Newbie general C code question   
    When the max value is less than 2^8 (256): uint_fast8_t
    When the max value is less than 2^16 (65536): uint_fast16_t
    When the max value is less than 2^32 (4,294,967,296): uint_fast32_t
    When the max value is less than 2^64 (aprox 1.8E19): uint_fast64_t
     
    These fast variants will be promoted to the best suitable integer type. That will typically be an integer multiple of the register width. So on the MSP430, uint_fast8_t becomes unsigned [16 bit]. On x86 it would be 16, 32 or 64 bits depending on target operating mode. This doesn't matter much on the MSP430, but it does on some others such as 16 bit PIC.
  25. Like
    pabigot got a reaction from Rei Vilo in Newbie general C code question   
    OK, fine, though my recommendation of the JSF-AV document was intended as general advice rather than in the context of this specific issue. I'm still not gonna use or recommend using a size-qualified type for local variables used solely for indexing arbitrary objects. (I would endorse use of size_t, except that it's a pain when using msp430-elf-gcc.)
     
    FWIW, the claim in the JSF-AV appendix related to whether char is signed or unsigned is not good advice; char is signed for every GCC target I know, and probably for LLVM as well. Best to only use unqualified char for text (which JSF-AV may recommend somewhere else), and explicitly convert it to an integral type if treating it as an integer.
×
×
  • Create New...