Jump to content

yyrkoon

Members
  • Content Count

    1,408
  • Joined

  • Last visited

  • Days Won

    34

Reputation Activity

  1. Like
    yyrkoon reacted to Rickta59 in More C versus C++   
    If the code you wrote above does what you want why do you want to be "c++ complete" ?
     
    The big advantage of boost is that it is cross platform and mostly made up of c++ templates except for the operating system stuff (which filesystem code is).  If you aren't planning on running this code on any other OS than linux then maybe it isn't worth your time.   Only you can decide what is time worthy.
     
    -rick
  2. Like
    yyrkoon reacted to Rickta59 in More C versus C++   
    The c++ way on a real os like linux would be to the boost library. It is all about iterators.
     
    http://www.boost.org/doc/libs/1_59_0/libs/filesystem/example/simple_ls.cpp
     
    -rick
  3. Like
    yyrkoon reacted to chicken in More C versus C++   
    Kate Gregory's point wasn't that you should stop using C. The talk was about better approaches to teach people C++ that don't know C and may even be new to programming. For that audience, starting with higher level concepts rather than pointers and char arrays makes a lot of sense.
     
    Getting a const char* out of a string should be straight forward. In the days of classes (when I was doing large scale C++ projects), the string class usually had an operator that transparently took care of the conversion. Not sure if STL has the same (I think so) or whether you explicitly have to use c_str() method.
     
    That being said, simply stick to the C++ constructs that make your live easier and don't feel bad about mixing them with plain C. I like to use classes to build better abstractions, or the template library for solid container constructs like lists. No benefit in being a purist in any direction.
  4. Like
    yyrkoon reacted to roadrunner84 in PWM from ADC joystick   
    //#include <msp430.h>
    #include <msp430g2553.h>
     
    /*
    * main.c
    */
     
    void main(void)
    {
    //int adcValue;
    WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
     
     
     
    //This is ADC10 control register
    //4th bit turns on ADC
    //11 and 12 sets "16
  5. Like
    yyrkoon reacted to chicken in How to prevent and detect stack overflow   
    Here's a great webinar on the topic of stack overflow from basics like stack sizing all the way to stack usage estimation and analysis, stack monitoring and stack overflow handling.
     
    Recording:
    Transcript: http://barrgroup.com/Embedded-Systems/How-To/Prevent-Detect-Stack-Overflow
     
    Found via the Embedded Muse newsletter.
     
     
     
     
  6. Like
    yyrkoon reacted to bluehash in Beaglebone-Web-PMIC-Register-Viewer   
    Placing the pic on github will really help. Nice job.
  7. Like
    yyrkoon got a reaction from bluehash in Beaglebone-Web-PMIC-Register-Viewer   
    Here is a screenshot for those that are curious, but may not care to actually go through the whole process just to see what the app does.
    https://photos.google.com/share/AF1QipMBlgvnVeue7SdioEo06_P2Zox_Hp3Q45noSM3tgIaL_3K2epj3FVE3neoQr0aiMQ/photo/AF1QipOSqWNV4ScwkHesOxO22l4WboYHcxfOiavjUGdP?key=cWVUeEl6djdZQlhvUl9yMDEwNGpFLTdLbURRUFpR
  8. Like
    yyrkoon got a reaction from radcliffkaty1 in Industrial / commercial sensors   
    By the way, this is the light level sensor we went with: http://www.acuitybrands.com/products/detail/147289/Sensor-Switch/CM-PC-ADC/Photocell-Dimming-Ceiling-Low-Volt
     
    Kind of expensive at ~$140, but when you need it NOW, hehe you usually end up paying through the nose.
     
    Eventually we may end up designing our own sensors, if there is a need . . . Problem is, finding good enclosures for a decent price.
  9. Like
    yyrkoon reacted to Fred in Industrial / commercial sensors   
    Olimex make a PIR sensor with a MSP430F2013 and based on a TI reference design. Might be worth taking a look at if you get to the "roll your own" stage. I once added a LDR to it and changed the code a bit to turn a light on in the bathroom at night when I went for a pee.
    https://www.olimex.com/Products/MSP430/Starter/MSP430-PIR/
  10. Like
    yyrkoon reacted to zeke in Industrial / commercial sensors   
    @@yyrkoon
     
    For your consideration:
    Motion Sensors from Grainger. Light Sensors from Grainger. I'm certain that there are many other options out there. This is where I would start my research.
  11. Like
    yyrkoon reacted to Fred in Logic Analyzers   
    You'll find a use for it soon enough.
  12. Like
    yyrkoon reacted to greeeg in Logic Analyzers   
    I would say that for a typical application the cost COULD pay itself off VERY quickly with time saved debugging. Of course it does depend on what you do. Often hobbyist/small commercial projects that's not so true.
     
    I personally have a OpenBench Logic Sniffer. (Which is compatible with Sigrok) I've really only used it a handful of times, The best example from my use case was reverse engineering an old B/W LCD module that I wanted to use in my project. But typically I'm much more productive with a Scope. (But of course limited to 4 channels.)
  13. Like
    yyrkoon reacted to zeke in Logic Analyzers   
    @@yyrkoon
     
    Joe and his brother built the company from the ground up. Their software was written in house. Their product is top notch. They are good people.
     
    EEVBlog has done a teardown.
     
    And another one here.
     
    If the Saleae isn't your cup of tea then maybe you might like the Open bench Logic Sniffer instead?
  14. Like
    yyrkoon reacted to Rickta59 in Basic MSP430 GPIO Macros   
    BTW:  that macro is missing parens around the ~pin ... should be ~(pin)
  15. Like
    yyrkoon reacted to Rickta59 in Basic MSP430 GPIO Macros   
    I think that is probably a gcc only optimization (forcing always_inline). I'm not sure if you can do that with the ti version.
     
    What I find interesting about discussions like this is that I'm often wrong about what feels true in my gut and what is actually true.  I'm sure I'm hampered by the fact I've been doing 'C' code now since 1982. I have a bag of personal biases that are often wrong with today's more capable compilers.  Lucky for all of you, optimization technology has come a long way since the days of the pdp 11
     
    -rick
  16. Like
    yyrkoon reacted to Rickta59 in Basic MSP430 GPIO Macros   
    These all seem to generate the same sized code ... 
    #include <msp430.h> #include <stdint.h> // MSP430 gpio macros #define GPIO_SEL(port) P ## port ## SEL #define GPIO_DIR(port) P ## port ## DIR #define GPIO_OUT(port) P ## port ## OUT #define GPIO_IN(port) P ## port ## IN #define GPIO_IS_INPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_OUTPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) |= (pin); } #define GPIO_IS_PERIPHERAL_IN(port,pin) { GPIO_SEL(port) |= (pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_PERIPHERAL_OUT(port,pin) { GPIO_SEL(port) |= pin; GPIO_DIR(port) |= (pin); } #define GPIO_SET(port,pin) { GPIO_OUT(port) |= (pin); } #define GPIO_CLEAR(port,pin) { GPIO_OUT(port) &= ~(pin); } #define GPIO_READ(port,pin) ( GPIO_IN(port) & (pin) ) #define GPIO_PIN(pin) (1 << (pin)) __attribute__((always_inline)) static inline gpio_is_output(const unsigned port, const unsigned pinno) { switch(port) { case 1: P1SEL &= ~(1 << pinno); P1DIR |= 1 << pinno; break; case 2: P1SEL &= ~(1 << pinno); P1DIR |= 1 << pinno; break; } } //#define USE_MACRO void main(void) { WDTCTL = WDTPW|WDTHOLD; //DCOCTL -= 28; #if defined(USE_MACRO) GPIO_IS_OUTPUT(1,4); GPIO_IS_OUTPUT(1,6); GPIO_IS_OUTPUT(1,0); #elif defined(USE_INLINE_FUNC) gpio_is_output(1,4); gpio_is_output(1,6); gpio_is_output(1,0); #else P1SEL &= ~(BIT4); P1DIR |= BIT4; P1SEL &= ~(BIT6); P1DIR |= BIT6; P1SEL &= ~(BIT0); P1DIR |= BIT0; P1OUT &= ~BIT0; P1OUT |= BIT6; P1SEL |= BIT4; #endif #if defined(USE_MACRO) || defined(USE_INLINE_FUNC) GPIO_CLEAR(1,0); GPIO_SET(1,6); GPIO_SEL(1) |= GPIO_PIN(4); #endif for(;{ P1OUT ^= (BIT0|BIT6); __delay_cycles(1000000>>3); // delay } } At least with msp430-gcc. I didn't try with msp430-elf-gcc
    $ msp430-gcc -Os -g gpio_test.c -mmcu=msp430g2553 -DUSE_INLINE_FUNC; msp430-size a.out; msp430-objdump -CS a.out >/tmp/inline.txt text data bss dec hex filename 180 0 2 182 b6 a.out $ msp430-gcc -Os -g gpio_test.c -mmcu=msp430g2553 -DUSE_MACRO; msp430-size a.out; msp430-objdump -CS a.out >/tmp/macro.txt text data bss dec hex filenameD 180 0 2 182 b6 a.out $ msp430-gcc -Os -g gpio_test.c -mmcu=msp430g2553 ; msp430-size a.out; msp430-objdump -CS a.out >/tmp/reg.txt text data bss dec hex filename 180 0 2 182 b6 a.out
  17. Like
    yyrkoon reacted to enl in Basic MSP430 GPIO Macros   
    I tend to use this style for many things, in particular single thread embedded applications like one tends to have on the smaller MSP430's, but it isn't always my preference.
     
    The code tends to be more readable if done reasonably well, with full optimization available since it is expanded by the preprocessor, but inline functions can be just as efficient and are often less likely to lead to debugging issues, making them generally preferable when available, but with the drawback that expansion is not mandatory, so timing is not guaranteed. If forced, you lose some space optimization features.
  18. Like
    yyrkoon reacted to roadrunner84 in Basic MSP430 GPIO Macros   
    You could consider using C++ template programming instead of C style defines.
    I haven't tested this, but it would go something like this:
    template <int port> void GPIO_IS_INPUT(int pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } template <> void GPIO_IS_INPUT<J>(int pin) { GPIO_DIR(J) &= ~(pin); } Now instead of passing port as a macro like function parameter, pass it as a template parameter
    GPIO_IS_INPUT<LED1_PORT>(LED1_PIN); I'm not entirely sure this will work though; the double-hash preprocessor operator is very tricky.
     
    You could go all the way with these templates and get gone with the macros entirely.
    If you really want no function call overhead, just make them inline.
  19. Like
    yyrkoon got a reaction from chicken in Basic MSP430 GPIO Macros   
    Hi Chicken,
     
    So I thanked you for the first post. Because it think it's awesome when people share their code with others while offering up an explanation.
     
    However, personally, I would  not do this. Do keep in mind when I say this, that it's purely a personal preference, based on my coding beliefs. But basically, I would not do this because it "obfuscates" how things are done. It adds more code than is necessary, and it makes the code less readable at a glance.
     
    Readability, one cold really argue both ways. But when I say it makes it harder to see what's happening at a glance. I mean literally. Like, if we create a macro to clear a bit on a port, interrupt, whatever. How do we know that macro is correct, or what it actually does without going through an implementation file or two ? Additionally, sometimes it may not be clear where the actual macro is. When working with larger projects, and the source is not yours.
     
    Passed all that I do have a strong dislike for #define directives, as well as macros in general. For numerical values, I prefer to use const.
     
    Then somewhere in my past, I've read that creating function like macro's is not really a good thing. Whether I still believe that is true or not is mostly irrelevant. But I still prefer to use standard C functions.
     
    So, when I need to set, or clear, or whatever a pin, interrupt, port, or whatever. I prefer to do it right where it needs to be done, and in plain C. This also keeps me from becoming lazy, and forgetting "things" which I already have a hard time with. Since I jump around between several languages a lot . . .
     
    I have to say though, if this works for you. Then keep it up
  20. Like
    yyrkoon reacted to chicken in Basic MSP430 GPIO Macros   
    In my project, I use a few basic macros for GPIO. The goal is, that I can easily redefine pin assignment in a central location without compromising performance or code size.
     
    The macros (gpiomacros.h):
    // MSP430 gpio macros #define GPIO_SEL(port) P ## port ## SEL #define GPIO_DIR(port) P ## port ## DIR #define GPIO_OUT(port) P ## port ## OUT #define GPIO_IN(port) P ## port ## IN #define GPIO_IS_INPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_OUTPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) |= (pin); } #define GPIO_IS_PERIPHERAL_IN(port,pin) { GPIO_SEL(port) |= (pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_PERIPHERAL_OUT(port,pin) { GPIO_SEL(port) |= (pin); GPIO_DIR(port) |= (pin); } #define GPIO_SET(port,pin) { GPIO_OUT(port) |= (pin); } #define GPIO_CLEAR(port,pin) { GPIO_OUT(port) &= ~(pin); } #define GPIO_READ(port,pin)  ( GPIO_IN(port) & (pin) ) In a central configuration file (e.g. hardware.h) I assign pins like this:
    // Pin assignment #define LED1_PIN BIT1 #define LED1_PORT 6 #define LED2_PIN BIT0 #define LED2_PORT 1 And then in the code I interact with GPIO like this:
    // Setup LEDs GPIO_IS_OUTPUT(LED1_PORT, LED1_PIN); GPIO_IS_OUTPUT(LED2_PORT, LED2_PIN); // Turn off LEDs GPIO_CLEAR(LED1_PORT, LED1_PIN); GPIO_CLEAR(LED2_PORT, LED2_PIN); The macros are resolved in two steps:
    1. Higher level "functions" define the commands. E.g. GPIO_SET(), GPIO_IS_OUTPUT(), ..
    2. Lower level macros used within those functions translate port, pin to a register. E.g. GPIO_IN(), GPIO_SEL(), ..
     
    The end result is code like you would write when directly working with the GPIO registers. E.g. P2OUT &= ~BIT0; Note that this translation is done by the C pre-processor before the code is compiled.
     
    This all works fine and dandy, with the exception of port J. Port J doesn't have a SEL register, which breaks the 1st half of the GPIO_IS_OUTPUT and GPIO_IS_INPUT macros. I currently work around this by adding special GPIO_IS_OUTPUT/INPUT_J macros, but then the main code needs to include some logic to invoke the proper macro.
    #if (LED2_PORT == J) GPIO_IS_OUTPUT_J(LED2_PORT, LED2_PIN); #else GPIO_IS_OUTPUT(LED2_PORT, LED2_PIN); #endif Any ideas, how I could include a condition inside macros, that checks whether the port is J, and if so excludes the GPIO_SEL command?
     
    And yes, I could probably use C++ templates with identical results and an easy workaround for port J, but I'd like to avoid migrating my plain old C project.
     
    Edit: Added a few missing parentheses, thanks to Rickta59 for spotting that
  21. Like
    yyrkoon reacted to Rei Vilo in Logic Analyzers   
    I agree with you. If you don't need a tool, don't own it! On my case, I'm using those tools on a regular basis and I'm ready to pay for quality equipment.
  22. Like
    yyrkoon reacted to LiviuM in UART - Sending 3 bytes per start/stop bit sets.   
    Strange, I was thinking the English is my week point...
    What I tried to say is, if you look the diagram at page 4 in the Microchips AN, you'll see that every time the bit value changes (0->1 or 1->0) you don't have a transition at the end of bit, but if the bit repeats, you have a transition in the middle of the bit (the active one) and one transition at the end of bit.
    But looking now to the same diagram, I see now that if you can detect the start edge (first H->L transition), there are maybe better criteria to decode the bits.
  23. Like
    yyrkoon reacted to LiviuM in UART - Sending 3 bytes per start/stop bit sets.   
    For Manchester decoding (not on micro controllers, on other equipment), I've measured the time distance between consecutive edges. If the distance is half of the bit length, the last bit is repeated, if the distance is the bit length, the last bit is inverted.
    If you use in interrupt to detect the falling edge and to start a timer, and as you know the first (start) bit is a zero, detecting the next bits shouldn't be to difficult.
  24. Like
    yyrkoon got a reaction from spirilis in Logic Analyzers   
  25. Like
    yyrkoon got a reaction from spirilis in Logic Analyzers   
    If I went by what I wanted, and not what I felt I needed. I'd actually probably build my own beaglelogic cape. Since you can't seem to buy them anywhere. They've apparently been tested, and made working with sigrok.
     
    @@spirilis Don't get me started on shop related stuff . . . heh. We've pretty much got everything. For everything. Our air tank for instance is 100gal . . . and you guys probably don't want me to go on. Car lift, wood shop, Machine shop, soon to be PCB fab . . .
×
×
  • Create New...