Go Down

Topic: [WORKFLOW RELEASE] Vidor sample projects are opensource! (Read 7864 times) previous topic - next topic

jomoengineer

I ran into the build error as well and found I had to run through the following on Windows 10 64-bit to get a successful build:
NOTE: This was parsed from the vidor-libraries/VidorBitstream github repo under:
"Things to know before getting started"

1. Open the  NIOS II Command shell and set the PATH variable:
    $ PATH=$PATH:/cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/TOOLS/scripts
    NOTE: This was valid for my config.

2. Then change directories to the VidorBitstream directory.
    NOTE: I did this from one directory up instead.
 
    $ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/

    or

    $ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga

3.  Set the permissions to the files under VidorBitstream

    $ chmod -R a+rw *

4. Then under the TOOLS/scripts directory, run the patch script
   $ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/TOOLS/scripts

   $ apply_quartus_patches.sh

5. Download and install the GO Programming language and build makeCompositeBinary.
   $ cd ../makeCompositeBinary
   
   $ go build -o makeCompositeBinary make_composite_binary.go

6. Build an example:
   $ cd /cygdrive/h/Development/Arduino_config/MKR_Vidor_4000/fpga/VidorBitstream/projects/MKRVIDOR4000_graphics

   $ build_all.sh

This resulted in the following for me:
Code: [Select]
Info: Quartus Prime Shell was successful. 0 errors, 352 warnings
    Info: Peak virtual memory: 4626 megabytes
    Info: Processing ended: Sat Jun 22 02:28:30 2019
    Info: Elapsed time: 00:06:33
    Info: Total CPU time (on all processors): 00:00:05
create ram + flash app.ttf
Jun 22, 2019 2:28:30 AM - (INFO) elf2flash: args = --input=build/software/MKRVIDOR4000_graphics/MKRVIDOR4000_graphics_lite.elf --output=build/output_files/MKRVIDOR4000_graphics_lite.flash --base=0x008E0000 --end=0x008FFFFF --verbose --save
Jun 22, 2019 2:28:30 AM - (FINE) elf2flash: Starting
Jun 22, 2019 2:28:30 AM - (FINE) elf2flash: Done
projects
ip
cp: omitting directory './ip/GFX/arduino/Vidor_GFX/examples'
cp: omitting directory './ip/QUAD_ENCODER/arduino/VidorEncoder/examples'
cp: omitting directory './ip/NEOPIXEL/arduino/VidorNeopixel/examples'
cp: omitting directory './ip/MIPI_RX_ST/arduino/VidorCamera/examples'




I hope this is on topic.

jomoengineer

After perfoming the VidorBistream build process and replacing the existing VidorGraphics Arduino IDE libraries folder with that built from VidorBitstream, ex;VidorBitstream\distrib\MKRVIDOR4000_graphics, as Martino explained to me has rendered my Vidor 4000 Graphics as non functional. I put the original library files back in place but still no luck; none of the VidorGraphics examples or code I had previously created and which were working are working now.  All I get on the HDMI output is a white screen with the Arduino log in the middle but not the one from the DrawLogo example.

jomoengineer

Okay, so I downloaded, built and loaded  VidorBoot from the vidor-libraries GitHub repro and all is right again with the Vidor 4000.   

rymen

I just built VidorGraphics from the VidorBitstream repo (using Quartus 18.1), and successfully flashed the VidorQrRecognition example sketch to my board.

I have a camera and an HDMI monitor connected, and the monitor shows the camera video fine, but the QR recognition is not working - the blue crossmarks in QR markers are not shown.

If I use the pre-built VidorGraphics (downloaded through "Manage Libraries"), the QR recognition works correctly.

I also note that the pre-built VidorGraphics has version no. "1.1.0" in "Manage Libraries", and my built-from-source version also has version no. "1.1.0" in library.properties, but they are *not* identical - for example, the "VidorQrRecognition" example from the pre-built library has the famous "while (!Serial);" line, but the VidorQrRecognition example from the github VidorBitstream repo does not.

