Your project looks really great!
Regarding your DMA question, I don't have details about it, however there is a thread taking about a similar question. Here is the link, it might be interesting for you: Re: is DMA available on Edison, also which CPU datasheet for reference. I will try to investigate about DMA and if I am able to find some useful information I will post it here.
About the second release of the Edison software, it is planned for the end of year, however we can't disclose further details about it.
Thanks for the link re DMA and indication on the next Kernel release, much appreciated!
Just to clarify, the project is not to get DOOM running (as much as I would like to make the next PS Vita) but I do need to be able to render to the display at a reasonable rate hence
the use of a fairly intensive application like DOOM
I was really after clarification on the SPI speeds issues I'm experiencing (capped at 6.25Mhz, no DMA etc) and if they were real issues as such or was it down do something I was ****?
Judging from the work KurtE has done on his projects (albeit through MRAA from what I can tell) it seems that there are indeed issues with SPI in general.
So just three things I need answered if possible.
1) Can you confirm if DMA is enabled for the SPI channel or is it bit banged (I seen references to SPI bit banged functionality in the kernel but have not investigated further.)
2) What is the maximum speed the SPI bus it can be set to?
3) Are there issues calling dmam_alloc_coherent() from a loadable module (this is what FBTFT does when DMA enabled)
I came across a raft of QUIRKS set for the Intel platform but its hard to follow to be honest
Cheers and thanks for any help you can give.
Thanks for the feed back, I appreciate that!
Regarding the steps involved :
I have developed an entire build environment called Velox that allows users to create projects (products) based on what
ever Linux and MCU platform they are using.
Velox was designed as a hybrid build environment supporting not only Linux based targets but also microcontroller
targets since most of the work I have done in the past has pretty much always contains a product based on a design
that had multiple CPU's of various types involved. I was always annoyed that the code base/repos for the MCU's
was nearly always somewhere else and all the Linux build contained was a binary blob for the MCU target.
It supports developing code right within the environment too so everything is revision controlled and traceable.
Bootloader, Kernel, Busybox, filesystem (with a dose of supporting packages X11, GTK, QT, Networking etc) are built
from scratch and a deployable tarball is created that can be used. So far I can support Beaglebone, BeagleBoneblack,
AM335X EVM, Edison, RPi and soon the new CI20 from the Imagination guys. It also supports IoT type development like
Contiki and ChibiOS, again because I wanted a single repo for all my development. Linux target wise it supports ARM,
MIPS, PPC, X86 but I guess most Linux targets could be added. The idea is that you clone the master repo and add
your specifics to a proprietary directory. Any changes to the core can easily be pulled in.
Your MRAA is supported too but I don't use it yet
Is it any better that Buildroot, Yocto and the other environments? No, but I certainty found it useful!
Is it any good for developing user code? It's OK, currently based on CMAKE and can build libraries, exes, and KO's so
works for me! The idea is to have build environment and code development for all CPU targets in one place..
Anyway enough of the blurb!!!
The modifications I made where mainly to the 3.10.17 Kernel (after upstream-edsion applied) to get it to compile out of
Yocto and fix (get working) loadable SPI based device drivers (well FBTFT anyhow). I haven't created patches for
anything yet (since its a complete hack) but I have attached the modified files for the kernel and the modified source
for the FBTFT for adafruit2.8, FT6x06 touch driver and a script I launch at startup to configure the relevant pins.
Again the issue I'm seeing is really around lack of DMA support and general clocking speeds of the SPI device. I was
using DOOM as a heavy weight test, but Ilixi/DirectFB and Q5.3 are all pretty slow too.
Also, if DMA is enabled in FBTFT it fails to alloc the memory (since its mapped to the SPI device I guess).
The script as mentioned sets the pins and loads the modules as below :
modprobe fbtft dma=0
modprobe fbtft_device name=adafruit28_edison cs=1 gpios=dc:183 busnum=5 fps=20 rotate=90
FBTFT is checkout at revision fcc562e1358e0065b27f382c22b0647670edce5f and I just copy over fbtft_device.c before compile.
It's compiled out of tree too hence the mods to Makefile to pass in EXTRA_CFLAGS (-DFB_TFT_EDISON)
There are also some pre-requests for the kernel config to get it to compile out of tree so I have attached my defconfig
If you are able to get FBTFT to work and see what I'm seeing then what would be great!
I am trying to get an SPI display to work as well. While initially I thought that I could get by without DMA, the transfer rate is horrific and completely unsuitable for the task at hand.
My 'go-to' right now for IoT development is the Aria G25. While it is slower and has less RAM, it obliterates the Edison when it comes to SPI performance. I remain hopeful that a future kernel release will address the SPI/DMA issue so I can migrate my projects over to the intel hardware.
The Aria G25 looks great but as you said it's performance/spec compared to Edison is not comparable (albeit blowing Edison out of the water DMA/SPI wise)
I'm waiting on the CI20 from Imagination Technologies as a back up plan but I too remain hopeful that a new Intel Kernel will sort it. Time will tell I guess!
As a side note I have QT5.3 using fbdev up and running and wrote a small app but the performance is nasty! The screen takes about 2/3 of a second to refresh when switching tabs
and the scan line is clearly visible. The Connman/DBUS and QT networking stack performance is great however!
I was hopeful that the kernel update that was promised by end of year would address the issue, but i guess they meant end of 2015
I need to find a way to get the fully patched linux source tree over to my edison so I can do native compiles and change the kernel up as needed. The process right now is quite convoluted and painful... plus reliance upon a Ubuntu system to bake the image royally sucks...
@smaguire, thanks for the post. MRAA is something i have wanted to get going on the edison. I have put some serious time in diagnosing the SPI. My conclusion is the lack of DMA support is the root cause. It's been a long time since i have visited the forums, as (sadly) I have lost hope for the edison. It's a shame because I loved everything about it but the firmware.
I can only hope they will put more priority to this product.
To change the subject a bit and I know I should not but others may find this useful.
Since then I have jumped on the ODROID C1 by hardkernel. In a nut shell its the best thing out there IMHO.
You can get it from USA distro here:
jwestervelt, I was looking forward to it too! My development on the graphics front has stalled unfortunately so the sooner the new Intel Kernel is released the better. If it fixes my issue then great news otherwise I have too look else where
I compile the Kernel on my host machine (Ubuntu) but I guess there are no reason it can't be done natively. I have attached the crosstool config I used to build my compiler if you fancy having a go at compiling without Yocto.
I attached my default config and patch etc in my earlier post too, so use that to get it to compile the way I did it. You need to apply the upstream-edison patch to 3.10.17 vanilla kernel first though!
crosstool.config.zip 3.5 K
I am also looking forward to new kernel, especially if they have addressed some of the SPI issues.
Stewart, your display looks pretty nice. Are you using some publicly available library for these or is this part of your own project/products? Currently I am rolling my own stuff, like I have a scrolling text box, which is pretty crude. May want to introduce scrollbar and then build into a listbox... Again your stuff looks pretty nice.
I'm just using QT5.3 for the with an FBDEV back end. I use QT Creator to generate the UI files that I can include in my CMAKE process. CMAKE includes a nice QT wrapper to generate
the header files with all the GUI declarations and implementations. Out pops the exe and I just upload it. There are a few environment variables to set to force QT to use FBDEV and a few
more to get tslib and QT input method to play nice together. I also cross compile QT5.3 from scratch.
I started off using my own stuff but I was re-inventing the wheel (badly at that lol) so Ilixi/DirectFB or QT5 where the obvious choice for me since I had FBTFT working.
It also reinforced the fact SPI transfer was woeful since both perform badly.
I don't know if Yocto can use QT5 (I'm sure it can) but thats the route I would go if its not too complicated to get it working in Yocto.
QT5 also has a dose of other functionality including Bearer management for networking etc, it really is a fantastic platform!
Almost seems like Intel are testing the water a bit with this release of Edison just to see what the uptake is like. Given the silicon appears to have fallen of the Tablet/Phone
production line (failed GPU blocks maybe??) they probably have nothing to loose. I still think it has big potential as a Linux platform, not so convinced about MRAA or any of that user space
implementation but I understand their target market going after the Arduino market/development guys.
The Odroid kit is brilliant and the Device Tree based Linux kernel is a lot easier to use than the classic BSP implementations (once you get your head around it). I've done four or so different products with the same ARM kernel but different device tree definitions for Cortex A8 based kit although at the start I hated it lol.
This kit here with the Samsung Exynos5422 is a monster platform, if only I had more time to play!
The Edison definitely uses less power than the ODroid boards, but then again, it lacks functional SPI with DMA. I have a Samsung ARM based Chromebook2, and that is effectively the same as the XU3. Sadly I cannot get both 8-core HMP and Mali acceleration at the same time. The ODroid boards can get Mali acceleration with HMP because they are using an ancient 3.10 kernel that Linaro is working on, but the device tree files for this Chromebook do not exist for such an old kernel. I expect that things will get sorted shortly, but really... 3.10 kernel?? Yuck. Worse yet, Linaro has a track record of dragging their feet. The ODroid is going to be hobbled by this since they are not doing their own kernel development.