EMC: 03cmorley 07TRUNK * 10emc2/src/hal/classicladder/protocol_modbus_master.c: fix wrong length of responce calculation of write registers
I've figured out enough about ghdl to make a test bench that reads and writes unix standard I/O
now where's the dotted "cut here" line so that I can have my test bench fondle the data and address bus of 5i20?
you are trying to simulate driver <-> fpga interaction?
don't you need a file of test vectors?
I think the communication from the hostmot2 userspace component will be something like 'w <addr> <value>' 'r <addr>' or 'x <fpga cycles>'; to 'r <addr>' there will be a reply with some 32-bit numbers
seems like every driver outb or inb will need to be turned into bit twiddling
still trying to wrap my head around what you want to do
you may need the local bus control lines as well (R/W ...)
and address of course
load a tweaked version of the driver, that does the w <addr> <value> stuff instead of outb/w
then load as another process the FPGA emulator
but the fpga emulator will probably be running hundreds of times slower than the rest of EMC
oh, cool then :)
so that you can for instance investigate the behavior of stepgen without running a real mesa card
jmkasunich: that's OK -- sim rtapi will just run very slow compared to wall time
will you somehow sync everything to the simulated FPGA clock, so that EMC doesn't .... OK
if it blocks waiting for the reply to a 'r <addr>' command, it'll just block all the simulated rtapi threads until it returns
probably won't run the simulated mesa at 50MHz anyway .. might still get useful results running it at 100kHz
a lot of work before it would get to that point; i wonder if it's worth my time
that driver should (in theory) just be an equivalent to hostmot_pci
or hm2_pci (however it's spelled)
since (again in theory) the physical I/O is in a separate layer from the functional part
have at it :)
i'm having at other stuff atm ... ;-)
yeah, same here
huh, linuxcnc.org down?
or just slow
ah there it goes
hey jepler a couple of years ago you added a rm in the debian/rules.in for the HAL_User_Manual.pdf
I'd like to split that part out of the integrators manual so do you mind if I undo that?
08:39:16 <jepler> last I knew, the hal manual was repeated in its entirety in the integrator manual. so there was no point in having both
08:39:32 <jepler> the mpurpose of the hal manual is for the nearly-mythical person who wants hal without emc
08:39:38 <jepler> s/mpur/pur/
08:39:59 <jepler> if that's changed, then remove the line that removes the pdf, and add the right line to emc2.files.in for it
so yes if the hal manual is not just duplication of material in the integrator manual, then you should get rid of the 'rm' and add it to emc2.files.in
yes I will remove the duplicate from the integerator manual
jmkasunich: built 5i20 bitfile on windows from spec2bit.py
still haven't tested
I've tested today trivkins with perpendicular correction and it works perfectly
free mode with no real correction, only in coords mode is applied
wiki page barely available here
[Global Notice] Hi all, Terribly sorry for that network burp -- appears one of our sponsors decided to reboot the server without warning, affected users in the region of 2,000. We apologise for that mishap and hope you have a nice day!
micges: yes, the hosting service for www.linuxcnc.org and wiki.linuxcnc.org seems to be having some problems this morning.
I see, where to put kins mentioned above ? it was tested and I want to put in public
on the wiki, when it's available again