Is there a known bug regarding QR recognition when building from the github repo? If not, any suggestions on how to troubleshoot?

rymen

Hm, it seems the problem is more general than the QR demo:

When I do a cold boot of the Vidor after flashing my source-built code, the HDMI monitor is stuck on only showing the Arduino logo on white background. Graphics commands like vcam.vgfx.Cross() are not working (and no camera video), but the sketch loop() is running, as I can see debug printouts with Serial.print() in the console.


What I did yesterday, was to flash my source-built firmware over the stock firmware/QrRecognition example, *without* power cycling. After flashing and "soft reset", I got the behaviour described in my previous post (i.e. camera video working, but no QR recognition).

I added some more vcam.vgfx.Cross() and Serial.print() lines for debugging, and it seems that *both* QR recognition and graphics drawing are broken after soft reset. The sketch receives no QR markers, and also cannot draw any graphics.

If I flash the stock firmware again, I can replicate this behaviour over and over. That is:
1) Flash stock fw
2) Power cycle
[ 3) Everything works ]
4) Flash source-built fw without power cycling
5) Camera video still works, but QR recognition / graphic overlay stopped working
6) Power cycle
7) Stuck on white screen w. logo


Is there something wrong with communication between the MCU/sketch and the FPGA? How do we troubleshoot?

rymen

Ok, now I'm really confused. I did a really basic test to see that my app.ttf is loaded correctly:

1) Installed precompiled VidorGraphics from Library Manager
2) Flashed the QR example to the board - QR recognition works

3) Built the *VidorPeripherals* app.ttf from source (e.g: NOT the VidorGraphics app.ttf)
4) Put my custom-built *VidorPeripherals* app.ttf into the *VidorGraphics* precompiled library's folder (overwriting the precompiled app.ttf for *VidorGraphics*)
5) Once again flashed the QR example to the board

6) QR recognition is STILL WORKING?!

But - I flashed the sketch using the wrong app.ttf (VidorPeripherals), which should not contain the necessary things for camera + QR recognition??

So why is QR recognition still working? Has the app.ttf not been flashed to the FPGA at all?

Can someone please describe how they got the VidorBitstream workflow to work correctly? Am I missing something obvious?

jokejustjoke

#36
Nov 26, 2019, 01:39 am Last Edit: Nov 26, 2019, 05:20 am by jokejustjoke
Ok, now I'm really confused. I did a really basic test to see that my app.ttf is loaded correctly:

1) Installed precompiled VidorGraphics from Library Manager
2) Flashed the QR example to the board - QR recognition works

3) Built the *VidorPeripherals* app.ttf from source (e.g: NOT the VidorGraphics app.ttf)
4) Put my custom-built *VidorPeripherals* app.ttf into the *VidorGraphics* precompiled library's folder (overwriting the precompiled app.ttf for *VidorGraphics*)
5) Once again flashed the QR example to the board

6) QR recognition is STILL WORKING?!

But - I flashed the sketch using the wrong app.ttf (VidorPeripherals), which should not contain the necessary things for camera + QR recognition??

So why is QR recognition still working? Has the app.ttf not been flashed to the FPGA at all?

Can someone please describe how they got the VidorBitstream workflow to work correctly? Am I missing something obvious?
This is exactly what I've been trying to solve, I cleared (keep the file but delete all the contents) both app.ttf and signature.h and nothing changed

jokejustjoke

Hi,

Thanks for the updated files, the Quartus patches seem to work fine now!

I am having problems running the example files however (starting with a slightly modified bare example that should set an output pin to 1 lighting up an LED). If I merely create an Arduino library (as is suggested in the github readme), the Arduino IDE complains that FPGA is defined twice (once in the VidorFPGA.cpp file in the VidorPeripherals library and once in my test library). I can comment out the offending lines in either of the libraries, but I am not certain how to figure out which app.ttf gets loaded in the end.

I have not yet managed to turn the output LED on through code written in Quartus. It seems to me that no matter what app.ttf I try to load, the example sketches from VidorPeripherals (setting outputs to on and off) seem to work. This indicates to me that I am always just loading the pre-compiled FPGA code, am I misunderstanding something?

