element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Moto Mods
  • Products
  • Manufacturers
  • Moto Mods
  • More
  • Cancel
Moto Mods
Blog Porting the PaPiRus HAT to the MDK
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Moto Mods to participate - click to join for free!
  • Share
  • More
  • Cancel
Group Actions
  • Group RSS
  • More
  • Cancel
Engagement
  • Author Author: freund
  • Date Created: 11 Sep 2016 11:22 PM Date Created
  • Views 2005 views
  • Likes 2 likes
  • Comments 8 comments
  • eink
  • mdk
Related
Recommended

Porting the PaPiRus HAT to the MDK

freund
freund
11 Sep 2016

At the end of July, a couple of Motorola software engineers formed a Hackathon team to bring up the PaPiRus E-Ink display on a MotoZ phone using the new Mods Development Kit.  Most of the work consisted of porting the existing open-source display driver (epd.c) from the Raspberry Pi running Linux to the MDK running NuttX.  Although our team didn't have much prior hardware experience, we expected the porting effort should be relatively straight-forward since the MDK environment is designed to facilitate porting hardware and software from other platforms by making use of common hardware interfaces such as I2C, SPI and GPIO, and through it's RPi HAT Adapter card which aligns pins from RPi's GPIO to the MDK.

 

During the 2.5 day event (working late nights), the team was just able to bring up the display and draw an image.  After completing the work, the team artificially diced up the code changes into a series of 8 commits posted to this MDK epd Github link which roughly align to milestones described in subsequent posts below.  But I want to emphasize that this project was a learning experience for us, and was just done to the level of quality of a rushed hackathon project image. 

 

We hope this example demonstrates that without much experience, any software developer should be able to select a random hardware project from Raspberry Pi or other platforms and get them working on Motorola phones with relatively low effort.  And also hopefully inspire someone to continue work on this MDK PaPiRus driver.

 

-Jason Freund

Motorola Mobility

 

image

  • Sign in to reply
  • freund
    freund over 8 years ago

    Commit #8: “Shows cat and display image after clear”

    • epd.spi.h: 53: SPI_send_image() not used
    • Epd.c:202: epd->middle_scan=true: probably not needed as that’s the default value for the display firmware
    • Commenting: frame_data_repeat().  This code is needed but we couldn’t get the full pipeline of drawing to work according to spec.  So our compromise was to feed inverted images to the draw_image function and skip the final inversion step.
    • Epd.c: has lots of dead commented code that’s not needed
    • Epd_spi.c:135 up_udelay(500): RPi has a more powerful CPU than our MuC.  Since we spend more time sending the image data, we need to dial down the delay beetween bytes.  We tuned this value to optimize performance but still get the send to work
    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • freund
    freund over 8 years ago

    Commit #7: “Finally clear display routine works”.

     

    Get SPI driver to compile and clear works.

    • MDK’s spi_send API should be able to support bi directional communication with a separate R and W buffer, but we couldn’t get it working, so in epd_spi.h:50, we made use of the MDK’s spi_send routine’s return value to support the R/W bi-directional communication.
    • Epd.c:41 needed to use mdk’s sleep functions included by mdk.h.
    • Epd.c:350: Delay_ms(1) is needed before every spi_send.  It’s part of the PD protocol needed to initialize the control signal for SPI.  This was found on p.15 of the PD spec. Under the “/cs” graph.
    • Stm32_spi.c: 1444: RPi’s epd_spi utility code did not clear the LSBFIRST bit.  The MDK doesn’t support configuration of those clear bits, so we had no choice but to edit the MDK’s SPI code to NOT clear that bit.
    • Stm32_cpi.c: spi_portinitialize1() is dead code, should be ignored
    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • freund
    freund over 8 years ago

    Commit #6: “Change the epd driver so now we are able to read cod version and it is 2” 

     

    Get epd to compile.  Display version code can successfully read the HW, but nothing else works.

    • Uploading stm32_spi.c from MDK with no modification yet
    • Epd.c:322: Add code to read cog_id which returns a value of 2 (ie, the 2.0” display)
    • 364: Support clearing display by breaking 2 byte send commands into 1 byte
    • 339: Port “Check breakage” (of display HW) code by breaking 2 bytes into 1 byte send commands
    • Note that PD spec indicates that SPI_SELECT must be called before and after each Send
    • Epd_test.c:55 changing reset_pin direction to 1 is fixing our own bug
    • Spi.c was renamed to epd_spi.c.  All ioctl from RPi was changed to SPI_SEND, for example:

    if (-1 == ioctl(spi->fd, SPI_IOC_MESSAGE(1), transfer_buffer)) {ToSPI_SNDBLOCK(spi, buffer, length);This wasn’t captured by the github change diff because the file was renamed.

    • SPI_create for RPi uses fopen, was changed to spi_create which calls up_spiintialize(1) // SPI1
    • Set_spi_mode from rPi used icotls sets 3 values.  Epd_spi.c accomplishes that on line 162 with:
      • SPI_SETMODE(spi,in_mode);
      • SPI_SETBITS(spi,8);
      • SPI_SETFREQUENCY(spi,EPD_SPI_BPS);
    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • freund
    freund over 8 years ago

    Commit #5: “Port the RaspberryPi driver to adapt to Mod HDK”. 

     

    Compile epd driver and test code.

    • map SPI structure to MDK library
    • Make use of remapped GPI r/w API’s
    • Update include path for epd.h to point to compile time arch/board folder
    • Nuttx C compiler doesn’t like variables to be declared inside of another statement such as a for loop.  Similarly, the compiler got confused about re-using name of variable in nested scope on epd.c:739
    • Change RPi warn/error logging to MDK’s given dbg log function
    • Epd_test.c: strip down to 1 test case (clear screen)
    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • freund
    freund over 8 years ago

    Commit #4: “Configure GPIO’s in the HDK and test it using RAW command and LEDs”. 

     

    Test code to verify that GPIO pins can be turned on and off using a Raw command

    • Gpio_test.h: original epd source
    • Mods.h: Add pin definitions.
    • Gpio_test.c: Remap gpio function names
    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
>
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube