MachineKit on BBB running Hostmot2 with Xilinx FPGA

[Jeff Pollard]

Hi,

   I have the 5-19 version of MachineKit running on a BBB on a custom cape I made using a Xilinx Spartan 6 LX9 FPGA.  The current version of board has two 24 bit I/O ports (50 pin connector) that are compatible with the Mesa I/O port.  This version of board has 3V3 on the power pin rather than 5V though (not a big deal  unless you wanted to power a 5V board from the ribbon cable).  The BBB communicates to the FPGA through the TI GPMC bus in 16 bit words.  Since the bus is address/data multiplexed it provides real random access to the memory map in the FPGA without the need for any auto-incrementing of the address or address translation processes.
 
  So far I've run a Mesa 7i30 Servo board driving small servos with 2000 line encoders.  I've also run a Mesa7i44 and Mesa 7i69 Serial to GPIO combination.

  Now I'm trying to get a stepper motor version running.  I can get the motors to turn in one direction, but when I try to go the other direction, I end up getting a joint following error.  This only happens when I try to go in a particular direction(backwards), so it doesn't look like it should be related to the ferror parameter that is referred to in online documentation (but I really don't know).  Does anyone have any ides what I can change in either the ini or hal file to prevent the error from coming up so I can continue some test.

  AIso, I haven't run any latency tests. How does one go about doing that on the BBB?

Thanks,

Jeff

[Michael Haberler]

> Am 25.08.2015 um 19:45 schrieb Jeff Pollard <xylot...@gmail.com>:
>
>
> Hi,
>
> I have the 5-19 version of MachineKit running on a BBB on a custom cape I made using a Xilinx Spartan 6 LX9 FPGA. The current version of board has two 24 bit I/O ports (50 pin connector) that are compatible with the Mesa I/O port. This version of board has 3V3 on the power pin rather than 5V though (not a big deal unless you wanted to power a 5V board from the ribbon cable). The BBB communicates to the FPGA through the TI GPMC bus in 16 bit words. Since the bus is address/data multiplexed it provides real random access to the memory map in the FPGA without the need for any auto-incrementing of the address or address translation processes.
>
> So far I've run a Mesa 7i30 Servo board driving small servos with 2000 line encoders. I've also run a Mesa7i44 and Mesa 7i69 Serial to GPIO combination.

excellent news - industrial strength I/O boards for the BB!

> Now I'm trying to get a stepper motor version running. I can get the motors to turn in one direction, but when I try to go the other direction, I end up getting a joint following error. This only happens when I try to go in a particular direction(backwards), so it doesn't look like it should be related to the ferror parameter that is referred to in online documentation (but I really don't know). Does anyone have any ides what I can change in either the ini or hal file to prevent the error from coming up so I can continue some test.

See subject ' 7i80db hm2_eth stepgen going only one way' a while ago on this list, could that provide a hint?

>
> AIso, I haven't run any latency tests. How does one go about doing that on the BBB?

no different - just run latency-test; should be on the order of 40uS with the 3.8.13-xenomai-r72 kernel

- Michael

>
> Thanks,
>
> Jeff
>
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+...@googlegroups.com.
> Visit this group at http://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.

[Jeff Pollard]

Hi Michael,

   Interestingly, the small change referred to didn't work (for me), but sure did get me to exactly where the change needed to be.
   What did work was before casting the double to a long (as suggested) was to use:  floor (value - 0.5)  on the double value that needed conversion (if it was negative).
   So I'm back off to more testing

   Question:Is there a way to edit a post once it has been posted (rather than delete it and resend)?

Thanks,

Jeff

[Sarah Armstrong]

Jeff 

try reducing the ferror , depends on what you actually have but i think by default if you have not altered it , is something real small like 0.0005 

try it set to something like 0.05 , and see if you get a different result , 

certainly interested in  your efforts with fpga , i'm currently looking at the same idea & thoughts , i was thinking of using Altera , but i must admit i am leaning towards ZYNQ 7000 

at the moment , yet another learning curve in the mix . 

Sarah 

[Jeff Pollard]

Hi,

  Changing ferror was my first attempt at fixing the problem, but that didn't help.  The axis would jog in one direction (positive), but not the other (negative).  Michael's suggestion was spot on.  The correction suggested in the link he provided interestingly enough though didn't work.  I simply rounded the negative double number down before applying the change, and then it did work.  Now the code for stepper through the hostmot2 now seems to works just fine. I read somewhere on the net that the way ARM and x86 handle double to long conversion is slightly different, which seems to have been the problem. 

    So, I've got the stepper, servo with encoder, and the SmartSerial initially tested out.  It all seems to work pretty much as it should.  I'm looking at testing a some more things (UART, SPI and maybe a couple others).  They *should* work, unless more problems like the above crop up.

  I looked at the Zynq, but was taken aback by the cost.  Digikey's lowest cost Zynq is about the same price as a full-on BBB.  I guess if you are building a custom device it might be practical, but adding a Xilinx 144 pin fpga on a simple cape on top of the BBB seems like an easier general purpose route (for me) to take.  I can deal with soldering a 144 pin tqfp.  Big BGA's would not be so easy.  I think the BBB's processor has enough horsepower to do many small CNC applications (certainly it has more than the processors of some CNC machines had just 10 years ago), and with the hostmot2 interface linked in to MachineKit along with a hardware interface cape, it can(should able to) provide the real-time I/O necessary for machines larger than just a Sherline or Taig.  Well, that's what I'm trying for anyway.

Jeff

[automata]

Hi Jeff,

Check the topic: "7i80db hm2_eth stepgen going only one way" in the archives. There is a solution posted by Jeff Epler in the linuxcnc git repo which seems to work for him.

Are you using the FPGA module that you initially made? I had bought one and would like to follow your efforts..

-automata

[Jeff Pollard]

Hi,

  That change (also recommended by Michael) didn't seem to work (by itself).  What I ended up doing was round negative numbers down by first adding -0.5, and then cast the double to uint32 as he had done.

  This is a new version of the FPGA board that uses the GPMC bus on the BBB to communicate with the FPGA, rather than a bit-bang approach.  It runs at full bus speeds, the address is multiplexed with the data on the 16 bit bus, so direct random access to the FPGA register map is possible.

Jeff

[mugginsac]

Is this going to be an available product?

Alan

[Jeff Pollard]

Hi,

  Yes, I plan on making it available.  Perhaps sometime in Feb. (depends on how busy I am/get/don't get)
  You can see a picture of the item here:

http://www.xylotex.com/Xi90.jpg

  It has 3 ports that are like the ports on a mesa 7i90 board.
  I've tested a mesa 7i30 servo board and a mesa 7i44/7i69 combo with it.
  I've also tested stepper control and UART serial with it.
  Because it uses the emmc bus, the software must be run on the uSD, not the BBB onboard flash.
  I used the 5-19-2015 version of MachineKit.
  At this point I don't have a step by step procedure to allow a person to build the necessary files, so it's not ready for "prime time".
  If you have specific questions about it, feel free to ask.

Jeff

[Charles Steinkuehler]

On 1/26/2016 12:05 PM, Jeff Pollard wrote:
> Hi,
>
> Yes, I plan on making it available. Perhaps sometime in Feb. (depends on
> how busy I am/get/don't get)
> You can see a picture of the item here:
>
> http://www.xylotex.com/Xi90.jpg

Very nice looking board! Keep us posted regarding availability!

> At this point I don't have a step by step procedure to allow a person to
> build the necessary files, so it's not ready for "prime time".
> If you have specific questions about it, feel free to ask.

Do you have the modifications you made to the hm2 driver available?

I need to modify the driver to talk to the DE0-Nano SoC (Altera
dual-core ARM + FPGA), and those changes should dove-tail nicely with
any work you've done. The same ARM driver should be able to support
most any hostmot2-like FPGA instance via uio and device-tree binding.

The hm2 driver is already complex enough to understand, we really
don't want lots of derivatives to start showing up. :)

--
Charles Steinkuehler
cha...@steinkuehler.net

[Jeff Pollard]

Hi,

   The files I have still have tons of debug junk in them, so I don't have anything for release.
   Most of the debug stuff was due to my total lack of understanding what was going on with the driver, how it worked, how it interfaced with the rest of the system, etc.
   Actually, there really is only a little that needs to be done.  I think the two main file (on the MachineKit side) are hostmot2.c and hm2_7i90 (or hm2_XXX).
  
   The main file change is the hm2_XXX file.  This is a data interface from the motion software to the bus being used, then out to the FPGA.  In the case of my board, it is to the GPMC bus.  So I need a GPMC setup area.  The setup specifies the physical parameters of the GPMC bus as well as the memory locations, CS select pin to use, transfer mode (muxed or not), and other things that are specific to the GPMC.  Then I have functions to read 32 bits from or write 32 bits to the GPMC bus.  These are called from the llio routines (which are called by hostmot2.c).

  the llio routines are basically reading or writing a byte/word/long from memory  This is memory mapped on the Ti processor (the GPMC) so I'm not sure if this would be applicable to all ARM processors. To read a 32 bit word, I simply read twice, from consecutive locations, a 16 bit word from a 64KB address space in the GPMC bus area using a pointer that points to the GPMC memory word I want to access.  I'm basically reading the FPGA as a memory location in the GPMC space.   Your interface might be able to do a full 32 bits at a time since the SoC has the processor and the FPGA so closely coupled.

    Of course the FPGA firmware needs to be modified to use and respond to the GPMC bus signals, but that's a different issue.  Most of that is handled in a single file over on the FPGA side (again I made several changes to the FPGA side simply as debugging tools and because the original firmware was written for a parallel port).  Once you can read or write a 32 bit word from to the FPGA (in the GPMC case that means two 16-bit reads or writes), the rest of the FPGA firmware takes control, and you don't need to modify any of that unless you want to add customs non mesa boards (custom servo, stepper, PWM, etc.).

  I started with a hm2_XXX for the parallel port.  Once I stripped all of the PP stuff out, the interface is relatively easy.  The hm2_XXX driver really is only an interface between the llio function calls and the FPGA hardware.  I haven't looked at the PCI version of hm2_XXX, but it would probably be a better starting point for a regular bus interface.

  So what I guess I'm saying is that I think you *will* need a separate file for each different ARM processor if they use different memory controllers, or have different memory interface mechanisms.

  What hm2_XXXX file did you start with or are you looking at?  If you are looking at a parallel port version, then yes, it may seem unnecessarily complicated. 

   I can send you a copy of my hm2_Xi90.C file or better yet, if you have a link to the procedure used to put new software in to the MachineKit package, I can try to put what I have in there, as long as users know that it is an *unfinished* version.

Jeff

[Charles Steinkuehler]

On 1/26/2016 2:25 PM, Jeff Pollard wrote:
>
> So what I guess I'm saying is that I think you *will* need a separate
> file for each different ARM processor if they use different memory
> controllers, or have different memory interface mechanisms.

As long as the FPGA can ultimately be mapped into normal memory space
somehow, the hostmot2 driver code should be pretty reusable between
various FPGA ports. In the GPMC case, most of the required setup can
likely be done with the existing kernel module and device-tree
bindings, while the Altera SoC details are setup at compile time (but
should also use device-tree to convey physical addresses and other
details).

> What hm2_XXXX file did you start with or are you looking at? If you are
> looking at a parallel port version, then yes, it may seem unnecessarily
> complicated.

Michael Brown has started work on a uio based driver which I intent to
follow up on and get working:

https://github.com/machinekit/machinekit/issues/865

> I can send you a copy of my hm2_Xi90.C file or better yet, if you have a
> link to the procedure used to put new software in to the MachineKit
> package, I can try to put what I have in there, as long as users know that
> it is an *unfinished* version.

No need to send a PR if it's not ready for merge. If the code is on
github, send a link, otherwise you can send me whatever you've got
directly. Even if the code isn't ready for use, it should give me
most of what I need to support your FPGA and the Altera SoC project
with as much common code as possible.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Sarah Armstrong]

i would also be interested in any drivers , working or whatever , 

i'm currently working on 2 ideas one using the de0-nano as a base 5i25 replacement , connected to a BBB 

and using a plugin pcb  , similar to Jeff's .

yes i agree if we can look at a common driver structure , it's going to help in the future 

i currently have a foot in 2 houses , stick with xilinx or move to Altera . and do we have any benefit in going either way , 

i'm not sure . 

do we want a plugin to say a bbb or a universal fpga board that will work across different boards , be a pc or bbb , or any other up and coming board 

in the future , and have a common api driver , which will make it more maintainable . with only needing a wrapper for any other future input device , 

[Jeff Pollard]

Hi,

  I am totally unfamiliar with github (and the like), but I will try to put up the stuff I've worked on sometime this week. 

  There are two parts of the HM2_XXX file.  The interface between the llio (LLIO or "low level input output") of the MachineKit software, and the actual access to the bus interface structure built in to the FPGA, be that parallel port, GPMC, SPI, I2C or whatever you have set up in the FPGA as the communication port.  I'm not sure which part is the "plugin" and which is the "wrapper", but in any case, the part accessing the physical bus structure will need to be specific to the interface you plan on using between the physical processor and the FPGA.  In my case, I read/write to a memory mapped GPMC location, but it could just as easily be a SPI register in the processor.  The information transferred over to the FPGA gets parsed to create an address in to the "regmap" structure of the FPGA to read or write the registers there.  There is a text file on the FPGA side actually called "regmap" that lists where devices like PWM and encoders are memory mapped.  But you only need to look at that if you are interested in the low level operation of the system, as it is all handled automatically through the hostmot2 software for you.

  Assuming you use standard hostmot2 devices (like PWM, encoder, etc), the API is already built in.  There is a single line in the HAL file that you use to include the device you want to use.  For example, if you have "num_encoders=4" on the line,  the MachineKit software will automatically be setup to use 4 incremental encoders.  There is a file called "encoder.c" in the drivers directory that is used to access the encoders.  You shouldn't need to change this file; the MachineKit software is already setup to use it.  You just need to make sure the specific device you want to use is instantiated when you build the FPGA software.  The instantiation of the various devices you can use is over on the FPGA side and in a single file.  There are a whole load of "PIN_xxxx_xxxx.vhd" files in the hostmot vhdl code that you can choose from for setting up various devices to be compiled in to the FPGA (or you can make your own file).  You just  need to make sure that if you have "num_encoders=4" in the HAL file, that you have instantiated them in the FPGA code (known as "QcountTag" over on the FPGA side).  The rest is automatic and already taken care of.

  So, I think most of what you are looking for is already in place (be they called wrappers or plugins or api, or whatever).  The only main MachineKit side file that you really need to be concerned with is the HM2_XXX file which would be specific to the transfer protocol of the bus structure between the processor and the interface programmed in to the  FPGA.  If you want to create your own device (like some new type of PWM module or weird encoder interface), then you would need to write your own driver (like weird_encoder.c) and add links to the hostmot2.c file to access the new file (as well as create the FPGA code to instantiate it)

Jeff

[Jeff Pollard]

Hi,

  I made a mistake in my previous post where I wrote:

"You just  need to make sure that if you have "num_encoders=4" in the HAL file."
It should have read:" ... in the INI file."

  The INI file is also where you tell MachineKit which low level driver to use, for example hm2_Xi90 for my BBB GPMC interface.  Sara's might be, for example: hm2_de0-nano

Jeff

[Jeff Pollard]

Hi,

  OK, I have made a github directory based on one of Charles' MachineKit directories.  To that I added a new directory in the src/hal/drivers directory called hostmot_soc.  To that I've copied a lot of the files I changed in the machinekit code.  Also needing changes, but I haven't modified in the github yet, are the INI files, and the makefile.  You can see the files first set of files here:

https://github.com/xylotex/MachineKit/tree/MachineKit-ubc/src/hal/drivers/hostmot2_soc

  The files like pwmgen.c and encoder.c are used to communicate with a specific implementation of a instantiated device in the FPGA, and could be moved to a "device" sub directory.  Thus all new FPGA communications modules would be placed there.

   The file hm2_Xi90.c is the file I used to communicate between MachineKit and the FPGA.  This could be placed in another sub directory i.e. "llio" along with other files used to interface between different processors and the  FPGA.  The INI file would have the specific interface program to use.

  I've modified many of the files by adding function demarcation comments while I was learning what-was-what.  So while many of the files may appear "changed" they are functionally identical to the original file.

  Some of the files are most likely not necessary and were only included to allow compilation (without changing the makefile again).  for example I don't think bitfile.c is used or needed in this configuration.

  Currently I use a separate C file to bit-bang program the FPGA through the GPMC port (rather than have it programmed in the hm2_Xi90.c file), but the FPGA could also be programmed automatically with a eeprom or through the jtag port.  The actual way it is programmed would be board level dependent since the programming pins on the FPGA could be routed many different ways depending on the board it is installed on.

  I started with the TopEPPSHostMot2 version of the FPGA code from mesanet.com and modified that by removing the parallel port interface and building in the GPMC interface.  Then on the machinekit side I wrote a stand alone C program that did the same I/O as the hm2_Xi90.c file mentioned above.  There is a memory space in the FPGA where a "cookie" is stored once it has been properly programmed. The value is:55AACAFE and is stored at location 0x0100.  Once you can read that, you can start making your own hm2_XXX file.

  Hopefully that will give people wanting to use hostmot2 with MachineKit a start on how I implemented it.

Jeff

[Charles Steinkuehler]

On 2/1/2016 9:25 PM, Jeff Pollard wrote:
>
> Hi,
>
> OK, I have made a github directory based on one of Charles' MachineKit
> directories. To that I added a new directory in the src/hal/drivers
> directory called hostmot_soc. To that I've copied a lot of the files I
> changed in the machinekit code. Also needing changes, but I haven't
> modified in the github yet, are the INI files, and the makefile. You can
> see the files first set of files here:
>
> https://github.com/xylotex/MachineKit/tree/MachineKit-ubc/src/hal/drivers/hostmot2_soc

Excellent!

Thanks for the link and the details. I'll holler if I have an
specific questions or don't understand something when I get into the
code...probably in about a week or so.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Timm Eversmeyer]

Am Dienstag, 2. Februar 2016 04:25:51 UTC+1 schrieb Jeff Pollard:

  I started with the TopEPPSHostMot2 version of the FPGA code from mesanet.com and modified that by removing the parallel port interface and building in the GPMC interface.  Then on the machinekit side I wrote a stand alone C program that did the same I/O as the hm2_Xi90.c file mentioned above.  There is a memory space in the FPGA where a "cookie" is stored once it has been properly programmed. The value is:55AACAFE and is stored at location 0x0100.  Once you can read that, you can start making your own hm2_XXX file.

  Hopefully that will give people wanting to use hostmot2 with MachineKit a start on how I implemented it.

I have an unused LogiBone [1] which could be used to run hostmot2. I have not found the VDHL code in your MachineKit fork [2]. Would you mind share the GPMC adapter to hostmot2 with me?

Your Beagle Bone FPGA shield looks nice. Looking forward to hear any news.


[1] http://valentfx.com/logi-bone/ 
[2] https://github.com/xylotex/MachineKit/tree/MachineKit-ubc/src/hal/drivers

[Jeff Pollard]

Hi,

  I will have to relearn how to do the whole git/pull stuff (which will take some time).
  And I will have to clean up the files before I do that.......
  In the mean time, if you e-mail me at sup...@xylotex.com I can e-mail you the files.
  I have the gpmc access file currently named  hm2_Xi90.c, but that will probably change
  That code basically sets up the GPMC bus and provides read/write function for the hostmot2 software.  The bit settings for the gpmc configure the bus for multiplexed address/data with specific timing that the bitfile in the FPGA would expect
  If you are going to use the GPMC you will need to disable the emmc in the /boot/uboot/uEnv.txt (or wherever that file is kept these days- I'm still working from an old 2015 version of machinekit).
  Then you'll need to get the vhdl file to match the timing generated by the gpmc bus.  It's currently called topEPPHostMot2.vhd on my computer, but should be renamed to something else as well.  I started with mesa EPP bus stuff to make the gpmc interface and haven't renamed the file.  There is a lot of stuff commented out that should be cleaned up, but dismissing that, you should be able to get an idea of what was done to interface to the gpmc.

  The files I have is for the board (cape) I'm presently working with:

(4) sets of Servo PWM (PWM/DIR/Enable) outputs
(4) sets of Single ended Incremental Encoder inputs along with two inputs for limit switches
(1) Single Ended incremental Encoder input for Spindle
(1) PWM output for spindle speed control along with FWD,REV output commands, and a FLT input.
(1) Single Ended incremental encoder input for MPG (A and B only, no index input)
(1) UART in TTL mode to communicate with a uP on the MPG which encodes axis select and jog rate switches as well as other button inputs
Mist/flood output signals
E-stop signal chain
 
  To see a picture, go here:

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

  Anyway, drop me an e-mail, and I'll try to get you the files you want.

Jeff

[Timm Eversmeyer]

Ok thanks, I'll write you an e-mail.

The FPGA with GPMC is running on my setup. I just disabled all unneeded capes and OS is running from SD-card. It's a debian image running with a near up to date realtime kernel. So I think i will manage to get MachineKit running.

My purpose is using the 2,5mb/s serial interface to connect to https://github.com/rene-dev/stmbl which have the proprietary sserial interfaces. In that case I don't need much IOs.