1 2 Previous Next 20 Replies Latest reply on Mar 9, 2016 5:14 PM by nelfata

    DOOM on Edison with adafruit2.8 TFT

    smaguire

      Hi All

       

      I have been playing with the Edison and the Arduino breakout board over the last few weeks and have to say its a nice piece of kit!

       

      I don't use the Yocto build system so have compiled kernel, boot loader and file system from source and all seems to work well. 

      I also don't use the user space MRAA libraries either mainly in an attempt to achieve faster SPI/I2C communications.

      All pin muxing, exporting gpio for SPI/I2C etc is done from a simple script at bootup (based on looking at the code from MRAA)

       

      I have been able to get FBTFT running as a loadable module on the adafruit28 (with a few hacks around GPF_ATOMIC flags and MAX SPI buffer size in Intel source)

      capacitive screen and also touch control using a native i2c kernel module (ft6x06) and tslib users pace libraries and for fun fired up DOOM to test the throughput (picture attached)

       

      However, as I have seen other members mention (KurtE) there appear to be serious issues with throughput on the SPI bus and more than likely

      DMA problems too. i.e. the lack of it!  The refresh rate is pretty bad and although I'm not expecting 3D accelerated graphics I have done similar on the BBB

      and it renders in SW just fine.  I also have iIixi (great toolkit b.t.w) on top of DirectFB running but again painfully slow.

       

      I know that FTTFT has the ability to use DMA buffers but enabling that causes the module to fail to allocate. Again DMA issues in the Kernel....

       

      So before I dig any further into the Intel Kernel source am I right in assuming that the Kernel as it stands (3.10.17) does not support DMA allocation or DMA SPI transfers?

       

      Just to end, I have seen that there are plans to release a newer version of the Kernel with Edison support before the end of the year so are Intel actively looking at DMA allocation and SPI

      speed issues/DMA transfer support for the next release?

       

      Cheers

      Stew

       

      DSC_0014.JPG

        • 1. Re: DOOM on Edison with adafruit2.8 TFT
          DiegoV_Intel

          Hi smaguire,

           

          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.

           

          Regards,

          Diego.

          • 2. Re: DOOM on Edison with adafruit2.8 TFT
            smaguire

            Hi Diego

             

            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.

            Stew

            • 3. Re: DOOM on Edison with adafruit2.8 TFT
              B.

              Really nice work so far Stew, would definitely like to follow your work on this.  Any chance you could share the steps you took to get this far or give us a fork if fbtft on github?

              • 4. Re: DOOM on Edison with adafruit2.8 TFT
                smaguire

                Hi B.

                 

                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!

                 

                 

                Thanks

                Stew

                • 5. Re: DOOM on Edison with adafruit2.8 TFT
                  jwestervelt

                  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. 

                  • 6. Re: DOOM on Edison with adafruit2.8 TFT
                    smaguire

                    Hi Jwestervelt

                     

                    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!


                    Stew


                    DSC_0016.JPG

                    • 7. Re: DOOM on Edison with adafruit2.8 TFT
                      jwestervelt

                      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...

                      • 8. Re: DOOM on Edison with adafruit2.8 TFT
                        mikemoy

                        @, 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.

                        http://www.hardkernel.com/main/products/prdt_info.php?g_code=G141578608433

                         

                        You can get it from USA distro here:

                        http://ameridroid.com/products/odroid-c1

                        • 9. Re: DOOM on Edison with adafruit2.8 TFT
                          smaguire

                          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!

                           

                          Stew

                          • 10. Re: DOOM on Edison with adafruit2.8 TFT
                            KurtE

                            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.

                             

                            Kurt

                            • 11. Re: DOOM on Edison with adafruit2.8 TFT
                              smaguire

                              Hi KurtE

                               

                              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!

                               

                              Stew

                              • 12. Re: DOOM on Edison with adafruit2.8 TFT
                                smaguire

                                mikemoy

                                 

                                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!

                                 

                                ODROID | Hardkernel

                                 

                                Stew

                                • 13. Re: DOOM on Edison with adafruit2.8 TFT
                                  mikemoy

                                  Stew, I think you hit the nail on the head here.

                                   

                                  As far as Odroid goes, I dont have the XU3, but do have the U2 & C1.  The C1 has been the best thing i have played with in a long time.

                                  • 14. Re: DOOM on Edison with adafruit2.8 TFT
                                    jwestervelt

                                    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.

                                    1 2 Previous Next