Hardware ISP and v4l2 - linux

I'm new to Linux.
My doubt is regarding v4l2 driver supporting existing ISP harware in Jetson TX1.
I would like to know whether basic v4l2 implementation in Linux provides an interface to send data to ISP(hardware module) or not?
If not provided, is it possible to modify the v4l2 implementation so that it does not bypass ISP.
And also, I would like to know, how the data flows from an image sensor to system memory through v4l2( if possible can i get sources for block diagram representing this data flow)
Please help me...

Related

CSI-2 V4L2 driver programming

I am interested in porting a camera driver from one SOC(Pi) to another SOC(Jetson) which both run flavors of linux and have CSI-2 interfaces.
I have the source code for the driver. I'm trying to understand how the CSI-2 interface works with respect to V4L2. The camera is controlled by the SOC through an I2C line which control functions are provided for in the source code. What I am confused about is if I need to write something to actually pull frames from the camera and control the CSI interface directly? Or is that all standardized by the CSI-2 interface and handled by V4L2?
If you wanted to access the raw data from the camera how is this done?

How do I transfer data from RISCV Rocket chip core to peripherals connected directly to FPGA pins?

I am trying to accelerate the communication between two FPGA/ARM development boards. Currently, data is passed from RocketCore to the ARM processor to an Ethernet port. This transfer is incredibly slow. Instead, I am trying to connect the RocketCore directly to the development board's peripherals. All documentation I read indicates the only way to get data out of a RocketCore is via MMIO. First is it possible to directly control an FPGA pin via a RocketCore? Second if yes, what command, library etc. would I use?
Functions as simple as would suffice
writePin(pin number, value)
readPin(pin number)
Thank you in advance!
I have tried sending data via the ARM core; however, that is too slow for my application.

How can I use Androids Audio Tunneling API to send compressed and encoded audio through USB to an external source instead of an onboard DSP?

I would like to stream audio through USB to be decoded by an external source. Android has released version 4.4 with Audio Tunneling to DSP. Audio Tunneling works by taking a compressed and encoded audio source and instead of sending it to the CPU, it sends it to an onboard DSP. This API was written by a company called Cadence I know that it currently works on The Nexus 5. I also know that it will only work if there is a DSP that it can be sent to. I am speculating that the Audio Tunneling API can be used to take the encoded audio stream data to the USB by some means instead of CPU or DSP. I am assuming this is true because of the compress_offload.txt states this
"The Compressed Data API does not make any assumptions on how the data
is transmitted to the audio DSP. DMA transfers from main memory to an
embedded audio cluster or to a SPI interface for external DSPs are
possible. As in the ALSA PCM case, a core set of routines is exposed;
each driver implementer will have to write support for a set of
mandatory routines and possibly make use of optional ones."
I would like to use this technique on Phones or tablets that lack a true on board DSP that the Audio Tunneling API would normally send its data. Any thoughts on implementing this? Also, if possible, I would like to get this working without rooting it.
Any help, tips and source code will be greatly appreciated.

How to send and receive bytes stream between PC and DE2 board

My school project is doing edge detection on DE2 board.
I'm looking for the way to send bytes stream from PC to DE2 board, and after doing edge detection, send data out back to PC.
Any help on general ideas?
Based on the description of the DE2 on the Altera website you have the following IO interfaces on the DE2 board:
Built-in USB-Blaster for FPGA configuration
Line In/Out, Microphone In (24-bit Audio CODEC)
Video Out (VGA 10-bit DAC)
Video In (NTSC/PAL/Multi-format)
RS232
Infrared port
PS/2 mouse or keyboard port
10/100 Ethernet
USB 2.0 (type A and type B)
Expansion headers (two 40-pin headers)
Of these there are 3 that are probably the most suitable for your purpose:
RS232
10/100 Ethernet
USB 2.0 (type A and type B)
Which one to use depends on your bandwidth / latency requirements, reliability, what sort of software interface you need, timescales, previous experience and level of interest.
RS232 should be easy to get working, there are UARTs available on OpenCores that will get you up and running but the bandwidth will be pretty awful.
Writing some RTL that communicates with the PC via Ethernet packets should be pretty straightforward if you assume the network is always reliable. Clearly if you want it to be robust you'll need to look into adding some reliability layer like RUDP.
Communicating via USB is probably the hardest interface from both the RTL and software end of the interface, however if you have an existing example design than you can modify to suit your purpose this might be the best option.
One other possibility worth considering is to embed a processor the Altera NIOS II in the FPGA like and let that handle the interface to your host. You could run a full Linux instance or a bare-metal stack with a dedicated TFTP to transfer data around. There are various examples and tutorials on the web that will help you get started.

Transfer data using NDIS

I am working on fpga firmware, in which i want to have very fast data transfer using ethernet . I got help from FPGA forum they say that suggest designs for data transfer using light weight internet protocol (LWIP).
How this is different from transfering the data using NDIS. I will be grateful if you can suggest me some guide to interface my visual c++ application to the network guide and tranfer the data.
many greeting in advance.
LWIP is a library for talking IP on a network.
NDIS is a specification for how an OS talks to network cards.
Neither is necessarily what you appear to want.
If you want to transfer data very simply and quickly point-to-point using Ethernet, you need to understand how Ethernet works at the packet level, and form your data into some Ethernet packets. You can make up your own protocol for this if you have control over both ends of the link.
If you want to transfer the data over an existing network topology, you would be better doing it using an existing protocol. UDP/IP might be one such protocol, depending on your requirements for data-rate, latency, software complexity, reliability etc. LWIP is one library which implements UDP, so might be of use.

Resources