What is required to run on an unsupported target?

[ortix]

In my student team (Project MARCH) we are looking for a C++ framework which we can use for our Xilinx Zynq 7000 SoC. It's an FPGA and ARM processor on a single chip. For now we use the ARM to do all our work.

Re-inventing the wheel is rarely a good idea, hence we are looking for a framework which handles our peripheral communication and such.

I haven't had time to go through the source code yet, but what would be required to get XPCC to work for our SoC? Is it worth the trouble? Are there any alternatives if this doesn't pan out?

[salkinium]

https://github.com/Ortix92/Project-MARCH

Is this Project MARCH? A PHP Framework?

I'm not entirely understanding your hardware setup, since the Zynq-7000 is powered by a dual-core ARM Cortex-A9. You surely are running some Linux on that, rather than barebone code?

xpcc does compile for Linux, but it's more of an afterthought and peripheral support isn't very comprehensive (mostly because Linux is the de-facto standard, don't need to reinvent the wheel ;-). Note that xpcc is designed for running barebone on AVR and ARM Cortex-M microcontrollers.

So, Linux is probably the better choice, particularly if you want to interface with the FPGA.

[ortix]

No that's the website ;) We are building an exoskeleton where there is a Zynq in every joint for motor control and DAQ (long story short).

Currently we run all our code bare metal. We use the tool chain provided by Xilinx to compile our code to run on the ARM.

We do not have plans to interface with the FPGA for now. There isn't that much time to build our controllers to run on the FPGA this year.

So would you recommend xpcc for our use case?

[ekiwi]

I haven't had time to go through the source code yet, but what would be required to get XPCC to work for our SoC?

Unfortunately, xpcc does not currently have Cortex-A9 support. While we might want to change that in the future as we are considering moving our robot hardware to a ZYNQ7000 based setup, this will take some time.

Is it worth the trouble?

To be honest: as you have no dependency on any xpcc functionality at the moment - imho - it would not be worth it.

Are there any alternatives if this doesn't pan out?

Yes, you can check out RIOT-OS, which has at least some experimental support for ZYNQ: https://github.com/RIOT-OS/RIOT/pull/3491

From this pull request you can see, that it takes quite a lot of code to port to Cortex-A9 (just like xpcc, RIOT-OS normally is targeted at the Cortex-M series from ARM)

I hope this answers some questions.

[ekiwi]

Currently we run all our code bare metal. We use the tool chain provided by Xilinx to compile our code to run on the ARM.

Doesn't Xilinx offer support for FreeRTOS? I think I have seen an app note on running Linux on one core and FreeRTOS on the other.

Re-inventing the wheel is rarely a good idea, hence we are looking for a framework which handles our peripheral communication and such.

I have not looked too much into the ZYNQ stuff, but as far as I understand, the Vivaldo IDE from Xilinx automatically generates peripheral drivers for the soft peripherals on the FPGA. Are there problems with their implementation?

I am very interested in hearing your reasons for trying to find alternative software to the Xilinx offering, since - as already mentioned above - we at the robotics club are considering moving our robot to a ZYNQ based platform.

[ortix]

@ekiwi I did some further research and there was just a fundamental misconception from my side on what xpcc does. I come from a background of php and java where I'm used to using frameworks which kind of "fix" the way you develop the software. The structure is laid out and you don't have to think about how to implement certain things.

With our project I was hoping to find the same so we would have a solid low level foundation. Obviously we can interface with our peripherals by using simple calls to xil_spi_transfer() and things like that. However, we were looking for a more thought out framework which also has some sort of structure laid out.

What I learned, however, is that such a framework really limits flexibility which is exactly what C++ gives us. So instead we will continue soldiering on with our own "framework", but we will spend more time coming up with a solid structure.

So to come back to our use of the Zynq SoC. It is a very powerful system and I think once you get used to the toolchain, it's an immensely beneficial piece of hardware. The ARM and the FPGA together is a very smart move. Having them communicate is a bit tricky. We haven't tried that yet, but I would definitely recommend it if you are not as pressed for time as we are.

[ekiwi]

I think we can close this issue. If the need arises, feel free to reopen.