gregdavill / diva-firmware Goto Github PK

The FPGA is capable of presenting itself as a USB device to a host.

It should be possible for the device to appear as a MSC (USB drive) and show a text-file which can be edited to adjust settings/parameters for the camera.

When telemetry is enabled on the camera, an extra line of data in inserted at the top/bottom of the frame.

This extra line contains extra telemetry information, which may be useful to enable at a later date.
However right now the image pipeline is not aware that this extra line is not image data, so it results in image artefacts, due to receiving 513 lines of valid data instead of 512.

Cover the following:

• What DiVA is
• Hardware it runs on
• Architecture of hardware
• Example screenshots
• Installation/updating

Adding an overlay to the video stream with a friendly name would be useful for identifying it when dealing with multiple cameras.

Via email:

Is there a way to reset the board back to default settings without using the menu?

Could you please?

It would be nice to remove the dependencies around the verilog DVI generation.

litevideo already includes a TMDS encoder module that should work in place of the verilog one.
https://github.com/enjoy-digital/litevideo/blob/master/litevideo/output/hdmi/encoder.py

We would need to create a thin wrapper that handles the 10bit -> 2bit output using DDR modules at pix2x speed.

Summary

During an update if the update is larger than 512KB the bootloader _wil_l become corrupted.
This is a bug in the bootloader, and due to a lack of FLASH locking.

Description of bug

When the write address of a block passes the 1MB boundary it starts targeting address 0x0, this is due to the FLASH on the board only being 1MB in size.

Proposed fixs

• Update bootloader to detect this event and cease writing past the FLASH capacity.
• Enable FLASH Write protection on bootloader blocks. (This could be done from user firmware)
• Create a workflow and guide for updating the bootloader in the field.

The current architecture only uses a single frame in RAM that is used to store new incoming frames as well as output the same frame to a monitor.

This creates a VSync issue between the input and output clocks. I've not noticed it being too bad with static scenes and the 60Hz camera, but becomes quite noticeable if the scene is dynamic, or if you are using a 30 or 9Hz camera.

The hardware contains 8MB of DRAM, so a proposed solution is to simply expand the DMA system to support 3 frames into the DRAM buffer. This ensures that an entire frame can be output without being altered mid way through transmission.

Currently the UI is implemented with a character terminal module.

This module uses up a fair amount of our fast internal memory on the FPGA and doesn't scale well if we try to increase the monitor resolution.

It would be nice to rework how the UI is implemented. I'm getting some inspiration on how we could do this with the Pixel Processing Unit, ppu, from https://github.com/Wren6991/RISCBoy

Currently the frame timing is all hard-coded inside the terminal module.

In order to support other resolutions (#9) it makes sense to refactor this so that Timing is separate from the UI.

litevideo already features the TimingGenerator and Initiator which enables adjusting resolutions via csr registers.
https://github.com/enjoy-digital/litevideo/blob/master/litevideo/output/core.py

Summary

The update software could also be used to upload custom firmware.

Description of feature

Currently the windows update tool is compiled with an embedded firmware.
Adding some GUI elements should enable the ability to load a custom file.

Mockups

Hello! How many FPS/Hz can one achieve with this adapter?

Issue filled via GroupGets

"One lil glitch I see, is as I was messing with the 1:1 vs full screen. (Just trying to remember how to make a selection and exit the menus) About every 3rd time, it went to full screen mode, I’d get a band on the left side that was a different shade of gray, and maybe 10% of the screen width. It would go away if I toggled back and forth again, so not a big deal to work around."

Radiometric bosons are now available.

This means that the are capable of outputting a calibrated temperature per pixel.
Making use of this will require capturing RAW pixel information from the camera instead of the colorized data we currently use.

This will require us performing the following steps:

• Automatic gain control
• Coloring with a Palette

With RAW data we can support:

• Min/Max highlight
• Histograms
• Spot measurements

Issue filled via GroupGets:

A customer wants to use the DiVA board with an HDMI transmitter.
Specifically this one: https://www.dji.com/lightbridge-2
They also tried the R2Teck and Aomway Nexus V2 with the same results.

These transmitters are compatible with 1280x720 or 1920x1080, but the DiVA wants to output 600x800 for the transmitter.
I think since the transmitter is not a display, it’s not automatically scaling.

The scaler I've written for this is hand-tuned for 640x512 upto 800x600.
But it does not currently perform correct interpolation on the Y axis. It simply duplicates lines to fill 600 lines. This can create artifacts on the Y axis if you are looking at diagonal lines.

Goal: Generalise the scaler pipeline so it can be used on both X and Y.

Making each axis configurable will enable up scaling of 320x256 data, and supporting both letterbox and fill scaling modes.
This change will be required to accommodate different screen output resolutions.

The device makes use of a bootloader that uses the DFU protocol.

dfu-util is cross-platform and can perform the update easily, however it might be useful to provide a dedicated application to assist with this process on windows for less tech savvy users.

The application will likely be built with the firmware, and contain an embedded copy of the firmware along with dfu-util. It will be required to detect our DFU device, and perform the update.