Posts Tagged ‘NIOSII’

DMX lightcontrol using FPGA and RS-232 to DMX converter (part 2)

February 22nd, 2011 No comments

The last month I’ve been working hard on my last assignment for my Technical Information Sciences education. The project consists of a DMX light controller built on a Altera DE2 board. It uses an RS-232 to DMX converter so I don’t need to deal with the actual DMX protocol. I focused on building a user interface wherein the user will be able to add devices and connect devices to built in chasers. The project also helps me improving my C programming skills. I found out that programming in C requires a completely different mindset compared to the programming languages I’m more familiar with. In Java, Perl or PHP, the languages I’ve more experience with, I don’t need to deal with memory allocation for example. Apart from Perl I never used pointers in my software. In C I needed pointers many times. It’s a completely different experience, but I enjoy it. The only things I needed was a good C reference manual, a lot of coffee and a quiet room to study. An important pitfall which I had to avoid is “Going too fast and willing to make things too fancy”. This makes the software too complex for my, still developing C skills. I had to keep it simple. Take it easy, learn from others and do small assignments and tests before implementing functionality in the final product.

Now the project is almost finished. I enjoyed developing my C programming skills as well as working with the Altera DE2 board and DMX controlled lights. Like I mentioned in my first post about this project, setting up a proper NIOSII core was a real challenge. I’m glad that I managed to get it working.

Like I said, the software works with devices and chasers. These objects are stored in arrays of structs. A device has a name, start address and a number of channels. Chasers consist of a name, active flag, reference to devices used by the chaser (array of device objects) and a number of required devices. The chasers itself are defined and initialized in code. It was simply too much work to build a system wherein the user can build his own chasers. However, the system can easily be expanded by such functionality. Devices can be added by the user. The menu provide this option by letting the user enter a device name, start address and number of channels. Devices can be connected to chasers in the ‘Chaser’ menu.

I can probably tell a lot more about the setup and code behind the system, but I thing a short video is a much better solution. Sorry for the bad quality. Phone camera…

I called the system ‘DMX Master’. There’s no reason for that other than that I liked it :). The pushbuttons are located on the right part of the DE2 board. C stands for return, M for menu or enter and the < and > buttons… well that’s obvious. Scrolling through the menu only works from right to left. I didn’t had enough time to implement the other direction as well. The most left switch is the reset switch. This one should be enabled at all time. 4 Chasers are built in at the moment which can be set by enabling switches 1 to 4. The fifth switch starts the selected chaser.

Post to Twitter

Categories: Electronica, Technologie Tags: , , , , , ,

SDRAM panic

January 31st, 2011 No comments

Today I continued with my FPGA-DMX controller project. I already made good progress as you could have read in my previous post. The next challenge was to get the SDRAM up and running. The Altera DE2 board, which I use for this project, has also 512K of SRAM which is much faster than DRAM. The SRAM already works but is too small to hold my light control data. The SDRAM on the DE2 board is 8MB, which should be sufficient. After finishing my application logic using the SDRAM the next step is to use Flash or SD-card as memory for the light controller data.

Sounds all very exciting, but first I had to make sure the SDRAM does actually work. After some reading about the IP-CORE SDRAM controller and the chip itself I wrote a small test setup containing a NIOS2 core and a PLL for the clock phase conversion. The PLL was set at -54 degrees, which should result in a 3ns delay on the system clock. In another (lost the link) manual I found out that it is safer to put your normal clock also through the PLL module with just a 0 degree phase shift. This is because the PLL it selves also takes some time which can result in wrong phase shift.

The picture above shows the NIOS system and the PLL. Next step is to write an application to test the SDRAM. Write data to the SDRAM and read it back. report data mismatches to an error counter. This sounds pretty easy. Setting up this code was indeed. See the example below:

#include <stdio.h>
#include <unistd.h>
#include "system.h"
#include "alt_types.h"
#include "altera_avalon_pio_regs.h"

/* Memory constants */
#define SDRAM_MAX_WORDS 100000

alt_u32 test_sdram( void ) {
	alt_u32 i;
	alt_u32 errors = 0;
	alt_u32 *buffer = (alt_u32 *)SDRAM_BASE;
	/* Write data to SDRAM */
	for( i = 0; i < SDRAM_MAX_WORDS; i++ ) {
		printf("SET row: %d\n", i);
		buffer[i] = i + 1000000;
	/* Check output from SDRAM */
	for( i = 0; i < SDRAM_MAX_WORDS; i++ ) {
		printf("GET row: %d\n", i);

		if( buffer[i] != (i+1000000) )
	return( errors );

int main( void ) {
	alt_u32 ret_val;
	printf( "Welcome...\n" );
	printf("Testing SDRAM\n" );

	ret_val = test_sdram();
	printf("...Completed with %d Errors.\n", ret_val );


When I ran this code on my NIOS system the console started printing… But at the 42’th SET action the complete system crashed. I made several modifications in my NIOS core, changed the phase shift, used different NIOS core types etc. Nothing worked. After several hours I almost gave up. One last thing to check. The software uses a generated BSP (Board Support Package). In this package are also the memory mappings for several areas of the NIOS system defined. I found out, the BSP standard uses SDRAM for these memory areas.

Overwriting the memory sections used by the system results in instant system failure. Doh… After changing these areas to the SRAM the read/write test finished successfully :D.

Post to Twitter

Categories: Electronica, Technologie Tags: , , , , , , ,

DMX lightcontrol using FPGA and RS-232 to DMX converter (part 1)

January 24th, 2011 1 comment

My last big project before I can start with my graduation internship is a DMX light controller using an FPGA and a RS-232 to DMX converter. I’m using the Altera DE2 development and education board containing a CycloneII FPGA. Combined with a DMX4ALL DMX player XS and a set of 4 RGB LED PAR’s this should become a nice system to demonstrate RS-232 communication on the DE2 board.

The core of the system will be a NIOS II processor. This gives me the opportunity to write C or C++ code for my program logic. Setting up the basics like the core NIOS II and a simple test program should be very simple according to several online university tutorials. Unfortunately, it took me longer than I expected. The standard pin assignment file for the DE2 board differs in naming for some DRAM pins compared with the naming used by the SOPC builder. There was also a bug in the Eclipse based software developer tool. After a lot of browsing through manuals and forums, some debugging and testing I finally managed to get the core system up and running.

I have uploaded an edited pin assignment file containing the DRAM pin modifications for the DE2 board and NIOSII. You can download this CSV file here. Two very clear and helpful tutorials can be found on the McMaster University website. The tutorials I have used are nios2-1 (mirror) and nios2-2 (mirror).

Now I could start with the fun part. Programming a simple test to send data over the RS-232 port. I managed to communicate with a laptop. But the DMX converter wouldn’t respond to the commands I sent. What could that be. Putty received the commands perfectly. Doh, of course. Most serial communication systems involve a TX and a RX signal. So does RS-232. What I need is a cross cable. I still don’t know why the communication with the laptop worked without a cross cable. The laptop probably has some sort of switching mechanism, like most of the ethernet connectors currently have. Transmitting data over RS-232 is very easy. It involves just a small piece of C code:

void UART1_T(unsigned char ch){
  while((IORD_ALTERA_AVALON_UART_STATUS(RS232_BASE) & 0x040) != 0x040){ ;}

Anyway, using a cross cable the converter finally responded to my commands. I wrote a small test program which changes the color of one RGB light. See the video below. When I continue on this project I will add links to the used manuals and add the code I used for my tests. That’s done.

Post to Twitter