LinuxCNC-RIO - RealtimeIO for LinuxCNC based on FPGA (ICE40 / ECP5)

meister wrote:

1. Created a folder ./gtc_custom/mpg/ (i.e. under /Output/LinuxCNC/)
2. Placed mpg.hal inside it (see attched source). 
3. Riogui -> Linucnc -> INI-Defaults -> HAL -> HALFILE (custom) == "./gtc_custom/mpg/mpg.hal"

For the moment this works wonder. Although I bet there are better ways to do it in Rio but I'm way too noob at it still. 

Only source code I've had to change was for the board family to be recognized as a its high-speed C7/i6 type.

/riocore/riocore/boards/MecanixDev/board.json
[-] "family": "GW1N-9C",
[+] ​​​​​​​"family": "GW1N-9C7",

/riocore/riocore/generator/toolchains/gowin/toolchain.py
Line 103:
[+]  if family == "GW1N-9C7":
[+]  prj_data.append(f' <Device name="{family_gowin}" pn="{ftype}">gw1nr9c-017</Device>')

That was the reason my PIN03, PIN13, PIN 15 (high speed bank) was not working. The Gowin was always compiling for a C6/I5 fpga type
But allpins works now!!

meister wrote:

Code:

You'll have to find out for yourself what's so special about it, I only say HAL of hell :P

 

I'll have a look at your HAL, thanks, maybe I can integrate it, but you can also write your hal-file here:

Output/Mecanix/LinuxCNC/postgui_call_list.hal

rio does not overwrite anything in this file when generating

---

yes, it should be something like that, only with the wled plugin,
but that's not what I wanted to show

it's about the new killer feature

you can now write logical links including round brackets in the 'net' field

Sure, as I've suspected there's countless ways to do it better in Rio. Brilliant kit!!

That mpg.hal integration would sure be nice. Not saying this for convenience for myself, but more about the fact that those analog MPGs are extremely common, inexpensive and functioning reliably well. Wired-Rulez!!

I'll have a look at that epic conditional net's (bracket or !bracket) [FEAT]. Haha awesome, just noticed the potential power of that thing; from useless zero-conditional HAL design -to- RIO conditional programming-like HAL. Who would have tought. O M G!! 

I'm going to have to disagree with you on the need for pull up or pull down resistors on inputs, especially with switches (unless the switch is switching to either zero or 5v)and rotary encoder that have an open collector output. Without a pullup or pull down resistor the input is going to float, until that input has a definite logic level on it. With high impedance inputs it requires very very little current to switch the input, if the voltage is at the right level. Generally on a chip such as the venerable 74xx245 when the enable inputs are in the disable state the output is considered to be in a "high impedance state" and is unable to "drive" the outputs.
Honestly any input that is connected via a cable needs a pullup or pulldown resistor for the case of a breakage in the signal wire, especially with an MPG, if teh signal wire breaks you want that input at the board end to held at a known level. The last thing you want is for your input to pick up stray noise and start oscillating. The chip wont "know" if it is a legitimate signal or noise and will pass that on to the other side.
That's why sometimes I feel am opto isolator is a bit better in this respect as the current required to drive the LED in normal situations is a little higher than induced noise in the line.

Never in my life have I designed a digital circuit that takes external off board signals with pullup or pulldown resistors, or inputs that get the input from a SPST switch from an on board switch without a pullup or pull down.