Edison mraa_gpio_write is a lot slower than digitalWrite

[eclipse]

Edison mraa_gpio_write is a lot slower than digitalWrite

[arfoll]

We're aware of this and have memory mapped io support for gen1 Galileo
however we're not pleased with the amount of platform dependant code this
has caused to creap in. The advanced fptr is an attempt to solve this kind
of problem but we never got round to moving it off to there. A cleanup of
mraa.c and gpio.c is required before we can do it. The arduino code is
afaik GPL and copyrighted emutex so we're avoiding it and going from the
specs.

To be honest having 'slow' gpio has never really been a concern of libmraa
as myslef and tom both consider that bitbanging on non real time systems is
just wrong. Out of curiosity what is your use case?

The plan is to have this work in a branch initially so there will be ample
opportunity to contribute/discuss. Hold on, hopefully the first bits will
be in next week.
On 30 Oct 2014 14:14, "KurtE" [email protected] wrote:

I was doing some testing of the mraa_gpio_write to see the speed of it and
it currently is a lot slower than doing digitalWrite in the Arduino
environment. Something in the order of 19us versus .4us
More details with test cases and logic analyzer output up on the thread:
https://communities.intel.com/thread/56516

Note: looking through Arduino code, it is using a fast GPIO interface to
the PCI device. I may try to play with the MRAA code to implement, but if
someone beats me to it...

—
Reply to this email directly or view it on GitHub
#27.

[KurtE]

Again the main thing I have been playing with in these cases are some of the Adafruit TFT displays. Which I have sped up some, but compared to some other systems, run like snails. The main issue is with the SPI system, for some reason the system will not allow me to run at 8mhz and even with a output of a buffer there is about a 1.5us gap between the output of bytes, which is longer than the time it takes to output each byte... Then there is a significant delay with each SPI output call maybe a gap of something like: .16+ms, Then you add on the delays for when we have to update the CS pin as well as the DC pin, we end up with large gaps between bytes output like .13ms

Again the SPI issues are much more but every bit I can speed up is good.
To keep things in perspective, I have the same display on a Teensy 3.1 (Arm M4 running 96mhz), using optimized driver. When running the graphictest program speeds are very much different
Screen fill test Teensy: 280113, edison: 2368886
Text test: 19434 vs 1216942
Lines: 73328 vs 24516829
...
There are other reports as well from others talking about the speed difference running the exact same driver except change the SPI device name, being way slower than several other Arm based linux boxes...

For me, I am getting close to being acceptable output for what I will need, like maybe have some buttons and some scrollable text output, but would be nice to not be in some cases 300 times slower...

[arfoll]

OK so you should use the hardware chip select that should remove that
issue. Obviously mmaped io is still in the works reguardless.

We can try investigate on the 8mhz issue, at least we can see what the
limitations are.
On 30 Oct 2014 17:18, "KurtE" [email protected] wrote:

Again the main thing I have been playing with in these cases are some of
the Adafruit TFT displays. Which I have sped up some, but compared to some
other systems, run like snails. The main issue is with the SPI system, for
some reason the system will not allow me to run at 8mhz and even with a
output of a buffer there is about a 1.5us gap between the output of bytes,
which is longer than the time it takes to output each byte... Then there is
a significant delay with each SPI output call maybe a gap of something
like: .16+ms, Then you add on the delays for when we have to update the CS
pin as well as the DC pin, we end up with large gaps between bytes output
like .13ms

Again the SPI issues are much more but every bit I can speed up is good.
To keep things in perspective, I have the same display on a Teensy 3.1
(Arm M4 running 96mhz), using optimized driver. When running the
graphictest program speeds are very much different
Screen fill test Teensy: 280113, edison: 2368886
Text test: 19434 vs 1216942
Lines: 73328 vs 24516829
...
There are other reports as well from others talking about the speed
difference running the exact same driver except change the SPI device name,
being way slower than several other Arm based linux boxes...

For me, I am getting close to being acceptable output for what I will
need, like maybe have some buttons and some scrollable text output, but
would be nice to not be in some cases 300 times slower...

—
Reply to this email directly or view it on GitHub
#27 (comment)
.

[tingleby]

Hay could you try using IO10 as your CS.

Along with the latest mraa?
http://iotdk.intel.com/repos/1.1/intelgalactic/libmraa0_0.5.1.22_i586.ipk

Then you don't have to bother doing your own gpio for the CS. Let the kernel driver do its magic.

[KurtE]

I am not sure here about always assuming CS on pin 10, also if you do expose the hardware SPI CS pin, then we need additional support to properly handle it. Question is how much of it is in place in the SPIDEV driver.

I really don’t have any experience with the SPIDEV driver, but I do see that there is a member variable: cs_change
Which helps control when the CS changes or does not change. In many cases it does not really matter when the CS changes. But I do know from getting the read of data back from the ILI9341 display it is important in those cases. That is when you start up a read request, the device will continue to give you data as long as the CS is still low….

Currently in mraa spi interface I don’t see any logical control over this.

[KurtE]

Forgot to mention, also that for example with this device: http://www.adafruit.com/product/1651 (2.8” tft display), I actually have two (actually 3 if you count the SD card) different SPI devices on this one shield.

