FPGA and Hostmot2

[DeWayne Young]

I am looking to get involved with FPGA and Hostmot2 is there a cape available that i can purchase or even better build? It seems from reading here there are a few people working on this.

My goal is to be able to run the Mesa IO cards direct from the BBB and Hostmot2 cape

Can anyone please point me in a direction as to the starting point and a list of what I need to obtain both hardware and software. I have here a Mesa 6I25 FPGA + 7I76 5 step IO card

Rgds DeWayne

[schoo...@btinternet.com]

Hi

No-one is working on a cape for attaching a Mesa IO card to a BBB AFAIK

What is the advantage of adding a board that is bigger than the BBB via
yet another board, ie a sudo PCI or PCIe interface?

Just plug the 6i25 into a PCI slot on the humblest x86 computer and you
have something that will outperform the BBB with ease.

The work I am aware of is programming SoC FPGA boards to replace
computer plus Mesa board, which is completely different

regards

[Jeff Pollard]

Hi,

  I have a BBB FPGA cape that I have been working on.  You can see it here:

http://xylotex.netfirms.com/OSCommerce/catalog/product_info.php?cPath=27&products_id=106

  I have used it for a PWM servo system with encoder feedback (Mesa7i30), as well as the Mesa 7i69/7i44 pair.
  I have developed the MachineKit interface as well as the VHDL interface, but I have not yet integrated any of  the software in to the MachineKit system repository due to time constraints.
  I have a few of the boards available for $65.00 each + shipping if someone wants to get one, with the provision that the user will need to build the software to make it work (I can give you the files I have).  The system uses the GMPC bus, so the MachineKit software must reside on a uSD.  Using an 8GB+ fast uSD would be best if you are going to develop on the BBB (I developed with a 4GB, but with the machinekit-dev directory a 4GB will start getting full).

Jeff

[Michael Brown]

Hi Jeff

I do not know if you have become aware of the mksocfpga project that now has been added

to Machinekit.

I would like to link you to the origin of this project started 8 months ago in a repo named mksoc:

https://github.com/the-snowwhite/mksoc

Notice the 3 levels of categories in the readme describing much of the full intended scope / idea for 

bring this into life:

mksoc

mksocfpga

and; --> mksoc +fpga 

Which is the category in this scope that fits your hardware perfectly.

For me your bbb cape has 1 interesting component built in that the other fpga platforms either don't have or is way to expensive to add as they cost expensive licenses:

A graphics core that is capable of doing OpenGL  natively via a locally connected display monitor.

The socfpga's can do a simple frame buffer (graphic core less), but I have not found any free addable graphics hdl ip cores worth trying out.

So for non headless applications you have a considerable candidate to add (via PR) to the list under the original broader mksoc hood structure.

Also:  Please excuse me for the late reply .....

[thematsche]

Hi,
sorry for capturing this thread but it's a similar topic.

Is there a package for mk with the hostmot2 includes like the machinekit-dev package?

[Charles Steinkuehler]

On 5/10/2016 7:04 PM, thematsche wrote:
> Hi,
> sorry for capturing this thread but it's a similar topic.
>
> Is there a package for mk with the hostmot2 includes like the machinekit-dev package?

What exactly are you looking for?

The hostmot2 HAL driver source is part of the Machinekit source (in
src/hal/drivers). The VHDL code for the FPGA is in the
machinekit/mksocfpga github repo.

Neither is what I would refer to as "hostmot2 includes", they are full
source trees.

--
Charles Steinkuehler
cha...@steinkueler.net

[thematsche]

Yes, and on some small ARMs it's not the best option to compile the whole sources.
What I'm looking for is a hostmot2 package with precompiled libs and the associated include files.
BTW: I've seen, that there are no branches or tags on the machinekit github repo.
Is this a good idea?
How to determine the state of the packages/libs?
I guess that most of the problems/issues asked here are based on the lacking reference.

For instance:
I'm writing a hm2 spi driver for the raspi2 using the image from gemi. basically it works, but there is an old hostmot2 issue.

