Thread: Embedded C .. Advice & Opinions

  1. #1
    Registered User
    Join Date
    Jan 2015
    Posts
    2

    Embedded C .. Advice & Opinions

    Hi Everyone,

    HHHmmm well a bit about myself, is that I am an electronics hobbyist, who went to university in the uk and done electrical and electronics engineering and done very well.

    I work as an electronics technician at the min and also in spare time do a few projects.


    I have joined this web site in search of some help ???


    I want to learn Embedded C but have no idea how to go about this??

    I want to learn it to programme micro controllers to give my electronic projects some life and also would like to master it (an how long that would take)???

    I want to know what is the future of programming micro controllers and what is the future of C !!! is it worth me spending 5 - 10 years to master it .....will it still be a useful skill and language in 10 - 20 years???




    I want to hear peoples opinions and advice on the future of embedded C programming????


    I also want to know about peoples experiences of learning embedded C and if it was worth it????

    Lool i feel like i am asking for alot now but I would also like to know about people who work as C consultants/freelance and how do they find it and why they choose that path??


    all opinions and advice are welcome and will be appreciated

    thank you for reading =]

  2. #2
    Ticked and off
    Join Date
    Oct 2011
    Location
    La-la land
    Posts
    1,728
    This is from a hobbyist's perspective, and only my own opinion:

    Currently, the hobbyist market is full of Arduino-compatible stuff. It's pretty easy to start with, and quite cheap, too (especially the clones). Arduino development environment is basically embedded C/C++, heavily augmented with Arduino libraries.

    Many manufacturers and companies have their own embedded C/C++ environments, of course -- mbed, STM, Microchip has some for PIC microcontrollers, and so on. I don't use those personally, because I prefer open tools myself. (I also do not use Windows at all, so I don't know and don't care which tools work best in Windows.)

    The approach I've suggested to my friends, is getting a Teensy 2.0 or Teensy++ 2.0, rather than an Arduino, as their first microcontroller. One reason is the low price. The main reason is that Teensies do not have a USB-to-serial bridge, but are native USB devices; this means you can program one to be a mouse, keyboard, a combo, or any other USB device you like. I've used it to emulate USB-connected devices for device debugging and driver development, but my first actual project was an arcade-style joystick and microswitch buttons for some serious old-style gaming. An easy, and really fun first project, and on the bare metal without any support libraries, too.

    You can program the Teensies (1.0 and 2.0, not the 3.x series) using AVR-GCC (available for all Linux distros; AVR MacPack for Mac; WinAVR for Windows), which is completely free. Finally, Teensies can be programmed using the Arduino development environment via Teensyduino.

    In short, all you need is the Teensy, a USB-MiniUSB (5-pin) cable, and the free software you can download off the internet, and you're ready to build something. Take a look at the examples first, though.

    The reason I recommend this path, is that I think it is best to start from scratch, with minimal investment, and see where it takes you. (If you start with Arduino, do remember that the Arduino libraries handle a lot of the low-level stuff for you, so if you go bare-metal later on, you'll probably have to un-learn some habits you pick up on the way. On the other hand, there is no reason why you couldn't use Arduino in commercial projects, too.)

    32-bit microcontrollers have in the last few years become much more affordable. The newer Teensy 3.1 is programmed using the Arduino development environment, but has an order of magnitude more RAM (65536 bytes) at the same price range. The STM32 Discovery evaluation boards are even cheaper (under ten UKP), but you need to use the STM32 development tools (although ARM-GCC will do if you use Linux), and you cannot use them as-is in end products (they're only for evaluation).

    Then, if you double the price to the $50 range, there are several single-board-computers like BeagleBone Black that have HDMI connectors for displays, 512MB of RAM, and so on; basically easily running Android or Linux, although you can also program them as if they were "just" microcontrollers. New, interesting ones pop up constantly.

    Alternatively, you can branch off to FPGAs (like Mojo v3), and start designing and implementing your own logic at the chip level.

    Whatever you do, I recommend you tip your toes in with a small, fun project first, and see where that takes you. For inspiration, check out projects on maker sites like Hackaday blog and Instructables (Arduino Instructables) and so on.

    If you like old-style arcade games, the arcade-joystick-and-buttons project using a Teensy 2.0 is a good starting point. The Teensy 2.0 costs under $20, a Zippyy joystick around $10-$20 depending on where you buy it, and mashable buttons are easily available for about $2 (here, there and elsewhere); for me the project cost about 50, but that includes the 30cm-by-80cm Baltic Birch (untreated, planed and sanded) board I built it on. If you use the pinned version of the Teensy 2.0, and use a socket for it, you can later remove the Teensy and use it in other projects (or more likely, on breadboard when testing some idea).

    Anyway, I'm not affiliated with any of the above, and they only reflect my personal preferences as a heavily open-source/free-software/Linux -oriented hobbyist. I hope others will pitch in with their point of view.

  3. #3
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    Whatever you do, I recommend you tip your toes in with a small, fun project first, and see where that takes you.
    This is very important!

    Hardware is complicated.
    For your first project do not make it overly so.
    At least, keep the software/programming part manageable.

    I tried something out of my reach and am somewhat afraid to approach electronics again.
    (If you're wondering, I tried to make the mouse cursor move from accelerometer input.
    Totally had no idea about what to do with the data once I got it. )

  4. #4
    Registered User
    Join Date
    Jan 2015
    Posts
    2
    Quote Originally Posted by manasij7479 View Post
    This is very important!

    Hardware is complicated.
    For your first project do not make it overly so.
    At least, keep the software/programming part manageable.

    I tried something out of my reach and am somewhat afraid to approach electronics again.
    (If you're wondering, I tried to make the mouse cursor move from accelerometer input.
    Totally had no idea about what to do with the data once I got it. )



    Well I was thinking of getting a development board and start playing about but didn't know which language i should learn for embedded electronics...i like a challenge so sud be ok

  5. #5
    Ticked and off
    Join Date
    Oct 2011
    Location
    La-la land
    Posts
    1,728
    Quote Originally Posted by manasij7479 View Post
    If you're wondering, I tried to make the mouse cursor move from accelerometer input.
    You need a native USB microcontroller for that; a serial-to-USB -bridged one like most of the Arduinos won't work.

    With a Teensy (1.0, 1.0++, 2.0, or 2.0++), the mouse example is here, including the sources. The example contains all the mouse-related stuff you need, and the usb_mouse_move(x, y, wheel) interface is perfect for your case. Remember: mice report relative movement only. (Absolute positions are also possible, they're just touchpads or similar, not mice.)

    Quote Originally Posted by manasij7479 View Post
    Totally had no idea about what to do with the data once I got it.
    Did you ask here? (I don't visit the C++ forums, so I've missed those. Pity; I could've helped with the quaternion stuff, I like using those for rotations.)

    Accelerometers provide signed values indicating acceleration along or around an axis. Typically, the first three degrees of freedom are the normal Cartesian axes, X, Y, and Z. The others are typically rotations around each axis.

    First step would have been to just have a prototype output the accelerometer values without any kind of mouse stuff. With a Teensy, you could do this very easily using the USB Debug example. You would just look at the accelerometer values to get a feel as to its sensitivity; you could even write a test app running on your host, simulating mouse movement.

    Most accelerometers use 3.3V supply and signal levels, so with a Teensy, you'd need a logic level converter. You would of course use an accelerometer with a good sensitivity and high sample rate -- something like MMA8452Q, up to 800 Hz sample rate with 12-bit sensitivity at 2g looks quite good to me. (Teensies can do full 12Mbit/s, or a bit over 1 megabyte per second over the USB, so a 10-byte HID frame 500 to 1000 times a second should not be a problem.)

    Now, an accelerometer measures acceleration, not movement or speed. Since the human hand movement range is quite limited, we cannot accelerate our hands for more than a fraction of a second at a time. Thus, we cannot use the acceleration directly as the relative mouse movement reports. Our hands would slam into objects or detach from our torsos, and even if in a large room with microgravity, our hands would tire quite quickly.

    There are two approaches you could try here:
    • Integrate the acceleration to get velocity, and report the velocity as the mouse movement
      This basically uses the accelerometer sensors to replicate the sensed movement as the mouse movement.
      You'll probably get very good results, if you consider small velocities in magnitude as zero (to counter drift), and add "drag", reducing the velocity by a small scale factor each time step (also to counter drift).
      This leads to pretty intuitive behaviour, but you need to test in practice to find good numerical values to use.
    • Use the acceleration as a trigger, with the twice-integrated displacement determining the mouse velocity
      This way, the accelerometer movement is considered a command. For example, if the sensor was at the tip of your finger, and you moved it slowly up, then held there, the mouse would start moving up at a constant velocity. When you move it back down, the mouse stops.
      I'm not sure how intuitive this is, but it might work, because there should be less movement necessary to achieve desired mouse movement. I haven't tried this myself.


    USB HID (Human Interface Device) devices are reserved 1000 reports per second on the USB bus. Using something like 100 to say 250 reports per second should suffice, and have little enough latency to feel "natural". Depending on the sensor output, you might wish to "average" few samples to reduce the noise. I'm not exactly sure about the typical mouse report rate, but deviating too much from those might confuse some operating systems.

    Although human time perception is such that 20ms (1/50th of a second) feels instantaneous to most, pointing devices have multiple axes and curved movement does not look smooth if you don't have high enough sample rate.

    So, all that said, with a MMA8452Q accelerometer, my main loop would likely be something like
    Code:
    /* Maximum 16-bit signed integer that will not overflow if a 12-bit signed value is added */
    #define V_MAX 30719
    
    /* Inverse velocity decay rate, higher is slower */
    #define V_RATE 128
    
    /* Zero range */
    #define V_ZERO 1024
    
    /* Velocity to mouse report divisor */
    #define V_SCALE 128
    
    /* Number of accelerometer samples per mouse report */
    #define SAMPLES_PER_REPORT 2
    
    /* These would be updated by read_MMA8452Q(), and sign-extended to 16 bits */
    static int16_t a_x, a_y, a_z;
    
    /* These are the internal velocity counters */
    static int16_t v_x = 0, v_y = 0, v_z = 0;
    
    /* Mouse report */
    signed char m_x, m_y, m_z;
    
    /* Just a loop variable */
    unsigned char i;
    
        while (1) {
    
            for (i = 0; i < SAMPLES_PER_REPORT; i++) {
    
                read_MMA8452Q();
                v_x += a_x;
                v_y += a_y;
                v_z += a_z;
    
                if (v_x > V_MAX)
                    v_x = V_MAX;
                else
                if (v_x < -V_MAX)
                    v_x = -V_MAX;
                else
                    v_x = v_x - (v_x / V_RATE);
                /*
                 * Same as above for v_y and v_z
                */
            }
    
            if (v_x > V_ZERO)
                m_x = (v_x - V_ZERO) / V_SCALE;
            else
            if (v_x < V_ZERO)
                m_x = (v_x + V_ZERO) / V_SCALE;
            else
                m_x = 0;
            /* Same for m_y and m_z, perhaps
             * larger V_SCALE for m_z (mouse wheel) */
    
            usb_mouse_move(m_x, m_y, m_z);
        }
    Note that because we have discrete samples with a constant interval, integration becomes a simple addition.

    The V_ZERO, V_SCALE, and V_MAX constants I drew out of my behind, so they're likely wrong.

    You might also make the velocities 32-bit, to allow for larger integration range. With 16 bits, there's just 4 bits for integration room, meaning 16 consecutive samples result in clipping already. With 32 bits, we'd have 20 bits, meaning you'd need 220 = 1,048,576 consecutive maximum samples to hit the limit.

    I don't have an accelerometer to play with, so I'm not sure if the above works in practice, but from a physics point of view, I don't see why it would not.




    Going back to the original topic, manasij7479's experience is a perfect example of why you should also make sure you have a community where you can ask for help, if you hit a snag. With things like accelerometers, you might need a bit of physics to immediately see how they can be used, so having a community where you can ask for specific details and help, is quite important, in my opinion.

    Which is to say: Find a good community, and pick the right boards there to ask the questions in, always give enough context (in case your approach itself is wrong), and for good measure make sure you always show your own efforts, too, so that other members see you're not asking others to do your work for you. (There's tons of freeloaders and leeches in discussion boards looking for free homework services, so initial reactions may be quite negative if you happen to be misunderstood in your purpose.)

    As to the language, embedded C or C++ (meaning a freestanding C or C++ environment, with no standard libraries, only special-purpose libraries like Arduino libraries or vendor-specific libraries), is certainly a valid choice, and one I would personally recommend. Reasons are the ubiquity of Arduino, the number and quality of the free tools (many of the commercial development environments use the free GCC compiler suite!), and the number of long-term supported, commercial embedded C/C++ environments.

  6. #6
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    I used an Arduino and the MMA_7455 accelerometer.
    For prototyping, I moved the mouse with the XWarpPointer function.

    Here is what the data looked like:
    What kind of algorithm do I need to apply for this ?

    The approach that I remember almost working is interpolating the bumps into polynomials and then integrating them analytically (not numerically) to get the x, y values to offset the cursor with.
    But the resulting movement was too imprecise to do anything realisitic with.

  7. #7
    Registered User
    Join Date
    Nov 2012
    Posts
    157
    If you really do want to get into all the good stuff, freescale offers some really cheap boards (the KL25z being one of the more famous ones) and they allow for alot of flexibility in programming they also have a really well built IDE if you really want to get to know your stuff . mbed support is available if you are an arduino kinda person though. Seeing as you are well versed in electronics , you shouldn't have any problems working with freescale .

  8. #8
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Both C and C++ are very common in embedded, so yeah, learn both. And while sometimes the standard libraries aren't available (or available in a limited subset), they're still of great help, so DO learn them, but also understand that they may not be available in embedded systems all the time.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Ticked and off
    Join Date
    Oct 2011
    Location
    La-la land
    Posts
    1,728
    Quote Originally Posted by manasij7479 View Post
    I used an Arduino and the MMA_7455 accelerometer.
    For prototyping, I moved the mouse with the XWarpPointer function.
    Ah okay, so the mouse logic was done in host software. That works fine too.

    First, you need to switch the data rate to 250 samples/sec (set bit 7 of register $18, "Control 1"). 100 Hz is just not going to cut with this noisy data; with 250 samples/sec, it might work. Then, you need to provide the raw data streams for seven cases: keeping the sensor stationary for a second or so; and starting from rest, moving the sensor along each primary axis at a steady speed for a quarter of a second or longer, then stopping. Each of these should be labeled, and each data stream should include all three axes. (Best format is a simple text file, with the three values on each line, and files named per the action performed.)

    There are a large number of numerical operations that can be done here. One is to combine all three acceleration samples into a vector, then scale the vector based on which direction it points to. (For example, you do not normally use the mouse wheel while moving the mouse, so the "valid space" for the acceleration vector is more like a spinning top, i.e. round plate with a stick through it.)

    If the data contains any oscillation we know is above (in frequency) the typical human movement (I'd say anything above 5 Hz, i.e. 20 samples at 100 Hz, 50 samples at 250 Hz; half that or 10 or 25 samples from peak-to-peak), it might be feasible to filter it out using a low-pass impulse filter.

    Another option is to use say a 10 to 25 -sample sliding window, to measure the extrema (maximum acceleration in either direction), which should have fast response to movement start (although movement stop has a latency of the window size).

    Just eyeballing some curves without knowing what physically happened at the same time is not useful at all. You need to first practice the movements, to find something you find comfortable, then measure them (more than once would be even better), and then ask help with the numerical data. This applies to all human interfaces, by the way. There are just too many numerical methods to pick a good one, unless you know what a desired result looks like!

    Sorry for hijacking the thread, but if you are willing to do the measurements, and upload them somewhere, and start a new thread (the old one is closed, so I can't post there), I'm willing to help you with massaging the data to see if it actually works. (You can also contact me via e-mail, the address is on my web page linked to from my profile.)

    To everybody:

    This accelerometer has a maximum 250 Hz sample rate, which limits the amount of filtering that can be done. While manasij7479 found that the mouse emulation didn't work in practice, that could be just due to the limitations of the accelerometer used -- and much more precise sensor, with higher sample rates, are available, and might work for this.

    Because of that, I'm not convinced that manasij7479 tried something "out of their reach", but rather that the hardware (configuration) used turned out to not work the purpose. (I'm pretty sure, looking at the curves, that at 100 Hz with that much noise or ping-pong responses to movement, you'd get at most something like 5-10 mouse movement samples per second, which I don't think would work -- the latency alone would be infuriating. Move your hand, and the mouse moves a tenth of a second later -- nope, not going to work. 2.5x sample rate might make a difference, and is possible with this sensor.)

    As to the hardware and project selection, the same applies as in programming: You cannot know if it works in practice before you implement it. That's why we do prototypes!

    Getting apprehensive because of one failure, as manasij7479 described, is unfortunate: I'd call that failure a win, instead. You discovered something that does not work, and the reason why it would not work. If somebody else tried the same, you could tell them what didn't work, where the issue was, and what to try instead (higher sample rate at minimum, perhaps a better sensor; and more methodical procedure to obtain the data for others to help with the numerical processing). It's all good, in my opinion.

    There is a reason why Hackaday has a Fail of the Week column. Even if the project falls flat on its face, you can still have fun and learn new, interesting stuff.

    And you never know if somebody comes along and can help you fix the project, too.

  10. #10
    [](){}(); manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    *nullptr
    Posts
    2,657
    You have certainly motivated me enough to try this again!
    I will get the 250 samples data and see if anything changes.
    After that I will probably need help to find better approaches.
    I do not yet have much knowledge on signal processing, so that needs to change first.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 4
    Last Post: 04-22-2014, 04:16 AM
  2. Embedded Linux & Embedded Java
    By jdomm95 in forum Linux Programming
    Replies: 4
    Last Post: 10-02-2012, 09:01 AM
  3. Opinions please!
    By Queatrix in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 10-23-2005, 07:04 AM
  4. Getting a new PSU... need opinions
    By XSquared in forum Tech Board
    Replies: 4
    Last Post: 09-29-2005, 10:03 AM
  5. Opinions &advice if any plz!
    By breed in forum C Programming
    Replies: 0
    Last Post: 12-13-2001, 04:10 PM