The first one the actual display uses CS=10 and DC=9,
The 2nd one is the touch sensor chip which is an STMPE610 SPI device with CS=8, luckily pretty slow speed needed for this one.
3rd is the SD card, which has a CS on pin 4… Don’t care about this one as would rather use SD card on the Edison itself…

[tingleby]

There is only one available hardware cs on the Edison arduino board. Realistically this means you should only have one spi device connected, to maintain sanity with the adc also on the same spi bus.

When speaking about cs_change, that is definitely something that needs to be added.

[KurtE]

Personally I think you need to be able to support both Hardware CS and Software controlled CS. As I mentioned I wish to support both the display as well as the touch controller. Yes it would be nice for the faster speed display if the hardware directly controlled it. Not as important with the touch controller as speed is not that much of an issue.

[arfoll]

Sure, however on edison + arduino board having software controlled CS may not end well due to the ADC being on there. On other platforms with a free spi bus that we can 'own' fully from userspace there is no such issue and using a software controlled CS arduino style is absolutely fine.

Of course mmap'd gpio is still in the work, check the 'mem' branch that @tingleby has started working on.

[KurtE]

However the current stuff, where the CS pin is toggled by the hardware on every byte completely breaks the ILI9341 driver as the underlying device is sensing the drop of the CS as being the end of a command or the like and stuff stopped working...

Also as you noticed and mentioned in the thread: https://communities.intel.com/thread/56279
I don't think the SPIDEV driver is currently setup to properly handle the cs_change field. I would suggest that until it does, that either MRAA does not setup to use pin 10 or there are calls to enable or disable it...

Thanks

[tingleby]

If you give the latest in the mem branch, You should get far better rates when doing writes. It will be pulled into master after more testing.

[KurtE]

Thanks, I will give it a try.

You may have seen that I am contemplating maybe adding a variant into the Arduino IDE to allow for the simple breakout board, where maybe all of the IO pins map the same as they do with MRAA.

So I was am trying to figure out how IO pins work with some of the other special pins, like #214 which for the Arduino board goes to a tristate. As I don't see this IO pin in the 70 pin connector I am assuming this is handles probably on the Arduino board, probably through I2C? Likewise I think the PU resistors in the range of something like 208-229 or thereabouts is again handled on the Arduino board.

But I noticed that the special function: mraa_intel_edison_gpio_mode_replace
is being used by both the Arduino board as well as the mini board has code like:
mraa_gpio_context pullup_e;
pullup_e = mraa_gpio_init_raw(pullup_map[dev->phy_pin]);
mraa_result_t sta = mraa_gpio_dir(pullup_e, MRAA_GPIO_IN);
And I believe the array pullup_map which defines the PU values for each of the Arduino IO pins is used for both boards. It only has 20 elements in it, so you will walk off the end if you use MRAA for some pin like #55...

Still trying to understand the mini board to see if there are special things I need to do, to get these pins to work. My guess is I need simplify the per pin tables to remove a lot of the entries...

[arfoll]

@KurtE Why not just get the arduino IDE to link against libmraa? Seems easier to me to do it that way and you'll be adding a bit of future proofing to your work :)

[arfoll]

@KurtE if you look at that function it only gets defined if you are using the arduino breakout. If you're on the miniboard that function will not be used as mraa_intel_edsion_miniboard will get called.

[KurtE]

Thanks, first my mistake on reading through the mraa code, I thought at first both boards defined the same replacement function for mode, but I now see that they are different.

As for IDE and libmraa, thought about that, but I don't believe that libmraa is included as part of the IDE, so would have to figure that out...

Also mainly doing this as an exercise to understand more what is being handled by the Edison Module and what is handled by the Arduino breakout board. At some point when Trossen Robotics comes out with their board for the Edison, I will want to understand how to interface to it... But that is some time in the future.
My goal for now is to make at least simple sketches work with the IDE and mini breakout board.
Like:
pinMode(55, OUTPUT);
digitalWrite(55, LOW);
...

[KurtE]

Quick update: I tried out the mem branch on my Arduino board and at first I did not see any speedups. Then I noticed that there was a new call to enable the memory mapped mode for a pin, so I modified my test program to take two IO pins. One it keeps slow and the other fast, I then loop 5 times toggling each pin high and low so you can see the differences.

I uploaded a Logic analyzer picture showing the differences up on the thread: https://communities.intel.com/thread/56516

[arfoll]

@KurtE sure it's not included but it's easy enough to build it in with yocto, I'd say it's probably easier to do that than modify the arduino code to include support. You could probably just add most of the files to their build system and build just a mini layer to bind the Wire API to mraa.

[KurtE]

For the fun of it, I did do a version of your delta for the mem branch, where I precompute the starting memory address for a specific pin, instead of having to do divides and multiplies for each usage, likewise computed mask.

On my write test it does show a little speedup… maybe something like .26us goes to maybe on average .245…

Also when I was doing it, I think there is an issue in the function mraa_intel_edison_mmap_setup. When you decide to turn a memory mapped pin back to a non memory mapped pin, you decrement a counter mmap_count and if it goes down to zero you do something, but did not see anywhere you incremented it. Think it should be at bottom of the function.

In case you wish to see my changes, I uploaded them to my fork of the library (kurte).

Kurt

[tingleby]

Ah yes, I missed the increment on the counter.

When I tried it on one pin with a static offset calculated I didn't notice any reasonable increase.