zephyr

History

Gerard Marull-Paretas 79e6b0e0f6 includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h> As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>. This patch proposes to then include <zephyr/kernel.h> instead of <zephyr/zephyr.h> since it is more clear that you are including the Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a catch-all header that may be confusing. Most applications need to include a bunch of other things to compile, e.g. driver headers or subsystem headers like BT, logging, etc. The idea of a catch-all header in Zephyr is probably not feasible anyway. Reason is that Zephyr is not a library, like it could be for example `libpython`. Zephyr provides many utilities nowadays: a kernel, drivers, subsystems, etc and things will likely grow. A catch-all header would be massive, difficult to keep up-to-date. It is also likely that an application will only build a small subset. Note that subsystem-level headers may use a catch-all approach to make things easier, though. NOTE: This patch is NOT removing the header, just removing its usage in-tree. I'd advocate for its deprecation (add a #warning on it), but I understand many people will have concerns. Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>		2022-09-05 16:31:47 +02:00
..
src	includes: prefer <zephyr/kernel.h> over <zephyr/zephyr.h>	2022-09-05 16:31:47 +02:00
CMakeLists.txt	cmake: Update cmake_minimum_required to 3.20.0	2022-07-04 10:18:45 +02:00
README.rst	samples: drivers: fpga: merge both samples and add sample.yaml	2022-07-18 10:28:08 -05:00
prj.conf	drivers: fpga controller: add eos_s3 fpga driver	2021-09-03 09:54:00 -04:00
prj_shell.conf	samples: drivers: fpga: merge both samples and add sample.yaml	2022-07-18 10:28:08 -05:00
sample.yaml	samples: drivers: fpga: merge both samples and add sample.yaml	2022-07-18 10:28:08 -05:00

README.rst

.. _samples_fpga_controller:

Zephyr FPGA controller
######################

Overview
********
This module is an FPGA driver that can easily load a bitstream, reset it, check its status, enable or disable the FPGA.
This sample demonstrates how to use the FPGA driver API and the the FPGA controller shell subsystem.
Currently the sample works with [Quicklogic Quickfeather board](https://github.com/QuickLogic-Corp/quick-feather-dev-board).

Requirements
************

* Zephyr RTOS
  or
* Zephyr RTOS with shell subsystem enabled (for shell application)
* [Quicklogic Quickfeather board](https://github.com/QuickLogic-Corp/quick-feather-dev-board)

Building
********

For building on QuickLogic QuickFeather board:

.. zephyr-app-commands::
   :zephyr-app: samples/drivers/fpga/fpga_controller
   :host-os: unix
   :board: quick_feather
   :goals: build


To build the FPGA Controller shell application, use the supplied
configuration file prj_shell.conf:

.. zephyr-app-commands::
   :zephyr-app: samples/drivers/fpga/fpga_controller
   :host-os: unix
   :board: quick_feather
   :conf: prj_shell.conf
   :goals: build
   :compact:


Running
*******

See [QuickFeather programming and debugging](https://docs.zephyrproject.org/latest/boards/arm/quick_feather/doc/index.html#programming-and-debugging) on how to load an image to the board.

Sample output
=============

Once the board is programmed, the LED should alternately flash red and green.

For the FPGA controller shell application, after connecting to the shell console you should see the following output:

.. code-block:: console

    Address of the bitstream (red): 0xADDR
    Address of the bitstream (green): 0xADDR
    Size of the bitstream (red): 75960
    Size of the bitstream (green): 75960

    uart:~$

This sample is already prepared with bitstreams.
After executing the sample, you can see at what address it is stored and its size in bytes.

The FPGA controller command can now be used (``fpga load <device> <address> <size in bytes>``):

.. code-block:: console

    uart:~$ fpga load FPGA 0x2001a46c 75960
    FPGA: loading bitstream


The LED should start blinking (color depending on the selected bitstream).
To upload the bitstream again you need to reset the FPGA:

.. code-block:: console

    uart:~$ fpga reset FPGA
    FPGA: resetting FPGA

You can also use your own bitstream.
To load a bitstream into device memory, use `devmem load` command.
It is important to use the -e option when sending a bistream via `xxd`:

.. code-block:: console

    uart:~$ devmem load -e 0x10000
    Loading...
    Press ctrl-x + ctrl-q to stop

Now, the loader is waiting for data.
You can either type it directly from the console or send it from the host PC (replace `ttyX` with the appropriate one for your shell console):

.. code-block:: console

    xxd -p data > /dev/ttyX

(It is important to use plain-style hex dump)
Once the data is transferred, use `ctrl-x + ctrl-q` to quit loader.
It will print the sum of the read bytes and return to the shell:

.. code-block:: console

    Number of bytes read: 75960
    uart:~$

Now the bitstream can be uploaded again.

.. code-block:: console

    uart:~$ fpga load FPGA 0x10000 75960
    FPGA: loading bitstream