Faster writing to the GPIO-Pins via the FPGA-Registers

[Toni]

Hello guys,

is there a possibility to speed up the procedure, which ensures the data-sending from the FPGA registers 0x40000018 and 0x4000001C to the GPIO-Pins, when using the "monitor"-command?

If I now use a few "monitor"-commands one after the other with different values in a script, the values on the pins change with a frequency of about 100 Hz. I think this frequency/speed has been set somewhere. Can one change its value?

Thanks

Toni

[Nils Roos]

Hi Toni,

There is no artificial limit on the rate that the monitor tool can drive the GPIO pins. Only processing overhead limits the speed.

The monitor tool has a mechanism to accept operations from stdin, which allows you to avoid some of the overhead. Execute "monitor -" (a single minus sign as first parameter), then you can issue operations to its stdin. Syntax examples for read and write:

Code: Select all

redpitaya> monitor -
0x40000020          <- reads value from exp_p pins
0x40000018 w        <- prepares to write value(s) from the following line to exp_p pins
0xff 0x00 0xff 0x00 ... (values will be written to the specified address as fast as monitor is able to, after you enter an empty line)

Don't use monitor for long term operations in this mode, it has some (small) memory leaks that may eventually bite you.

I suggest preparing some commands in a file, do "monitor - <file" and see if that is fast enough for you. If not, you will have to adapt the monitor tool to serve your specific purpose.

[Toni]

Hi Nils,

thanks for your answer, even its been a while

The speed of writing with that use of the monitor-command would be suitable for my application (ca. 2 MHz). But now I have another problem:

I need to write to the P- AND the N-Lines. But when I change from P- to N like this:

monitor -
0x40000018 w
0xff 0x00 0xff 0x00 ....
0x4000001C
0xff ....

...then I have a delay of several 10 µs , which is too long. Is there a way to use the monitor.c to write faster to both registers?
Otherwise I have to modify the c programm, if there is any way.

Thanks!

Toni

[Nils Roos]

Hi Toni,

The monitor utility always performs a new mmap/munmap for every address given, which probably accounts for the delays you are observing. There is no way around that, except by changing the utility.

To change that behaviour, take a look at this part: (Test/monitor/monitor.c , line 317+)

Code: Select all

		while ( parse_from_stdin(&addr, &access_type, &val, &val_count) != -1) {
			if (addr == 0) {
				continue;
			}
			/* Map one page */
			map_base = mmap(0, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, addr & ~MAP_MASK);
			if(map_base == (void *) -1) FATAL;

			if (val_count == 0) {
				read_value(addr);
			}
			else {
				write_values(addr, access_type, val, val_count);
			}
			if (map_base != (void*)(-1)) {
				if(munmap(map_base, MAP_SIZE) == -1) FATAL;
				map_base = (void*)(-1);
			}
...
		}

If you remember the last mmapped (addr & ~MAP_MASK) and only do the munmap / mmap if it evaluates to a different address, it should solve your problem.

[Toni]

Hi Nils,

thank you for your suggestion! I will take a look at this section and if I find a solution I´ll post it here.

[Arnold]

how can you set a GPO pin to High or Low by the ARM (SW) - without the use of a command line tool?

[Geoffrey]

I suggest preparing some commands in a file, do "monitor - <file" and see if that is fast enough for you. If not, you will have to adapt the monitor tool to serve your specific purpose.

What is the exact format and content of the file? Can monitor be run over a sequence of commands like this?

Using a shell file where each line is

monitor 0x40000010 0x02
monitor 0x40000018 0x02
monitor 0x40000018 0x00

etc. works but is obviously slow. I tried making a file with just the addresses and data and using "monitor -<monitor_test" with and without a .sh extension on the file (monitor_test and monitor_test.sh) from PuTTY but nothing happened. The contents of this file were:

0x40000010 0x02
0x40000018 0x02

I am hoping to eventually have a system that outputs patterns on the GPIO at high frequencies (~20-100+ MHz) and thought I'd try this kind of approach first.

Cheers.