Just as proof of concept, I up-ported the LCD-interface from the ‘beatrix’ SoC to the ‘dagobert’ netpp node default SoC configuration. This also introduces GPIO multiplexing options on port A, meaning, that a few pins have dedicated funcionality driven by an asynchronous bus engine with some extra decompression logic, tailored specifically for LCD screens. Since direct GPIO bit banging would burn a few more cycles and be slow, having a special interface definitely pays off (apart from DMA features, etc.)
The display controller of this OpenSmart variant has different addressing modes, so you can switch between landscape and portrait. However, there’s a catch: When trying to make use of the built-in scrolling feature, it turns out it is only supported for portrait mode, i.e. the shown landscape orientation would require to buffer the terminal content and redraw for each new line.
I have also tried to run a simple GUI toolkit as Achim Döblers µGUI. Due to its simple pixel-wise drawing API it is not very fast, but works ok for most purposes.
What is left to do is the touch screen implementation. This will only work on the ADC10 variant of the netpp node with populated msp430g2553. For now, touch screen is not required, so this task is not scheduled (no pun intended).
Other than that, the same techniques as mentioned in this post are used to save RAM resources using the SCACHE peripheral.
Here’s a short step by step intro to install and run netpp on Windows10 (it will work likewise on older Windows versions):
Download Python 2.7 (32 bit) and install it. Make sure to install for all users, otherwise the netpp installer will not find the Python directory and complain.
Download and run:
[sdm_download id=”1349″ fancy=”1″]
Run the example server via Start Menu->netpp->Run example server. A warning will appear and request you to unblock the service, possibly. Then, a small example netpp server is listening on your local machine.
Start the IDLE environment via Start Menu->Python 2.x->IDLE. Read more in detail below…
If you did not download Python before installing netpp, the netpp installer will throw a warning, but still continue.
First steps
Windows10 netpp session
When you have started IDLE, first try to import the netpp module as shown in the screen shot. Then make a connection to your local example server using the .connect() method.
The .sync() command creates a local property tree with root node ‘r’. When first called, the device server is queried for all available properties, so this can take a long time on some systems. Once the query has completed, the tree is stored in a cache and is only reloaded, if the device properties have changed.
Note the message “using PWD for storage”. If you have no cache directory created, the cache will be installed in the current program’s working directory, which may not be desired. Create the folders ‘.netpp/cache’ in your home directory, then the warning will go away. If you ever need to manually delete the cache files, you will find them there.
Next, we are going to look at the properties. This is simply done the pythonish way using ‘dir’.
And last, we obtain a property value using the .get() method. Simple as that.
Using the Power shell
There are two command line utilities:
master: Simple command line demo tool for netpp access
netpp-cli: interactive netpp client
Open up a Power shell (or a legacy cmd.exe) and change directory to where your netpp binaries are installed, like
cd c:\Program Files (x86)\section5\netpp\bin
The master.exe is a very primitive command line tool for netpp device query. When run without arguments, it will display the available hubs and send out a broadcast on the local network for attached netpp devices. If your example server is running, you will see it listed. Try accessing it:
.\master TCP:192.168.56.1
and it will list the device’s properties.
The netpp-cli.exe is an interactive console with a bit more caching functionality and session character, i.e. when you made a connection, the device will reserve a session with you until you exit the CLI. This operation mode may be required on some more complex devices that work session based.
Make a connection to a device:
.\netpp-cli TCP:192.168.56.1
At the netpp prompt, type ‘?’. Now you can just get a property value by typing its property name, like Container.Test. When you append a value, you can change a property, likewise.
Process viewer/browser support
To use the predefined GUI process control based on the free pvbrowser (see github repository), you need a demo setup based on a modhub or another Linux embedded demo setup running a pvhub server. This assumes a netpp node setup with default design.
Start the pvbrowser on your PC
Enter the URL
pv://modhub/netpp:UDP:192.168.0.5:2016
into the pvbrowser for a direct connection to the netpp node (assuming default IP at 192.168.0.5). Replace ‘modhub’ by the IP address of your pvhub server host.
The process viewer should display something like below:
PVbrowser netpp node example
Troubleshooting
There are some known issues with the evaluation release netpp 0.5-rc1 on Windows and IDLE:
When a cache directory was not created ($HOME\.netpp\cache), Python(IDLE) will report:
C:\Users\me\/.netpp/cache not found, using PWD for storage
This is mostly not a problem, however when access rights are limited, creating the cache can fail. Create this directory in your $HOME then.
Upon synchronization, a failure can occur when a cache created from an older netpp version is found:
r = a.sync()
...
IndexError: tuple index out of range
Search for the corresponding *.pyp file and remove it
I am glad to announce a new user evaluation platform module called ‘netpp node’. Its motto is ‘IoT on FPGA done right’. See detailed specs and preliminary order information here: [ refdesigns/netpp_node ].
Update [21.12.]:
The netpp node engineering samples v0.0 have just passed the long term burn-in. Running since approx. 11 weeks non-stop, the units are flooded with netpp requests from an embedded PC and have shown no failure in the hardware, except a reboot resulting from a power outage.
v0.1 series [18.1]:
Received the series! So finally we can ramp up with the delivery to beta developers…(thanks for being so patient).
Analog I/O
ADC10 low level control
For analog I/O, U3 on the board is by default populated with a MSP430G2553, functioning as a smart ADC that is controlled from the ZPUng ‘dagobert’ SoC via i2c. All relevant ADC configuration registers are directly accessible via netpp. For instance, we access the low level registers through a process browser panel as shown above to play with the parameters. The process view panel automatically updates the volatile properties from the netpp peer device. The ADC10 variant of the netpp node provides up to six analog channels internally sampled at up to 200ksps. When in synchronous acquisition configuration (SPI master), only five channels can be used.
Differential 16 bit sigma-delta ADC
SD16 analog input
The alternate population option with a MSP430F2013 provides a Sigma-Delta 16 bit ADC with differential inputs and programmable gain amplifier. This variant provides three different input channel configurations using the provided analog input pins on this board. Moreover, the internal temperature is available in a separate channel.
‘Push on demand’ data streaming
By default, the analog sensors are polled, i.e. a measurement value is delivered upon request by the master. For synchronous sampling however, a ‘push’ strategy might be desired, where a netpp node delivers a value stream to a data logger or database. This can be netpp (where the netpp node acts as a master), however for high speed data transfers (‘network scope’), a low overhead UDP stream is more desirable. The dagobert SoC features a data port option with programmable slots to stream I/O channels as well as analog values using a standard real time protocol with 90 kHz time stamps.
Monitoring netpp packet performance
Packet behaviour in a real network is measured using the Wireshark protocol analyzer.
The figure below shows some example netpp transaction log that the netpp node handles at a very low CPU overhead based on direct register accesses.The red bars is the effective number of query responses using somewhat ineffective ping-pong requests. The performance can be increased by accumulating data into larger buffer properties.
For i2c or SPI transactions however, the packet rate is expected way lower.
For high speed performance like MJPEG video streaming, a separate UDP/RTP queue can be set up within the firmware to reach maximum throughput. However, there is no handshaking using this method.
The image below shows a repeated property query from within Python. The pauses are introduced by external disturbance (stress test) that causes a packet drop – and the netpp engine to timeout and re-synchronize.
Python property query session
Improved RX/TX queue
With an improved packet FIFO on FPGA, I was able to crank up the number of netpp requests per second, as shown in the Wireshark trace below. This test makes sure that several netpp clients can poll the netpp node at high frequencies without disturbing each other. The blue trace is a repeated poll of the full property tree, the red bars are the timed queries from a process viewer daemon. With no other disturbance, we get the occasional drops (e.g. at 45s, 101.5s) due to the queue running full
In-Field/System update
The default boot loader firmware supports self-programming over the cable. That means, the netpp_node can be supplied remotely with a new firmware image via a simple upgrade procedure over netpp. If the uploaded image is faulty, the system will fall back to the default boot loader. However, if the new design itself has errors, the system will be unable to recover unless the reset button is pressed.
Test procedures
As the full model of this design is available for simulation, we can verify the system effectively against stress situations. In particular, network safety is of outmost importance. The test procedure check list of the dagobert SoC:
Completed
ARP and ping flooding
netpp packet performance test
Broken packet handling
Lost interrupt scenario (packet queue desynchronization)
Yet open
Jumbo packet flooding was tested, however support can not be enabled on this platform for the receiver queue. It is however possible under certain circumstances to generate (TX) Jumbo packets for experimental purposes. The performance gain is however minimal.
Extended RTOS support
Currently, the netpp node runs a simply bare metal main loop without particular RTOS functionality, i.e. all user code must be designed such that there are no blocking wait statements. Let me just put the FAQ together:
There is FreeRTOS and eCos support code for the ZPU architecture. However, I have no plans in going down that road, you’d be on your own.
A NuttX port is currently under evaluation and may likely be released in a few months time. NO PROMISES!
A simple ‘netpp OS’ with very basic task management is in experimental stage:
Guaranteed latency time from driver interrupt to queue handler task
‘User space’ context switch when sleep() called
Very cheap context switches due to ZPU architecture improvements
Code size is an issue on this particular platform, larger programs (TCP stacks) need to move to the SPI flash overlay program space. Since this involves caching, the program timing is no longer fully deterministic and the RTOS functionality can only apply to program code running in the L1 memory.
