I've been toying with a lot of things recently.
Automated builds of AnyIO FPGA Firmwares
I've been helping John Kasunich a little bit on automating the build of all the
flavors of AnyIO FPGA firmwares--25 in the last emc2 release--automatically.
Presently, the process apparently involves Peter Wallace of Mesa Electronics
manually making edits to a few vhd files and repeatedly invoking the build
process in the Xilinx ISE gui. Hopefully when we're done the process will be
automated, though it may still run for an hour or two (my laptop runs for about
two and a half minutes to produce 5i20/SVST8_4.BIT).
Ladder Logic for AVRs
I took a look at Ladder Logic for PIC
and AVR (GPL), compiled it with wine-dev and tried to port it to the
atmega168 on Arduino boards, but unfortunately I've still got a bug--probably
in the setup of timing-related registers. There's not a direct connection to
emc here, but I know there are a lot of ladder logic fans out there to whom
this might be appealing.
Modbus Slave for AVRs
Then I had a look at freemodbus, a
BSD-licensed modbus slave implementation for embedded systems. I did succeed
in running that on my Arduino, and got it to communicate with both a standalone
modbus master and with emc2's classicladder in TRUNK. I still maintain that
making the modbus hardware interface an inseparable part of classicladder is
the wrong thing to do, but as long as it's the only generic modbus interface
someone's contributed, well, it's better than nothing.
In doing that, I found bugs in freemodbus--its "report slave id" function
seems to be broken, not writing a byte count where it should--and in the
modbus master library used by emc2 TRUNK's gs2_vfd and in my standalone
exercise program--its "report slave id" function is also broken,
by hardcoding a probably-incorrect response length. So was its
read input registers request, for a similar reason.
Of course, my litany of modbus-related complaints wouldn't be complete without
a complaint about the Specification and Implementation Guide for MODBUS
over serial line in
which they explain on page 13 the inter-byte timing requirements of MODBUS RTU,
then immediately say in a "remark" that in fact you should do something almost
entirely different.
Having modified both the client and the server of the modbus protocol before
they would talk to each other, I'm forced to ask: do either of them talk modbus
at all? Good question!
(originally posted on the AXIS blog)