SSerial hardware implementation?

The stepgen thing was a firmware issue, that got sorted out. The SS thing also got at least partially fixed. it now loads with the correct version (42 or 43 IIRC) but I'm still not getting through the handshake with the 8i20. At this point it's kind of difficult to verify the hardware or the firmware because neither is known to work.

The only thing I can think of to do is scope my board for a handshake again. Any insight on what I would be looking for on the boards transmit line when starting up LCNC/MK? I previously saw a few blips but nothing substantial but at that point the firmware was obviously broken.

At the beginning, the host should send a 0xDF [CRC]
and the 8I20 should respond with 0xAA [CRC]

PCW,

It *looks* like it's working in MK at least at the firmware level, yet I still can't get through an instantiation process. Messed with it quite a bit still not getting anywhere.

The "minimal host adapter" example in the 8i20 manual explains that programming can be done with rs232. would this work just for hal recognition as well? Trying to eliminate hardware as an issue.just straight from the 3.3v gpio used as SS to the 8i20 "TXB, and RXB"

The Git issue if you have any insight.
github.com/machinekit/mksocfpga/issues/107

After sorting out some firmware issues and me messing with my board I was able to get discovery of the 8i20. There are apparently comm faults right after the handshake that I'm trying to narrow down to MK's hm2 drivers that seem to be lagging behind LCNC's.

On start the 8i20 is recognized and the sserial pins are instantiated, the 8i20 flashes it's status light, then throws the fault light. The 8i20 pins all appear in hal but apparently the SS port has been shut down after ~200 comm errors on the sserial.0.fault-count pin.

At the moment I just have a resistor divider bodged in to bring the receiver output down to 3.3v levels, which is probably not ideal but I'm told it should still be fast enough. I guess the question is, does HM2 do discovery at a lower baud rate then switch to a higher speed afterwards or something else that would allow discovery but fault immediately afterwards.

I'm trying to determine if the hardware is probably good enough that I can say that the driver probably needs work.

No, the baud rate is constant from discover to servo thread process data transfers.

So is it safe to assume that since discovery is successful that comm issues are post discovery driver issues and not HW/FW related?

So I picked up a 7i66-8 to mess with. I plug it into my rs-422 port and it discovers the board and I can read and write all of the I/O. So I suppose there's some sort of issue in MK's 8i20 hm2 driver unless there is something different hardware wise about how the 8i20 does SS?

There's no hardware difference but there is specific driver support for the 8I20
(and the 7I64) both of these cards were designed before the full auto-discovery
support was added to sserial so the driver has to know specific things about
those cards. Maybe the MK driver has some bugs in 8I20 support or the driver
code is too old to work with newer firmware+8I20. I would think the sserial driver
stuff could be ported pretty easily from LinuxCNC
(I dont think it has changed much in the last couple of years)

I did take a peak at the 8i20 driver in MK and it does appear old, obvious differences between it and 2.8pre1's included version, though I'm not the person to say really.

quick hardware question if I may.....parallel termination is only necessary on the host receiver side right? I've seen examples where it is only done at the end of each receive line, and Ive seen it done at both ends of each line. It works either way but I see conflicting info about this, leaning towards it only being necessary on the receiver ends but not sure.

not sure if Andy watches this thread but I’m curious if there was ever a time that the hm2 driver had to be updated to match an 8i20 software version.

I’m not sure what version MK derived the hm2 SS driver from, but my 8i20 reports a sw version of 139 and the hm2 board firmware reports a SS version of 43 on startup. The MK SS driver has obvious api changes but the code appears to differ further than that from 2.8’s driver.