- Posts: 58
- Thank you received: 0
New project, litehm2: a hostmot2 port to linsn rv901t
In theory you could use those 4 unbuffered lines as output, too. But that would mean you have to deal with FPGA levels directly, without the convenience (and protection) of a driver. Also I use 2 of them for UART-debugging during development.
Not 16 ?
I read that there are 10 outputs on J600 or J601 and 6 on the JP4, two buffered and four unbuffered.
Please Log in to join the conversation.
it still needs one more patch for litex-boards.
Try this
Attachment not found
Compilation still doesn't work for me.
Still <TypeError: get_mem_data() got an unexpected keyword argument 'data_width'> and after removing line containing "data with" :
Please Log in to join the conversation.
I loaded rv901t_stock__example_in.bit into flash memory, I get answers to ping.In theory you could use those 4 unbuffered lines as output, too.
I will do more tests later.
Could you compile configuration with all pins available on JP4 and without a serial port?
16 outputs is more than at the LPT port, I think that for many people are enough ...
If this works, you will be able to do 4 Stepgen, 2 PWM and 6 outputs.
This is enough for a milling machine with a fourth axis.
Please Log in to join the conversation.
imgbox.com/JN9HeNH2
Depending on the state of the Toggle signal, at the multiplexer's output you will get either stepgen signals (normal axis), or the PWM signal as a steppe (axis as a spindle).
PWM as STEP.
By switching from the axis to the spindle you will lose position, but this is how it works.
Multiplexer works as buffer too.
Please Log in to join the conversation.
Please Log in to join the conversation.
I can, later this day. I have to think about the implications of not having the serial.
In theory you could use those 4 unbuffered lines as output, too.
I loaded rv901t_stock__example_in.bit into flash memory, I get answers to ping.
I will do more tests later.
Could you compile configuration with all pins available on JP4 and without a serial port?
16 outputs is more than at the LPT port, I think that for many people are enough ...
If this works, you will be able to do 4 Stepgen, 2 PWM and 6 outputs.
This is enough for a milling machine with a fourth axis.
But instead of adding a multiplexer, isn't it easier to do the board modification the way IlyaKw described?
Please Log in to join the conversation.
In case of RV901T you should cut one trace in two places then solder it to GND and add a smd 0805 1k resistor to 3V3. In the end you will get U603, U607, U602, U606 as input and U605, U601, U604, U600 as output ports.
Do you by any chance have more information on where to cut it? A pic, or a link?
Please Log in to join the conversation.
Must be multiplexer.
But instead of adding a multiplexer, isn't it easier
Hardware or software, but multiplexer.
You can't replace multiplexer by add outputs.
The idea of 4th axis is switching the STEP/DIR inputs of stepper (servo) motor controller.
In mode "axis" you can drive motor by g-codes, in mode "spindle" 4th axis turns independent of g-code (as in lathe).
You may use external generator for "spindle" velocity, but you may not drive it from LinuxCNC.
Use of PWM output give this ability.
In other words, in this case, the PWM is in fact frequency generator, it is a trick, but should works.
The <IndexError: list index out of range> is from litehm2.py and use of make command nothing to do with it. (Of course you are right, compilation should be run by make command).
BTW.
I think, most of LinuxCNC users want drive three axis milling machine, or two axis lathe, so the signals for that should be at J600 or J601 connector.
Some users want four axis machine, so 4th's STEP/DIR signals may be at JP4 connector, but should be buffered.
The PWM signals are for advanced users, so these may be unbuffered at JP4 connector.
The multipurpose outputs should be at J600 or J601 connector.
This is to avoid situation when beginers must use unbuffered signals at JP4.
Please Log in to join the conversation.
The <IndexError: list index out of range> is from litehm2.py and use of make command nothing to do with it. (Of course you are right, compilation should be run by make command).
litehm2.py expects an initial firmware.bin and loader.bin to be present. The makefile generates a dummy before calling litehm2.py. Not the best solution, but the least intrusive I could think of at that time.
If it still fails when called from make (and without any lines removed), can you please give me some more output again?
Please Log in to join the conversation.
Of course, however it is the same.
can you please give me some more output again?
Please Log in to join the conversation.