http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blobdiff;f=src/hal/drivers/mesa-hostmot2/stepgen.c;h=85060ee764b432f2bade32c875c29b0156508c78;hp=a971847d4da6b8978d2171f800a79ac89c4d2f98;hb=8b536f47153db14bf6001c3c1c7b69bcc84b6389;hpb=e082ca2f983a87357081afdd23e15b45ebe017e7
.
Ok. I updated machinekit with apt-get and now the driver does not work anymore because the headers and the libs does not match.
What's your proposal?
Whenever I change/fix something on this driver pulling and recompiling the whole source tree keeping up to date?

> --
> Charles Steinkuehler
> cha...@steinkueler.net
>
matsche

[GP Orcullo]

Just post a PR so that you don’t have to worry about that ;-)

[thematsche]

And?
Who tests my driver?
Do I have to send my testing equipment to the maintainer?

How can I determine or compare the state of packages or source tree?
It ends up in developer maintainer ping pong.
IMHO.


BTW: the "C4 Collective Code Construction Contract" reads like a licence agreement from apple or microsoft. ;)

[Charles Steinkuehler]

On 5/11/2016 7:53 PM, thematsche wrote:
> On 2016-05-12 01:34, GP Orcullo wrote:
>> Just post a PR so that you don’t have to worry about that ;-)
> And?
> Who tests my driver?
> Do I have to send my testing equipment to the maintainer?

You (or anyone else actually using it) test your driver. :)

There are a *LOT* of drivers that get built that not everyone has
hardware to test (hostmot2, pico-systems, LPT drivers, etc).

> How can I determine or compare the state of packages or source tree?
> It ends up in developer maintainer ping pong.
> IMHO.

Builds are automatically run from pull requests both prior to a merge to
trunk (to mostly verify things still build and pass unit tests) and
after (to run all build permutations and generate packages for release).

The hostmot2 driver is not really intended to be compiled "out of tree",
so you have a few options:

* Send a PR for your driver and get it included in master. Then you
don't have to build anything, you just need to fix any bugs and can
otherwise use the latest packages.

* Setup a self-hosted build: Add some swap (you'll need it) and be
prepared to learn patience...it takes a while to build on lower-end ARM
platforms like the BBB and RPi.

* Setup a build host: Use a powerful ARM board to compile and just run
the code on your target platform. A typical setup would be something
like a quad-core iMX6 or maybe an A53 to build with the source on an NFS
share that can be seen by your target platform. You can just
run-in-place from the NFS mounted build directory for testing.

* Use the available build VMs: The continuous integration that tests
each pull request and builds packages for each merge is freely available
and based on Travis + Docker (IIRC). You can clone part of this
infrastructure and run your own builds targeting your repo if you don't
want to setup a native ARM build machine.

* Modify the build process so the hostmot2 driver *CAN* be built
out-of-tree with just Machinekit-Dev (and not a full source build)
available. If you do this, send a PR!

So basically, if you're building the hostmot2 driver, you're doing
serious development and you need a real build environment. Either push
your code upstream and use the project's infrastructure, or you'll have
to craft your own (unless you feel like tweaking the Makefiles so
hostmot2 can build stand-alone).

--
Charles Steinkuehler

[thematsche]

On 2016-05-12 03:16, Charles Steinkuehler wrote:
> So basically, if you're building the hostmot2 driver, you're doing serious development and you need a real build environment. Either push your code
> upstream and use the project's infrastructure, or you'll have to craft your own (unless you feel like tweaking the Makefiles so hostmot2 can build
> stand-alone).

I bent the include paths and comp did the rest. :)
Now it works with 32 MHz SPI Clk. :)
Strike!

Maybe more later but the real live returns and some projects have to be done at the real job....

[thematsche]

On 2016-05-12 03:16, Charles Steinkuehler wrote:

> So basically, if you're building the hostmot2 driver, you're doing serious development...

No, it's just for fun. :)