I have also tried running the blinking example sketch written by Philippe which was posted here earlier and while Quartus indicates that everything compiles fine, the LED connected to port 6 never blinks. Is there a way for me to debug whether I have a problem with my FPGA? (The VidorPeripheral examples work!)

EDIT: Turns out I had screwed up something during my early debugging attempts, restoring the bootloader (according to the other thread) fixed my issue.
Hello, I'm also having the same problem. I tried multiple app.ttf (even with app.ttf with no contents), the results are all the same. I'm pretty confused as the code does try to read app.ttf and signature but the contents don't matter.

rymen

Ok, I think I found the problem (but just you wait, there are more problems coming... ^^)

If I re-flash the FPGA bootloader before I upload my sketch containing a new app.ttf, then everything seems to work.
It seems that I have to flash the bootloader anew before every sketch upload, for the app.ttf to be written.

The tools for re-flashing the bootloader can be found in this thread: https://forum.arduino.cc/index.php?topic=561393.0


Seems like a really convoluted and error-prone workflow... Would be great if the normal "modus operandi" of a sketch would be to use JTAG (or some other "native" method) to flash the FPGA in the first place, and not be dependent on a working bootloader in the FPGA to receive the app.ttf!



Anyway, now I can consistently flash a new app.ttf.

However, the VidorGraphics library is absolutely useless when built from source with the free version of Intel Quartus.
The VidorBitstream repo's README notes that the NIOS2 softcore in Quartus Lite is a crippled version that runs much slower than the one in the paid Quartus Standard.

I can confirm that this causes all graphics commands (like fillRect(), fillCircle() etc.) to run EXTREMELY slowly - you'll watch the picture being drawn pixel-by-pixel, it'll take almost a minute for the VidorDrawLogo example to finish drawing. o.O


Also, I cannot get the VidorEnableCam example to work at all with the source-built library/app.ttf.
First, the screen is (pretty slowly) filled with white. Then, when vcam.begin() is called, the screen is (even more slowly) filled with black (pixel by pixel). This is the VidorCamera library filling the graphics overlay with "transparent" pixels, to unveil the underlying camera stream (see here: https://forum.arduino.cc/index.php?topic=560517.msg3824792#msg3824792 and check out VidorCamera::begin() in VidorCamera.cpp).

However - there's no camera video underneath, just black. With the precompiled library/app.ttf, again, it does work.

Sigh. I'm starting to very much regret my purchase of the (expensive!) Vidor, that was being touted as an Arduino with a programmable FPGA! Not as an Arduino with a black-box IC (that technically happens to be an FPGA) which cannot be used for anything but a few useless precompiled toy functions.

A good start would be for Arduino to re-write the FPGA parts of the library to be *completely* functional when built from source with the *free* Quartus version.

Even better would be to redesign the board with something like the Lattice ECP5 or Xilinx Zynq-7000 and use the fully open source toolchains available for those! :) That would've been awesome.

Also, the "KISS" mentality would serve well: the Vidor FPGA workflow is very convoluted with all the "infrastructure" in the build environment to stitch together different IP blocks and binary images in god-only-knows-what way - it is a very opaque system for the newbies, much harder to figure out than necessary.

Sticking to plain, simple Verilog projects without softcores, bootloaders etc. would be much easier on the beginner.



I was planning to do a pretty simple project based on the QR reader, where I modified the reference firmware to track visual features in a slightly different way.

After wasting many days on just trying to get this crazy build workflow going, I have now pretty much decided to scrap my project, as it doesn't seem doable unless I rewrite the whole FPGA part from scratch. That was NOT part of my intention, and is also way harder to do for a beginner, than what I was planning to do.

For anyone reading this who is thinking about purchasing the Vidor to get started with Verilog/FPGA development, I would very strongly recommend against it. Go get a Lattice Icestick, Xilinx/Digilent Zybo board or the ULX3S Lattice ECP5 board instead, use the open source toolchains, and you'll likely have a much better time! :)

