Jump to content

nickds1

Members
  • Content Count

    22
  • Joined

  • Last visited

  • Days Won

    5

Reputation Activity

  1. Like
    nickds1 got a reaction from spirilis in More C versus C++   
    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...
  2. Like
    nickds1 reacted to zeke in Implementing an I2C slave device.   
    This is my approach to state machines. Your mileage may vary.
    Determine all of the sub-systems that you will want to service Commands, Controls and Inputs, User Interface, and Data Setup a system tick timer that fires its interrupt on a regular consistent basis. This system doesn't have to go into LPM4. If it does then periodically wake up the system and cycle through the software service loops then go back to sleep. Setup a series of service flags that are set during the interrupt service routine and cleared after being serviced: Flag(s) for Commands, Flag(s) for Controls and Inputs, Flag(s) for User Interface, and Flag(s) for Data Setup a variable that acts like the system timer odometer. Every Odometer == (DesiredInterval%ServiceFlag_n_now) set the ServiceFlag_n Decide how often you will service the other functional blocks of your code. For example, Update the 2x20 LCD display every one second, or Update the Serial Console every 250ms, or Retrieve the Temperature from a sensor every 15 minutes. Setup an Interrupt Service Routine to catch any characters coming into the Serial Port Buffer. Stuff them into the Input Ring Buffer Set a flag that there's something to service. In the main loop, scan all of the service flags to see if any are set. Call the servicing function for each set flag. Clear the service flag at the end of that process. Configure the program to repeat continuously until Kingdom Come.
    I've left out significant details about setting up all of the peripherals and general variables so don't forget to do that stuff.
    This is just the basic gist of my state machines on a bare metal level.
  3. Like
    nickds1 got a reaction from chicken in More C versus C++   
    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...
  4. Like
    nickds1 got a reaction from Fmilburn in More C versus C++   
    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...
  5. Like
    nickds1 got a reaction from dubnet in More C versus C++   
    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. Like
    nickds1 got a reaction from stirlingboy1426459970 in Easy way to monitor peak stack usage...   
    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 }  
  7. Like
    nickds1 got a reaction from tripwire in Easy way to monitor peak stack usage...   
    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. Like
    nickds1 got a reaction from bluehash in driverlib crc32 problem   
    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.
  9. Like
    nickds1 got a reaction from bluehash in Easy way to monitor peak stack usage...   
    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 }  
  10. Like
    nickds1 got a reaction from oPossum in Tiny low power LED clock   
    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...
  11. Like
    nickds1 got a reaction from tripwire in TLV Die record - how is it set?   
    Normally, wafers like this are stepped as the imagers can't maintain the super-fine focus over the whole wafer (this is certainly the case for fine-resolution chips such as modern CPUs).
     
    The wafer is stepped so that each die is imaged in turn - the tables cost an absolute fortune as they have to have phenomenal repeatability and the design of the lens is an enormously specialised art - only a few people in the world do it. 
     
    Quoting a friend in another forum (who is a lens designer for these machines):
  12. Like
    nickds1 got a reaction from pabigot in Getting started: Best BSP?   
    Yes - that was a mistake of my part, I meant MSP430Ware....
     
    I really appreciate the work you've done on BSP430 & mspgcc. As a professional programmer myself (though not an embedded one) you can see the amount of effort that has gone into those projects...
     
    Just as a thought, do you know of any plans to produce a clang/LVVM MSP430 back end? I've worked on the gcc compiler in the past, and to say that its a challenge would be a gross understatement - its a venerable old warhorse that is still extraordinarily useful, but there was a very good reason that the clang project was started....
×
×
  • Create New...