Machinkit Mesa support is getting thin

Based upon findings related to this not yet solved bug I yesterday took a look into the newest mesa hdl sources I could find.

I found that a lot of development effort has gone forward in the mesa development team, so much in fact that the new hm2 registermap is highly incompatible with our current current mksocfpga repo. (not really the problem however) I sorted the source file out of the 1 folder delivery setup into a mksocfpga compatible folder structure and placed it online in this archive which makes it easy to compare with the mksocfpga/HW folder for all interested.

The reason I'm placing this issue here is that Mesa has released new hardware (like the ethernet boards 7i79, etc), machinekit currently cannot run with. The mesa development effort has also evolved quite a lot of the hostmot2 drivers currently used in Machinekit . Machinekit is (supposed to) be compatible with the mesa hardware. (this also means newer mesa boards ?).

Current situation is that Machinekit Mesa compatibility is moving towards a thin ice situation. Unless some team effort is produced, its likely more bugs like this unfortunate one will break the surface.

Playing the ketchup game: (catch up....) Porting these new hostmot2 SW additions evolvements and bug fixes from the Mesa team requires knowledge of how Machinekit is currently different than the Lcnc ways (like pins instead of parameters)

While porting on the HW mksocfpga side is mostly a straight cut/copy paste job, when so needed.

Any SW volunteers ?

@the-snowwhite

I have a 7I92 and 7I77 prepared for a project for which I plan to use Machinekit. (I just have too many projects and too little time for them all.)

I remember that when I bought them I tried with motors and all and it was working - I think - both in Machinekit and LinuxCNC. However, the situation may have changed. I can test it as a just 7I82 or with 7I77 connected. (I cannot test it operatively with motors, the system is silicon controlled 3-phase rectifier with back-to-back thyristor bridges and as I went with the cheapest solution possible, the transformer has about 150 kg). So, if it doesn't work, I will have to work on the support.

Of course, the problem might be - for the team effort - that you need the hardware.

My problem was using a 8i20 with a de10 nano over SS, which admittedly is probably a rather minor use case in MK. Not really even one that I need to work, I'm just trying to verify SS compatabillity.

I'm not sure if the raspberry pi4 has been a thing with MK yet but Mesa has been sitting on the 7C80 for a while now due to the inMux input driver needing work. I checked today and it's been released. If there is a card that needs support in MK I'd say it's that one. Granted, it's not cheap, and it's bleeding edge but since the Rpi4 is actually rather decent in it's performance, a Rpi4+7C80 is going to be a rather serious little machine controller package. http://store.mesanet.com/index.php?route=product/product&product_id=345&search=7c80

From an MKsocfpga standpoint, all that really matters is remote card support. The socfpga board is the host mesa card so realistically I suppose all you would really want to do there is plug in a SS card and extend functionallity.

and on the front of needing hardware for testing, I'd almost be baffled if one of the MK devs couldn't reach out to Mesa and see if they could supply a couple of the newer boards for testing. Peter Wallace is aware of the MK movement, as a vendor I'd think they'd be happy to supply hardware for a support effort. Could only lead to more hardware sales

Well to be totally honest: I may have startled somewhat when I noticed that the Mesa-dev team actually have changed a lot of the hm2 HW register address, however as the hal software drivers probe the register addresses from the hm2 hardware rom, the software is mostly unaware or where the actual registers physically reside. Ensuring backwards compatibility at least to some extent

What has me somewhat heated is the fact that for me the Mesa-firmware was the means to connect a software group to the for me beloved socfpga technology that still IMHO has a great unexplored potential that I'm struggling to make more clearly visible. Instead of being able to innovate from the fpga side with a handshake to the SW side I still have to do both (and I still really suck at traditional SW like demonstrated recently in the arm64 port... :-) ) (that and the feeling of vast empty space in the current MK group)