jokejustjoke

Thanks for the post. Just curious, have you ever tried to re-flash the bootloader, then program the board with a blank app.ttf and signature.h? I tried it and I saw no change after clearing the ttf and .h, very weird.

Also I saw what you talked about the slow update - but that only happened to me when I used the distrib output from the project compilation using NIOS II command shell. Weird, again.

I'm looking at the USB blaster to solve my 1st problem mentioned.

rymen

I have not tried flashing an empty app.ttf, but it sounds like storage isn't cleared before the new bitstream is written to it... Could it be that flashing an empty file causes *nothing* to be written, which leaves the old bitstream in place? Whereas flashing a new (potentially smaller) bitstream might still leave old data around, but it will never be read, and so it won't matter?


Could an Arduino employee please confirm whether it is possible to build a working camera or QR example from the VidorBitstream source?
That would be super helpful, so that we know whether to press on or not.

Thanks!

jokejustjoke

I have not tried flashing an empty app.ttf, but it sounds like storage isn't cleared before the new bitstream is written to it... Could it be that flashing an empty file causes *nothing* to be written, which leaves the old bitstream in place? Whereas flashing a new (potentially smaller) bitstream might still leave old data around, but it will never be read, and so it won't matter?


Could an Arduino employee please confirm whether it is possible to build a working camera or QR example from the VidorBitstream source?
That would be super helpful, so that we know whether to press on or not.

Thanks!
This feels like a dead sub-forum, the mods' last post is since May, and many questions left unanswered. I don't feel very safe pushing on with my project.

Limba

I will try to look these. I just updated my computer so I have to reinstall all tool chains.

Also that Arduino team radio silence is not what I like.
At least Vidor4000 have moved to normal branch. Earlier it was only in Beta devices.

Also remember you can only use one FPGA image at time.

IMO:
I think currently Vidor is ok for basic FPGA learning with Quartus Lite and USB Blaster sketch.
I would recommend to use serial or SPI for data transfer to FPGA and USB Blaster sketch for debugging FPGA.
Currently biggest problem is missing documentation of mailbox system and no select for VCCIO for banks (no LVDS in mini PCIe connector).

jokejustjoke

I will try to look these. I just updated my computer so I have to reinstall all tool chains.

Also that Arduino team radio silence is not what I like.
At least Vidor4000 have moved to normal branch. Earlier it was only in Beta devices.

Also remember you can only use one FPGA image at time.

IMO:
I think currently Vidor is ok for basic FPGA learning with Quartus Lite and USB Blaster sketch.
I would recommend to use serial or SPI for data transfer to FPGA and USB Blaster sketch for debugging FPGA.
Currently biggest problem is missing documentation of mailbox system and no select for VCCIO for banks (no LVDS in mini PCIe connector).

Thanks, I appreciate any help!

This is what I just tried:
1/ load the blink LED from this site: https://systemes-embarques.fr/wp/archives/mkr-vidor-4000-programmation-du-fpga-partie-1/    --> it runs, LED blinks

2/ So then I run the Bootloader recover from this site: https://forum.arduino.cc/index.php?topic=561393.0

3/ delete all the contents of the app.h file, compile and upload via arduino again --> it still runs even though app.h has nothing

4/ After 3/, I delete the content app.ttf and signatures.h in vidorCamera library, compile then upload again --> LED still blinks while camera is not read.

So what I think is happening is

1/ that the bootloader recovery doen't clean up everything, still leaving the source somewhere causing step 3 to run

2/ rymen's assumption is correct as nothing is written meaning the previous code keeps running (step 4)

Limba

If I remember right boot loader need some data in .fpga_bitstream section that is outside of SAMD flash area. If it's empty it won't access to FLASH connected to FPGA.

Edit:
If you plan to use USB Blaster sketch. When you want to reprogram device you need to double tap reset to go boot loader mode because USB Blaster reserves whole USB interface for emulating USB Blaster. 

Go Up