In late September I traveled up to Cambridge, to attend an ARM course hosted by ST Microelectronics as a vehicle to showcase their new Cortex M7 microcontroller.
The course described in detail some of the key features of the M7 architecture, and how it's performance has been enhanced over the existing M4. In the afternoon there were practical introductions to some of its DSP capabilities. And of course, the main reason for going was to get a free STM32F7 Discovery board - worth about £40.
The F7 Discovery board comes with a load of hardware bundled in, notably a 4.3" capacitive touchscreen, ethernet, stereo audio, microSD card, camera interface, dual MEMS microphones - for directional sound analysis, and external 8Mbyte SDRAM and Flash ( to demonstrate code execution from various external memory devices).
I had put the board to one side for a couple of months, whilst waiting for mbed to support this feature rich board. Now at last, mbed has stable support - and I can begin experimentation.
As with all mbed platforms, there are a few code examples supplied to get you started - in this case - writing text and graphics to the LCD, and reading the capacitive touchscreen. The examples were easy to follow, and easy to modify to suit my own purposes.
I decided that it would be interesting to run my J1 Simulation on the Discovery board, by way of benchmarking it. If the J1 Sim ran reasonably quickly on this extremely portable platform then it would be useful to try out some of my J1 assembler development on it - written in mbed C++.
The benchmark was reasonable - about 4.65 million J1 instructions per second. This should be quite fast enough for now to develop the next stage of the project.
LCD and VGA Dispays
Both the STM32F42x M4 and the STM32F7xx M7 processors contain an LCD controller. This generates the RGB parallel 8 bit video data and the horizontal and vertical sync signals for most modern LCD displays. The sync generators are entirely programmable, and will handle display resolutions of up to 1024 x 768.
It is a fairly trivial matter to combine the digital data lines using a weighted value resistor network - which acts as a simple D to A converter and allows an analogue video signal to be recreated. This is exactly what VGA monitors require - so it should be possible to get the M7 to generate reasonaby good graphics on a flat screen monitor. As much as I like the touchscreen LCD - text on it is a little small.
This post to a forum confirmed the technique is valid - by modifying a '429 Discovery board
To put this plan into action, I will need to create another breakout - board, in order to get at the necessary signals - unfortunately the F7 Discovery uses a BGA packaged processor - and virtually none of the required signals are accessible.
The board can use either a STM32F439 or a STM32F746 - as they are pin identical. There should be at least 2MB of fully static SRAM and a block of SDRAM.
The new breakout board will have a modified Arduino MEGA foortprint - to allow it to be compatible with my Papilio Duo and Computing shield hardware. These provide PS2 and VGA break-out connectors.
An ARM/FPGA Duo ?
Since getting my Papilio Duo FPGA boards earlier this year, it has opened up experimentation with computer hardware and softcore processors.
One of my goals is to put an FPGA and a reasonably powerful ARM Cortex M7 processor together on the same pcb. This will allow exploration of the FPGA hardware - but with a fairly standard ARM to provide system hosting. It is likely that they will share some dual ported RAM.
For debugging the ARM will provide a user interface - allowing keyboard, mouse, USB and ethernet interfaces. Code can be simulated at about 1/30th of real speed on the ARM, before being ported across to the FPGA. This is going to be a challenging brain stretching project.
The intention is to create a workstation-like environment, with 1024 x 768 graphics on a large screen monitor.
Prototyping
It should be possible to prototype a lot of this before having to commit to a lot of new hardware.
The 100 pin STM32F746 BOB board allows most of the RGB lines to be accessed - enough to allow a full 8 bits of green, and 6 bits of each Red and Blue to be connected. This will at least allow the system timing to be tested on a VGA monitor. The Computing shield has a break off section which allows VGA combination of 4 bit RGB signals.
The STM32F746 has 320K of SRAM - and if we are using 4 bits of each RGB - then we cannot display much of a picture. Instead - for experimentation - pack up the RGB as 3:3:2 into a single byte - that would then allow a 640 x 480 display.
A lot of work has already been done in getting microcontrollers to output video. Cliffle's Blog is a good place to start.
A Graphics Co-Processor?
The idea of offloading the burden of driving a video display to a custom graphic processor has been around since the earliest days of the PC. Traditionally the graphics system would involve a frame buffer RAM, into which the cpu would paint the pixels required for the video image. The cpu would usually use the vertical blanking period (about 50 blanked lines or 3.2mS) to update the data in the frame buffer.
Loading the frame buffer with the data for text characters and shapes is computationally intensive - and if it could be offloaded to a special graphics engine, then it frees up huge resources in the cpu. The other way of looking at this, is that a much slower, simpler cpu could be used, if it no longer has the graphics overhead.
This is the approach adopted by FTDI, who have launched a series of embedded video engine (EVE) ICs - which are finding there way into embedded systems. EVE does not just handle the video for the LCD, it also has a touchscreen controller interface and an audio generator - which a range of pre-recorded sounds.
EVE treats all the items that go to make up the video display as objects. There are numerous in-built objects - such as buttons and sliders - that go up to making a modern GUI. The host processor need only built up a display list of the objects that it wants to display, in terms of size, position, colour and other attributes - and this list is passed to the EVE device, whenever the mcu needs to update the display.
As the display list is a fraction of the size of the objects that it represents, it means that it takes very few resources to generate and update it. This means that a simple 8 bit microcontroller can easily generate a display list for a very slick looking GUI. FTDI have emphasised this capability - by basing there development boards around the ubiquitous ATmega328p - commonly known as Arduino.
There are several key advantages to using this approach:
The EVE chips may be purchased in 1 off from Farnell - for about £5.
No comments:
Post a Comment