The new baby on the block Ultra96 has on the side line a "binaural network (AI)" template for vision recognition that comes with it for free(I'm thinking that could be handy for something like a pick and place machine or recognizing bamboo sticks for machining).

On top of that the HDL compiler company (Xilinx) has just released a free licence for Partial Reconfiguration of the ultra96's fpga fabric as a worlds first which is uncharted territory in the open source world.

The energy I could spend on making showcases of what these things can bring to machinekit is spent on doing (sw) stuff others can do much more efficiently than my patient, slow and systematic slogging.

The worry for me is that seen from this perspective the Mesa compatibility is the store front that attracts the crowd that then (hopefully) I can handshake with on both the Hardware (Electronics) and software (Machinekit) side from within the (incomprehensive for most) fpga fabric side and let the magic synergy of innovation (hopefully) start to happen.

So If those who already have mesa hardware (and can program) could somehow, get more involved I'm ready to go much further into fpga driven innovation and co-create some new stuff....... :-)

P.S (edit) I's a bit like the old saying: You can drag the horse to the water but you can't force it to drink....

On 30 Sep 2019, at 00:51, Michael Brown notifications@github.com wrote:

Playing the ketchup game: (catch up....) Porting these new hostmot2 SW additions evolvements and bug fixes from the Mesa team requires knowledge of how Machinekit is currently different than the Lcnc ways (like pins instead of parameters)

Unless I’m mistaken, parameters should still be supported and still work.

Having discussed this a while ago with Michael H, the Cython bindings do not (intentional !!) support parameters.

Pretty much all you could do with a param, you can do with a pin. So we changed to pins as much as we could.

On 30 Sep 2019, at 03:29, Michael Brown notifications@github.com wrote:

Well to be totally honest: I may have startled somewhat when I noticed that the Mesa-dev team actually have changed a lot of the hm2 HW register address, however as the hal software drivers probe the register addresses from the hm2 hardware rom, the software is mostly unaware or where the actual registers physically reside. Ensuring backwards compatibility at least to some extent

What has me somewhat heated is the fact that for me the Mesa-firmware was the means to connect a software group to the for me beloved socfpga technology that still IMHO has a great unexplored potential that I'm struggling to make more clearly visible. Instead of being able to innovate from the fpga side with a handshake to the SW side I still have to do both (and I still really suck at traditional SW like demonstrated recently in the arm64 port... :-) ) (that and the feeling of vast empty space in the current MK group)

The new baby on the block Ultra96 has on the side line a "binaural network (AI)" template for vision recognition that comes with it for free(I'm thinking that could be handy for something like a pick and place machine or recognizing bamboo sticks for machining).

On top of that the HDL compiler company (Xilinx) has just released a free licence for Partial Reconfiguration of the ultra96's fpga fabric as a worlds first which is uncharted territory in the open source world.

The energy I could spend on making showcases of what these things can bring to machinekit is spent on doing (sw) stuff others can do much more efficiently than my patient, slow and systematic slogging.

The worry for me is that seen from this perspective the Mesa compatibility is the store front that attracts the crowd that then (hopefully) I can handshake with on both the Hardware (Electronics) and software (Machinekit) side from within the (incomprehensive for most) fpga fabric side and let the magic synergy of innovation (hopefully) start to happen.

I’m afraid I do not understand how reconfigured fpga will work when your hardware is static (the real world connection, resistors, transistors, diodes... the physical components), but that’s not a discussion for this thread. I only mention it because I do not think that by providing software x on platform y people will magically start developing their hardware/cape solution. The majority will wait until someone has done the hard work (you) and expect/badger for support. (Call me a cynic).

There will be “a new baby on the block” each 9 months, and people tend to want to use anything that’s 0.50 euro/pound/dollar cheaper than the previous. Then the dev board has a life cycle of 2 yrs. where’s value in that? who maintains that? Who carries the cost for the developing for the next big hype? The developer, and not the maker buyer who does not want to spend a bit more money, chasing latest versions. (End of rant).

How does the mix of “old” cards like the mesanet 5i20/25 (which because of their long life are suitable for industry) fit with all these new boards that have a new feature x each year?

Porting the latest current hostmot to MK is silly if there is no way to easily update/pull/maintain future changes.

So If those who already have mesa hardware (and can program) could somehow, get more involved I'm ready to go much further into fpga driven innovation and co-create some new stuff....... :-)

I have a 5i20 for a 7i30 and 7i42TA, a 5i25 + 7i76, and a DE0 nano with db25 board. I’m not afraid to buy 1 or 2 other boards if I can potentially use them for projects.

But here’s the thing, I have a lot of stuff going on, and I cannot commit to developing the way things tend to go now.

I can help merge stuff, I can change Parameters to pins, load and run bitfiles etc, but the way these projects seem to happen is that there are these huge chunks when there is an overhaul. Frequently done by one person.

The big challenge: can such a project/undertaking be done with small enough PRs, so that it is done by multiple people, instead of one person. Otherwise it’s a fallacy to think that multiple people are developing, and in reality it will be only one or possibly two, and the rest must wait for the huge chunk to be committed. And that’s not how it should work. It will drive people to burn outs and leave the project.

I’m afraid I do not understand how reconfigured fpga will work when your hardware is static (the real world connection, resistors, transistors, diodes... the physical components), but that’s not a discussion for this thread

The understanding of Partial Reconfiguration is a (very) new open source option So I will grasp every opportunity to explain(even this straw: The new PR option also includes all the fpga's in the existing mesa lineup): Now it is possible to have static regions inside the fpga fabric that remain functionable (static) while other parts can be dynamically reconfigured after a few ms of down time. So your motors and other hardware keep running while you can do HW pid tuning, change/adjust/swap a (vision recognition) filter and much else elsewhere in the fpga fabric....

There will be “a new baby on the block” each 9 months, and people tend to want to use anything that’s 0.50 euro/pound/dollar cheaper than the previous. Then the dev board has a life cycle of 2 yrs. where’s value in that? who maintains that? Who carries the cost for the developing for the next big hype? The developer, and not the maker buyer who does not want to spend a bit more money, chasing latest versions. (End of rant).

IMHO the releases in the fpga related world have a very slow cycle (the DE0 Nano Soc came out 5 years ago, and you can still order one today)(the replacement board that eol'ed it the DE10 Nano is basically a no brain unplug replug replacement because of Terasics consistency) these and likewise products live at least 5 years ... proven.

There will be “a new baby on the block” each 9 months, I havn't yet seen this phenomenon in the under $1000.- class in the socfpga world, but yes in the non socfpga world yes.

How does the mix of “old” cards like the mesanet 5i20/25 (which because of their long life are suitable for industry) fit with all these new boards that have a new feature x each year?

Well so far I have not seen that tendency in the low class socfpga world (speaking mostly from the Altera camp perspective i was stuck in) The "new" Xilinx based (So far unique) Ultra96 has mostly features reserved for the 1000$+ class (like huge space inside compared to all former mksocfpga boards)(except for out of the box 3.3/5v gpio), and the port to this board is perhaps a gamble I do not know (but all the pieces of the port are now finalized and commits spread out over several people not a single one)

Porting the latest current hostmot to MK is silly if there is no way to easily update/pull/maintain future changes. Thanx I totally agree.

I see Mksocfpga appearing mostly as a contender to the Mesa project, that it was born with Hostmot2 in it's belly is just a coincidence.... ..... I have no clue as to how the Mesa developers would react to the (weird hobo) idea of implementing Partial Reconfiguration in the Mesa lineup. As they still seem to be holding the idea of socfpga at an arms length.

The big challenge: can such a project/undertaking be done with small enough PRs, so that it is done by multiple people,

Yep a good challenge seen generally I'm working on that....

machinekit / machinekit-hal

Machinkit Mesa support is getting thin #236