• Announcements

    • bluehash

      Forum Upgrade   03/11/2017

      Hello Everyone, Thanks for being patient while the forums were being fixed and upgraded. Please see details and report issues in this thread. Thanks!

nickds1

Members
  • Content count

    22
  • Joined

  • Last visited

  • Days Won

    5

nickds1 last won the day on April 7

nickds1 had the most liked content!

About nickds1

  • Rank
    Member
  • Birthday April 19

Contact Methods

  • Website URL
    http://www.desmith.net/NMdS

Profile Information

  • Gender
    Male
  • Location
    - Somewhere hot surrounded by a LOT of sand...
  • Interests
    Just about everything...

Recent Profile Visitors

244 profile views
  1. http://projectgold.ru/gearbestles/3w_sconces_led_wall_lamp.html

  2. http://projectgold.ru/gearbestles/practical_433mhz_rf_transmitter.html

  3. http://projectgold.ru/izobility/molochnik_cena_400nbspr__.html

  4. "...or tear more hair out..." May i be so bold as to suggest not using Energia in this case? For true micropower applications, total control of all aspects of the device's operation is essential. Having a framework doing stuff you don't know about in the background is not helpful when calculating the energy budget or predicting performance. I'm doing an FR5969 IoT project at the moment and it's coded from scratch. By careful design and fine tuning I've managed to get the power consumption so low that it'll run off a CR2032 for at least a year - every little bit of the code is tuned - I couldn't do that if there was a 3rd party framework behind it. EnergyTrace++, LPM modes and interrupts are your friends. Energy harvesting is next up.
  5. Late into this thread, and I haven't read it top to bottom, but there seems to be a slight conceptual gap developing regarding what C & C++ really are. They are languages, not environments. The C language was originally designed for telephone exchange testing & control. Subsequently, it was used to implement the early UNIX kernels. There is a "C Standard Library", which is distinct from the language proper - this is where printf etc. come from. The story is similar with C++ - the language is distinct from its support libraries, e.g. stdlib, STL, and the various boost libraries. A huge amount of apocrypha and mis-information surrounds these languages and the pros and cons of their various implementations - most of the arguments are bogus and ill-informed. The truth is, IMHO, far more boring - that they each have pluses and minuses. The main differences are that C++ is geared to a more object-orientated design methodology, and generally, the mindsets used are different, which is why some feel that teaching people C, then C++ is a bad plan. When mis-used, C++ can be memory-hungry, which is one some decry its use for embedded work - I feel that this is a fallacy - C++ is absolutely fine for embedded work (I use it all the time), if you understand the consequences of your actions - C++ is a far more powerful & capable language than C, but with great power comes great responsibility (*) - blaming the language for your poor understanding of the consequences of your actions is not an excuse. C++ is easy to abuse, C can be plain dangerous... An analogy I like to use is the difference between "mathematicians" and "people who do mathematics". A mathematician has an intuitive grasp of numbers and mathematics - they can visualize the problem they are working on and come up with novel ways of solving it; further, when presented with a left-field/previously unseen problem, they will see ways of dealing with and solving that. Someone who does maths, OTOH, knows how to follow rules and can solve problems that are related to problems that they have encountered before, but may have real issues dealing with a novel puzzle.. Same with programmers. There's a world of people who can do C or C++ and have used the support libraries - that does not make them good or even half-decent programmers. In my career, I have found very very few genuinely good programmers - people who understand architectural issues, who can see solutions, who can visualise novel approaches and solutions, who understand and then, very importantly, can implement with excellence - it's the difference between a programmer (rare beast), and journeymen who know how to program (common as anything).. Note: I was involved in the ANSI C process and have been an editor or cited as a contributor to various C++ related books, including Scott Meyers' "Effective STL" etc Spent 30 years in the City of London and elsewhere as a CTO, designing, developing and implementing some of the world's largest real-time equity, derivative & FX exchange trading systems, mostly in C & C++. (*) Attributed to Ben Parker, Peter Parker's uncle...
  6. I highly doubt that this is an HW issue, though it's possible.... lets start with the code... Is the Watchdog timer still running? You've not stopped it (though I don't use Energia and don't know if it's stopped by default).. The code you provided is a bit messy, but is essentially the same as in the driverlib manual, and looks OK, except the WDT is on. As this seems to be a timing-sensitive issue, I'd start by stopping the WDT.
  7. Hi, I needed a way to see how much of my C++ stack was being consumed in my MSP application - the traditional way is to "poison" the stack with a known pattern, and then to see how much of it gets burnt away. So I wrote the following - hope folk find it useful: The following code allows you to simply do this and to check at any point how much of the pre-allocated stack was consumed during peak usage, i.e. how close your app got to the bottom of the stack, or indeed, whether it over-ran. The TI CCS documentation is completely wrong in the names it gives for the global symbols that define the size and start of the stack - needs to be updated, Stick this code (or similar) wherever you want to report on/check stack usage <smallest number of byes left free on the stack since initialisation>/<configured size of the stack>. #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif and then, in your main code you need to poison the stack as early as possible and then define the reporting routines: // Define STACK_CHECK to include stack usage diagnostics #define STACK_CHECK #if defined(STACK_CHECK) #define STACK_INIT 0xBEEF // Pattern to use to initially poison the stack extern uint16_t _stack; // Start of stack (low address) uint16_t stackMinFreeCount(void); uint16_t stackMaxSize(void); #endif #if defined(__cplusplus) extern "C" { #endif #if defined(__TI_COMPILER_VERSION__) || \ defined(__GNUC__) int _system_pre_init( void ) #elif defined(__IAR_SYSTEMS_ICC__) int __low_level_init( void ) #endif { //... stuff... #if defined(STACK_CHECK) // // Poison the stack, word by word, with a defined pattern // // Note that _system_pre_init is the earliest that we can // do this and that it may not be possible in TI-RTOS // // When we call the __get_SP_register intrinsic (same on IAR & CCS), it will return the address // of the RET address for the caller of this routine. Make sure that we don't trash it!! // register uint16_t *stack = &_stack; // Address of lowest address in .stack section register uint16_t *stack_top = reinterpret_cast<uint16_t *>(__get_SP_register()); do { *stack++ = STACK_INIT; // Poison stack addresses } while (stack < stack_top); // Stop before top of stack to leave RET address #endif return 1; } #if defined(__cplusplus) } #endif #if defined(STACK_CHECK) /** * Check how deep the stack usage has been * * \return \c uint16_t Minimum number of bytes to bottom of stack */ extern uint16_t __STACK_END; // End of data extern uint16_t __STACK_SIZE; // Linker-set size of stack uint16_t stackMinFreeCount(void) { const uint16_t *stack = &_stack; uint16_t freeCount = 0; while (*stack == STACK_INIT && stack++ <= &__STACK_END) { freeCount++; } return freeCount << 1; } /** * Return size of C++ stack * * Set by the linker --stack_size option * * \return \c uint16_t Configued maximum size of the stack in bytes */ uint16_t stackMaxSize(void) { return static_cast<uint16_t>( _symval(&__STACK_SIZE) ); } #endif int main(void) { ... stuff #if defined(STACK_CHECK) std::printf( "Stack: %d/%d\n", stackMinFreeCount(), stackMaxSize() ); #endif ...stuff }
  8. You could always use void GPIO_toggleOutputOnPin ( uint8_t selectedPort, uint16_t selectedPins Simplifies the loop code a bit... )
  9. This seems to be using a Raspberry Pi to drive the LEDs if you look carefully at the flow chart in the "Making of" associated video...
  10. Quick question on this - the counters go from 0-n and reset at n, so the actual count would be n+1. I thought that to count precisely "n" tickets, the CCRx registers would have to be set to "n-1"...
  11. Just wondering what RTOS people have been using (if any) that can take advantage of the MSP430[x] ULP modes? I've been having a look at TI-RTOS, FreeRTOS, TinyOS & Contiki etc. Experiences & thoughts welcome, Thanks
  12. Bit new to the MSP430 - I have the new FR5969 launchpad and was playing with RTC_B. Ideally, I'd like to protect the RTC over a main power failure, i.e. keep it ticking but stop the rest of the processor (think clock that doesn't lose track during a power outage). Is there a way to do this without an external RTC (e.g. DS3231 etc.)? Some other MSP430s have a "VBAT" pin that helps in this, but not the FR5969... Thanks Nick
  13. To be honest, I wasn't thinking so much about productisation, more about your safety. Even for personal use, I'd never use anything other than an X2 (you don't need X1 or Y-class) in this situation - you have a genuine fire hazard otherwise An X2 cap and a MOV are just a few cents, and could save you a world of pain ! Even better, use a Fairchild FSAR001B http://www.fairchildsemi.com/ds/FS/FSAR001B.pdf - cheap, small, no worries about capacitor types and does the job properly!
  14. In London UK, recruiters get 18% or thereabouts - they ASK for 30%, but you'd have to be a pretty naive company to actually pay that - I've been recruiting staff for my teams for 30 years - we never pay more than 20%.
  15. I just love clocks (especially cold-cathode and similar...)... Nice project... That's a good capacitor but not rated for this application - you should really be using an X1 or X2-rated cap for safety... not just for shock, but fire hazard etc. "X" capacitors are flame retardant and mandatory in Europe - don't know about US but both the Microchip App note and TI blog above also specify an X2-rated cap (as they should too!). A good one here would be VISHAY - MKP3382 X2, 4n7 @ 630VAC, p/n BFC233820472, Farnell p/n 121-5463 Also, you should probably have a MOV across the mains on the hot side of the cap - the cap will do its work with a nice 50Hz (and 60Hz) sinusoidal waveform, but a mains-borne transient from, say, a motor (fridge/washingmachine/nearby lightning etc.), has far higher dV/dT and will cause a DC spike, quite possibly in the 100+V region. A MOV won't be 100% effective in all cases, but its a good move. Have you measured or 'scoped the final DC voltage - is the zener doing the clipping or is the voltage below 3.9V? The two smoothing caps will also sink current - typically between 50 and 100uA each - with such a low delivery current to the uP & LEDs, these parasitics become very significant and can drop the final DC value significantly - maybe consider upping the 4n7 to 5n6 or 6n8? You can also lose one diode (D2) by replacing the lower two diodes in the bridge by 4.2V zeners and changing R11 to about 470R. With C3 at 22n you'll get a nice steady 3.6V with about 20mV ripple...