12 Replies Latest reply on May 19, 2015 10:09 AM by yp66

    MCU operation questions

    yp66

      I'm trying to figure out the workings of the MCU and had some questions that are not directly addressed anywhere (at least I have not found an answer).

       

      I am using the 2.1 image on an edison mounted on the sparkfun base board (SparkFun Block for Intel® Edison - Base - DEV-13045 - SparkFun Electronics) and a GPIO board (SparkFun Block for Intel® Edison - GPIO - DEV-13038 - SparkFun Electronics).  The GPIO board is rather simple, it routes GPIO 44-49 and GPIO 14,15 through level shifters; it also contains access to the four PWM ports and serial port.  I'm trying to get to the PWM pins and serial I/O but I was trying to do something basic first.

       

      The program is rather simple as shown below.  The /etc/intel_mcu/mcu_fw_loader.sh is the 'standard' one, I have not added references to any of the scripts.

       

      #include "mcu_api.h"

      #include "mcu_errno.h"

      void mcu_main()

      {

        gpio_setup(15, 1);

        while (1)  {

          gpio_write(15, 0);

          gpio_write(15, 1);

          }

      }

      My first question has to do with the interaction between the MCU programs and API and the /sys/class/gpio file system.  After 'installing' the MCU program, the /sys/class/gpio does not contain entries for GPIO 14 or 15, yet the pins are functioning.

       

      The second question has to do with timing.  On pin 14/15, I get a square wave with a 12 uSec period (about 83 KHz) but on pin 48 I get a square wave with a period of almost 40 uSec (around 26 KHz).  Why such big difference in timing ?

       

      Any help would be greatly appreciated.

        • 1. Re: MCU operation questions
          KurtE

          Sorry, I am not sure of the answers here, but I am curious.

           

          Have you tried: echo 15 > /sys/class/gpio/export?

          If so did GPIO15 show up?  was your square wave still being output?

           

          I know the release notes mentioned that there currently is not any mechanism for reserving hardware for either main CPU or MCU... so probably you can export it...

           

          I am curious to hear about the speed and why some pins are different. 

          • 2. Re: MCU operation questions
            yp66

            KurtE - exporting the pins still works, in the sense that it creates the /sys/class/gpio/gpXX entry; not much use if you are using the MCU for I/O but I am just trying to confirm what is going and the 'proper' way to do things, as documentation is spotty.   Initially, I though this is a required step because of the scripts that have to be included in the startup file; after looking at them and beating my head against the wall regarding getting an error message when i try to export GPIO 213 and other 'higher' numbers, I realized this is only relevant on the larger break-out boards as these are I/O devices that route the signals to various board pins.  In my case, I am using a bare-bones Edison so there is no need for scripts - I think.

             

            I am eager to figure out the difference in speed as well - even the full speed square wave is not really that fast - but it is unclear if it is an architecture issue or just configuration and/or software.  Flipping more than a couple of bits makes it even worse, as if adding just one simple line within the loop extends the loop by almost 7 micro seconds but it is not clear if this is a pin access artifact or slow code.

             

            I am not sure reserving pins is that important at this point - based on what I've seen with the Edison, between the I/O speed and the linux response, doing any type of micro controller work on the CPU is a losing game, unless you are doing simplistic or non-critical things like blinking LEDs;and configuring even a serial port or SPI port is a nightmare compared to most other micro-controllers I've worked with.  Next, I'm trying to figure out bandwidth between the MCU and CPU and ease of use.   I am really debating between giving up on it for back six months (by when docs will have hopefully caught up) or staying with it and make baby steps after hours of trial and error.  I guess as long as there is forward progress, I'll stick with it a bit longer.



            • 3. Re: MCU operation questions
              KurtE

              Personally I completely hear you!

               

              Actually the speeds that you mention here are pretty darn poor.  The main processor through memory mapped IO can get speeds maybe up to 1.4mhz. Fast GPIO Arduino board to logical IO pins on Breakout board?

               

              Also mentioned in another thread that the UART is limited to 115200 as the max?

               

              I started learning and working with the Edison as the Robot that I was waiting for from Trossen Robotics (HR-OS1) was going to use an Edison as it's main processor.  The beta version of the kit shipped to the 50 of us who preordered them.  During the last month or two before these beta units shipped, they also started supporting the RPI2, which is a nice little beast.  The beta units shipped with both processor boards.  Mine currently has the RPI2 in it.  I was adapting my PhantomX hexapod to use an Edison as it's main CPU, but I am currently in the process of converting it to an Odroid C1 and maybe then to Odroid XU3 lite.

               

              Note: I like the Edison's with the built in wifi and BT.  Also I appreciate some of the new stuff coming out, like support for sound over BT...   I was also excited when I saw that thy released support for the MCU.  The specs look interesting!  But then read the limitations like one thread, 10ms clock resolution, have to reboot to change anything...   Hopefully we will hear that an update is coming soon that will remove these limitations (and fix SPI...)

               

              I will keep an eye to see if you and others make some headway.

               

              Kurt

              • 4. Re: MCU operation questions
                Paul Bearne

                I think the device has the potential to be huge but i fear it may some way off. As you say i have also been getting some serious variance in IO speeds and am finding the new mcu is making it worse from a speed standpoint the improvement though is in the stability in my own application which is a health monitoring system the slower speeds are not a huge problem and the improved stability is great. The real drawback is the SPI or lack of as in my particular application almost all,the sensors use it. I'm sure that given time the Edison will do everything i need and its size is a real assist but as with any new device it usally rev 3 before all the problems are ironed out.

                • 5. Re: MCU operation questions
                  nniles

                  KurtE wrote:

                   

                  ...

                  But then read the limitations like one thread, 10ms clock resolution, have to reboot to change anything...   Hopefully we will hear that an update is coming soon that will remove these limitations (and fix SPI...)


                  Just FYI...

                   

                  If you look at the MCU API, there are both milli- and microsecond clocks (and hopefully they don't roll over at the same time).  Additionally, there are functions for both a 10 ms and a 1 us delay. 

                   

                  It would be interesting to see some statistics on the timing that can actually be achieved.

                   

                  Thanks,

                  • 6. Re: MCU operation questions
                    yp66

                    So here are some updates on MCU speeds and other observations.

                     

                    The following is a simple program that flips a bit.

                     

                    #include "mcu_api.h"

                    #include "mcu_errno.h"

                    void mcu_main()

                    {

                      gpio_setup(14, 1);

                      while (1)  {

                        gpio_write(14, 1);

                        gpio_write(14, 0);

                      }

                    }

                     

                     

                    asdf

                    • 7. Re: MCU operation questions
                      yp66

                      So here are some updates on MCU speeds and other observations.

                       

                      The following is a simple program that flips a bit.

                       

                      #include "mcu_api.h"

                      #include "mcu_errno.h"

                      void mcu_main()

                      {

                        gpio_setup(14, 1);

                        while (1)  {

                          gpio_write(14, 1);

                          gpio_write(14, 0);

                        }

                      }

                      It yields the following waveform

                      pin14.png

                       

                      Adding a delay in the loop as below

                        gpio_setup(14, 1);

                        while (1)  {

                          gpio_write(14, 1);

                          mcu_delay(5);

                          gpio_write(14, 0);

                        }

                      yields the following

                       

                      pin14-delay5.png

                      Note that the amount by which the pulse is delayed is way more than 5 micro seconds.  I would expect the need to add some calibration but it seems that there is quite a bit of overhead even on the busy-poll delay functions.

                       

                      Note the bit flipping program on pin 48:

                        gpio_setup(48, 1);

                        while (1)  {

                          gpio_write(48, 1);

                          gpio_write(48, 0);

                        }


                      pin48.png

                      Note that the delay is different than bit 14 (or 15).  The waveform looks different because I switched probes on the scope - that has nothing to do with the edison.


                      Finally, another interesting observation about the serial port.  At 115k it takes about 78 uSec to send out a character but when a physical UART is involved, it typically takes a fraction of that to buffer the characters to the UART so the program can continue one.  It seems the Edison MCU either waits for the transfer to complete or bit-bangs the serial port, which means the program is 'busy' for the duration of the send.


                      Relevant program:

                       

                        uart_setup(1, 115200);
                        gpio_setup(14, 1);


                        while (1)  {

                          gpio_write(14, 1);

                          mcu_delay(20);

                          gpio_write(14, 0);

                          uart_write(1, (unsigned char*)"01234567890123456789", 20);

                        }

                       

                      and the following is what we get (top waveform is the serial port output, bottom is pin 14):


                      pin14-delay20-uart20.png

                      Time between the down edge and the next up edge is 1.8 mS, so there is the overhead and the 1.56 mSec it takes to send out the data.  Also, the 20 uSec delay generates a pulse of 30 uSec.  Another issues, which is not apparent in the scope dumps is that the pulse width varies quite a bit, it gets as low as 10 uSec and as high as 32 uSec.  I suspect this has to do with the resolution of the underlying timer, but all in all, I think it will be very hard to do precise signaling even with the MCU.  In fact and pulse width control will have to be done with the PWM hardware which is pretty solid from what I've seen so far.


                      Hope that helps.


                      • 8. Re: MCU operation questions
                        Paul Bearne

                        The serial port probably is blocking synchronous mode as not using interrupts and with the limitation of only one thread no option to do anything else. I wonder what options the rots offers couldn't find much information by being an rtos you would think it has a mechanism for task sharing. This won't speed anything up but should eliminate waiting for a task to complete.

                        • 9. Re: MCU operation questions
                          KurtE

                          One thing I have been wondering about is does the MCU actually have any direct ability to control the IO pins, or is it always having to go through something like a device driver that is running as part of the main processor.  The reason I wonder this is looking at your diagram:

                          4335AAD2-4104-48BC-8F26-127EB1102AF8-imageId=78a88837-3b20-4f47-9cb5-0e56f795102e.png

                          It could easily imply that all of the devices are under the host cpu.

                           

                          Again it will be interesting to see if the MCU can achieve as fast preferably faster and more timing specific IO speeds than user mode programs on the host cpu.  Example could I develop an equivalent to SoftwareSerial library for it, that can reliably input or output on an IO pins(s), and what speed could I achieve?  Or if hardware SPI is never properly fixed, could I implement a software SPI, that could drive a TFT display?

                           

                          Time will tell.

                          • 10. Re: MCU operation questions
                            Paul Bearne

                            That's a good point KurtE , It is also possible that it is the other way around in that the IO is attached to the MCU core which was documented as being a Quark as used in the Galileo and that the Atom core has been accessing this all the time.

                             

                            As you say Time will tell.

                            • 11. Re: MCU operation questions
                              skvark

                              I did fast test with the MCU couple of days ago to see if it was capable of emulating i2c slave with software (skvark/Intel_Edison_mcu_i2c_slave · GitHub). It seems that it's not (disclaimer: my code could be wrong too). It detects the initial start condition (SDA low and SCL is high) but after that when it should read a byte in it gets stuck thinking that SCL is high. I think the MCU is not capable to sample the SCL fast enough via GPIO (tested with 400 KHz) and this makes me wonder too does the MCU actually have any direct ability to control the IO pins.

                              • 12. Re: MCU operation questions
                                yp66

                                I am seeing the same thing - there is no way to do low level bit-banging protocols with the MCU at its current state.  Without a reliable way to issue sub-microsecond level delays and flip an I/O port within a couple of assembly instructions, it will be very hard to do anything with it except treat it as another CPU. Maybe this is not the right forum for this, but Intel may consider working with Parallax and putting an 8-core propeller chip in place of the MCU -now that would be something!