The system is designed to connect to a computer via USB and allow an application on the computer to send data to the screen to be displayed. The computer will run a specialized software that allows other APIs to link in and request to display data at certain times. The screen is rather large and includes 4 function buttons for use in applications, and an application switcher button.
| Front view | |
The microcontroller being used for this project is an MKL16Z32VFM4 from Freescale. It is a Kinetis L series ARM Cortex-M0 device with all of the features required for this project. It is running a custom firmware which awaits the computer to send messages such as send graphics to screen, or send text to screen, or a no operation command to gather status information like button presses.
| Schematic | PCB | |
The microcontroller is linked through a TXB0108 (to convert voltage levels of the signal) to a Newhaven Displays 240 x 128 LCD screen (NHD-240128WG-ATMI-VZ). This screen was somewhat easy to use with its built.in RA6963 controller. It supports two customizable fonts that are planned on being used in the final version to load whatever a program wishes to load and use.
The microcontroller communicates to the computer through a Cypress USB-Serial Single-Channel (UART/I2C/SPI) Bridge (CY7C65211). This is a USB bridge that can do UART, I2C, and SPI with minimal configuration. We operate the bridge in USB-to-SPI mode, and we utilize the full-duplex nature of the communication. (More on this part in the final thoughts section) The Five buttons (4 function buttons and 1 program control button) are linked in series and we use resisters and an ADC to sense which button is pressed at any one time. The four function buttons will be used to inform the program of user input. Meanwhile the 5th button (the program control button) is used to change what program is controlling the display.
The rest of the board contains connectors for programming and USB.
The software currently consists of a library that includes a low-level wrapper for simple functions to be sent through the Cypress API, and a wrapper for that class which represents this device and all of the functions involved in it.
The software is also built with a windows service that will run constantly and process signals from the device. It will also allow other dlls to link to it and be switched between when the 5th button is used. Every draw cycle, the service will allow the controlling dll to send whatever changes it needs to send to the screen, and it will inform the program of any button press.
The software is currently not implemented as the CyUSB.NET libraries are posing some issue. The current course of action is updating it to use the older C++ version of the library and wrapping it for use in c#. I will hopefully have an update when this is complete.
I had hoped to make this device within the semester and have it functioning. It ended up being that the LCD screen and the USB communication were the sticking points.
The LCD screen took much longer to understand than I thought it would. This seems to be from the slightly roundabout documentation that Newhaven posted from RAio, and RAio.s original documentation. I ended up getting help with this and figuring it out.
However the big issue in the room is trying to use C# (or any .NET language) with the Cypress USB Bridge. I tried several approaches. In the past Dr. Bezrukov had used the C++ version of the library to great success. The library does SPI transfers with one call. After opening the device calling CySpiReadWrite(handle, readbuffer, writebuffer, timeout) handles the entire transfer and returns a status value. This library works amazingly. However because of all of the work in connecting that requires structs and more advanced data types than data-types, a port of this library using data marshaling is out of scope for me currently.
The other way to use the library is through the CYusb library which Cypress has provided a .NET version of. These libraries come with the additional positive of working with ANY Cypress USB2.0 or better device. There is an issue, the libraries are well documented function wise, and it is easy enough to figure out what a function does. The issue comes in when you use a Cypress bridge that has multiple protocols. In the end I figured out that the device could be programed with an external configuration device to expose the spi interface. All of this is done over the Cypress Control interface which is seemingly not documented. Once this was figured out I got the data transfer working with more difficulty. This version of the library has two calls (to be more generic). As the SPI interface exposes three other interfaces, a read interface, a write interface, and an interrupt interface. I still have no clue what the interrupt interface does as it seems to never activate. The general procedure to read and write some data is to write some data out equal to max(data written, data you need to read). Here we have our first issue: you need to know how much data you are receiving if you are operating in master mode. This becomes problematic. After you write a separate call to read data from the read interface is required.
I have also used the SiLabs CP2112. It is a simple device that comes in SPI, UART, IC2 and other versions (the CP2112 model is specifically for IC2). The library for this device operates in a simple way comparable to the C++ Cypress library; however they are for all languages and include headers for C++, C, and C# among others. It should be noted that there are a few issues technically with the API, however I have been quoted multiple times during this project saying, "The Cypress libraries are good but I can't. figure out why they don't work; at least with the SiLabs libraries I know exactly how they don't work".
In the end if I could redesign the project I would most likely end up not using the Cypress USB bridge again. It works, and extremely well if you are coding in C++; but the C# libraries are simply not the best.
I plan on continuing what I can with this project. Because a redesign isn't in the plan I will be carefully making a C++ wrapper for the library to contain the lower-level operations that directly use the libraries such that they can be linked in to the C# program.
Last modified:Mon, Jan 23, 2023.