Advanced Search

Top! If you need any vector or image I can draw it for you

The cia402 component generates the necessary signalling with the drive's controlword pin.
It has the logic to do state changes and other things required by cia402. Therefore, we don't bother about that, it is all handled by the cia402 component. We just use the cia402 component.

If you want to go your own way, and do the signalling yourself to the drive you write to the drive's controlword lcec.0.0.controlword.
But that is just unnecessary, use the cia402 component instead, connect it as in the example.
You can check the source code for the cia402, it is where the example is.
 

still work in progress, but taking shape!


 

Okay understood. So you imagine something  like SCK ringing in the 20cm cable triggering your SPI logic twice? Fair enough, I'll try adding a .1n or so cap to the SCK line then, maybe that will help.

And .. yes .. as feedback on your(?) product I think it would be nice if there would be an option to have slower SPI with sampling. I have a 7i96 in use since quite a while on a 3-axis router and am quite happy with it, it works well. However, having to use USB ethernet on the other Pi I am using for that (for regular networking) is a bit of an annoyance / issue. This is why I went with the 7C80 now.

Hallo
Langsam komme auch ich zu einen Ende. Habe die Frässpindel Montiert aber den Umrichter ( A2 Serie) noch nicht eingebaut. Probelauf mit den Panel gemacht und sie läuft.
So hier die Frage: habe das Video von Talla angeschaut und will das gleiche nachmachen. Was muss in der HAL Ini alles eigestellt werden damit das vom Bildschirm aus gesteuert wird? Er hat die 5V genommen, anscheinent sind für die 7i96s die 12V zu hoch. Inverter hat einen 5V Ausgang.
Danke schon mal für die Hilfe.
Gruß Hans

Unfortunately, lowering the clock rate does not improve SI issues with the SPI clock itself.
The firmware uses an actual clock pin rather than an oversampled input so any ringing
will be an issue. Its possible to make firmware suited to longer cables but at the expense of
SPI clock rate.

 

Hey PCW,

thanks for the quick reply. Ok, I'll plan on a shorter cable.

However, just to test things out, wouldn't slowing SPI (and if necessary by a lot) help with any ringing and similar transient issues? Or am I missing something? I can only imagine strong crosstalk that would actually causes glitches between SCK and MOSI/MISO to be an issue at slow speeds - and that is surely not expected @ 20cm as it would still be way too short for that?

If you agree, would reducing the rate as I did in spi_boards.c (max in spi_boards_init) work or are there other things that would prevent such an approach?

What does

ip a

report?

I have seen a similar issue when the network GUI used was wicd
which breaks Ethernet connections when setting up a WLAN
(network manager works, wicd is broken or was broken)

All zeros data is possibly a connection or firmware issue.

I would try a short cable though

Note that a 20 CM cable is very likely to be unreliable due to signal
integrity issues (both ringing and ground bumping) The 7C80
and 7C81 are designed for the RPI to mount on top of the card with a
~40 mm cable

Works for me
www.youtube.com/shorts/ZcQjW4829R0

the modbus has some delay, thats why it is a little asynchronous


@Andrew
there is also a template now for your board, but without input yet, would be nice if you can give me your config for the inputs

Hi,

using the prepared OS image "rpi-4-debian-bookworm-6.12.11-arm64-ext4-2025-01-27-0404.img.xz" from linuxcnc.org on a Pi4/4GB, I have no luck talking to my 7c80 board, which is connected with a 20cm ribbon cable to my RPi:

$ mesaflash --spi --device 7c80 --addr /dev/spidev0.0 --readhmid
Unexpected cookie at 0100..0110:
00000000 00000000 00000000
No 7C80 board found

This is both for the system-wide installed mesaflash as well as a separate build straight from github sources as of today.

I am (now) aware that cable length might be an issue here as SPI runs at a swift 20 MHz.

If possible (as replacing the cable with a much shorter one would involve quite a bit of mechanical disassembly and rework of my controller box) I would like to try the SPI connection first at slower speeds.

Is it possible to test (maybe bitbang even?) the SPI connection to the 7C80 FPGA to test whether the whole setup is working in principle? If so, are there any major problems expected then running everything with a reduced data rate (I am only planning to drive two steppers with this setup, so hopefully not a lot of bandwidth is needed)?

Can the FPGA be accessed slowly or are there timeouts preventing this?

I brazenly tried to reduce the SPI speed in spi_boards.c down to various rates, down to 100kHz, but that didn't help.

scotta wrote:

1. Convert an ST-Link to a CMSIS-DAP probe by using a a second ST-Link and the ST-Link utility to flash the CMSIS-DAP firmware.

mvdlande.wordpress.com/2015/10/05/cmsis-...ink-v2-mini-adapter/

2. Use pyOCD with the newly flashed CMSIS-DAP probe to flash the firmware to the controller board

python -m pip install -U pyocd
pyocd flash .\remora-rt1052-3.1.3.bin --target mimxrt1050_quadspi

github.com/scottalford75/Remora-RT1052-c...ora-rt1052-3.1.3.bin
Hello, I'm coming back to the charge on my RT 1052 card, I'm trying to flash with the CMSIS-DAP firmware but I have an error message the card is not detected?

 

 

Today i reran the PnCConf and the Startup Error didn't show.
But the WLAN Problem still persists.

I am running Debian on my Thinkpad T420
The mesa is connected to the Ethernet port and when I connect to WLAN the connection to the MESA Card fails, it happens both with 10.10.10.10 and with 192.168.1.121.

Network:
IP 192.169.1.10 Mask: 255.0.0.0 Gate: 0.0.0.0
IP 10.10.10.11 Mask: 255.0.0.0 Gate: 0.0.0.0

Yes, I had the Ohmic sensing into the B encoder input on TB2.

That's OK with 7i96dpl.bit firmware (that has three separate encoder 'A' pins)