Programming the RedPitaya in Python.

[dtorette4868]

Izi wrote

- I am preparing an image where UIO is used for the whole FPGA memory map, this would allow handling interrupts.
- I do not like using Python directly for low level drivers, it could result in performance issues. C should be prefered.
- I would like to finish a FPGA image with DMA support for oscilloscope first, but right now, I do not know when time will be available.

I agree that for embedded system programming C should be preferred, but Python could be interesting in the frame of Jupyter Notebooks.

Izi wrote

So in PYNQ there are many SW layers which I do not see as appropriate for Red Pitaya.

I was surprise by the lack of native Python libraries.
My goal is not to port all the SW layers of the Pynq project, but to integrate some custom IPs in the FPGA and control them from a Notebook.
Before going to such custom IPs, a first step should be to control the native functions of the default FPGA image.
So let me know when your FPGA image will be available, it will be interesting to encapsulate its services using the 'mmap' approach.

Regards, Dominique T.

[dtorette4868]

Concerning the various versions of the distro I've some questions.
I've discovered the download section of the RedPitaya web site http://downloads.redpitaya.com/downloads/, but we also a Github repository https://github.com/RedPitaya.
What is the reference? Are they synchronised?

On the download section:

• There are two distros: red_pitaya_OS-stable.img.zip and red_pitaya_OS-beta.img.zip with significantly different file size. What explain such a different size?
  There are two release numbers: OS-v0.96 and OS-v0.97. But these release numbers doesn't seem to correspond the 'stable' and 'beta' images.
  The changelog files are loosely detailed and quite hard to read.

An image is composed of two separate partitions: one for the 'ecosystem' and one for the 'os'.
Are there dependencies between these two partitions?

The red_pitaya_OS-beta.img.zip is dated 15-Dec-2016 07:27with a size of 1040953644, a file with the same sized red_pitaya_OS-v0.96-RC2-76-22_aug.img.zip is named August release date file name pattern. Are they different?

I know that documentation is boring. I think that all these should required some clarifications...
How to be sure that problems experienced with 'apt-get install' are coming from an incompatible distro?
Is the procedure to re-build from the sources available somewhere?

Regards, Dominique T.

[pavel]

Just my other two cents for this discussion.

The jupyter's predecessor called ipython notebook is available from the Ubuntu 16.04 repository as a binary package. It can be installed and run with the following commands:

Code: Select all

apt-get install ipython3-notebook
ipython3 notebook --ip=192.168.1.100

From a user's point of view, I don't see much difference between jupyter and ipython notebook. Their behavior and user interfaces are very similar.

[izi]

Hi Dominique,

I will respond to a few questions, I am kind of on vacation now.

An alternative to using PIP to install Jupyter is to port Debian sid packages to Ubuntu 16.04,
this is reasonably easy to do using a Launchpad PPA,
but a large set of packages with a large net of dependencies can cause problems.
https://launchpad.net/~redpitaya/+archive/ubuntu/zynq

Each stable release is tagged on our github repo, and images are build from the tagged code.
There is some improvising around Wyliodring, otherwise the process is rather straight forward.
http://redpitaya.readthedocs.io/en/late ... EADME.html
This instructions are a bit outdated but the basics should work.

The beta image is larger, since the drive free space was not properly zeroed to reduce compressed size.

There are dependencies between the OS on the ext4 partition and the ecosystem on the FAT partition.
But we try to keep them to a minimum. We are using OS libraries for example.
Applications in the ecosystem require systemd services (start scripts) stored on the OS partition to run.

Regards,
Iztok Jeras

[izi]

Hi,

I was working on an non root support, so I will probably prepare an image where Jupyter will run as a non root user.

I still have some trouble installing the proper set of packages, I mixed pip and apt and there were some conflicts between versions of path.py and pickle. Installing everything using pip takes ages (especially numpy), and probably leaves far more temporary data on the drive compared to apt, affecting compressed image size.
My point is, it will take me some time to produce a reliable image.

The second thing I would like to discuss is the prefered way to access FPGA registers directly.
I got ideas from here check uio.py and axidma.py:
https://github.com/Kirill888/parallella ... sample_dma

Code: Select all

import mmap
import os
import time
import numpy as np

regset_hk = np.dtype([
    ('id'          , 'uint32'),
    ('dna_lo'      , 'uint32'),
    ('dna_hi'      , 'uint32'),
    ('digital_loop', 'uint32'),
    ('ex_cd_p'     , 'uint32'),
    ('ex_cd_n'     , 'uint32'),
    ('ex_co_p'     , 'uint32'),
    ('ex_co_n'     , 'uint32'),
    ('ex_ci_p'     , 'uint32'),
    ('ex_ci_n'     , 'uint32'),
    ('reserved_2'  , 'uint32'),
    ('reserved_3'  , 'uint32'),
    ('led_control' , 'uint32')
])

os.system('cat /opt/redpitaya/fpga/fpga_0.94.bit > /dev/xdevcfg')

fd = os.open('/dev/mem', os.O_RDWR)
m = mmap.mmap(fileno=fd, length=mmap.PAGESIZE, offset=0x40000000)
hk_array = np.recarray(1, regset_hk, buf=m)
hk = hk_array[0]

for i in range(10):
    hk.led_control = 0xff
    time.sleep(0.2)
    hk.led_control = 0x00
    time.sleep(0.2)

I was not able to skip the step hk = hk_array[0], otherwise the code is rather compact and readable.
Of course variable names should be rethought.

Regards,
Iztok Jeras

[dtorette4868]

It's great to see that this discussion will end by Jupyter support from RedPitaya.
If needed, I can participate to the test of this port and FPGA registers access.
I can also write a Jupyter demo Notebook showing how to access the FPGA.

Regards, Dominique T.

P.S.: Even if Jupiter will not run as root, doesn't the 'mmap' approach require to run as root?

[izi]

/dev/mem is in the kmem group, it is enough to add the user running Jupyter into the kmem group.
But I plan to use UIO, which will provide a /dev/uio/api device or maybe multiple devices for each FPGA module (housekeeping, oscilloscope, generator).
UIO has a slightly different mmap interface (offsets are handles differently) and it supports interrupts from userspace.
And UIO devices will be in the uio group, as will be the user running Jupyter.

Regards,
Iztok Jeras

[dtorette4868]

The blink led example also works on my STEMlab 125-10 setup.

If you are new comers on Python and Jupyter, you could be interested by this free Ebook http://www.oreilly.com/programming/free ... python.csp from O'Reilly.

Moreover you could also install this text book as aJupyter Notebook and having all code snippets running live on your RedPitaya
You have just to clone the Notebook from the author's Git repository:

Code: Select all

 git clone https://github.com/jakevdp/WhirlwindTourOfPython.git 

and then pointing your browser to WhirlwindTourOfPython/Index.ipynb.

Have fun, Dominique T.

[The Great Morphu]

Hihi and hello there!

Sorry, I seem a bit late to the party..
Right now I am eagerly waiting for my 125-10 and start reading about it.
Jupyter seems to be the perfect choice to control this (or any other) little device...

However, I am confused a bit (maybe because I never held the STEMlab in my hands)..
What I would like to do is to use Python on my PC and control the device form there..
(So I wont really care what and how much is running on the device itself as long as it fullfills all queries)
This thread seems to go into a different direction.. why would I need Jupyter or Numpy on the 125-10?
Maybe I misunderstand something fundamental here?

What I would look for (or will try to create in the next weeks) is a Jupyter notebook remotely controlling the device, setting a Voltage or a frequency, plotting one Oscilloscope channel..

Cheers, thank you for any help and all the best regards,
Markus