Advanced Search

PCW wrote:

If you can reliably access the card on the RPI4, you would

sudo mesaflash --device 7c80 --spi --addr /dev/spidev0.0 --write 7c80d.bit
sudo mesaflash --device 7c80 --spi --addr /dev/spidev0.0 --write 7c80fall.bit --fallback

(7c80d.bit and 7c80fall.bit are in the 7c80.zip file in /configs/hostmot2/)
the zip file is available from the store in the card specification tab

 

From Pi4, dump of mesaflash BEFORE flashing: pastebin.com/kf8iUXQY
dump of mesaflash AFTER flashing: pastebin.com/5xm8FHpq

I forced a --reload in between each flash cmd, to validate the card took the firmware before moving on.

If this looks correct, I will proceed to swapping the pi5 back into the machine.

I still believe that spi can be used instead of serial communication and have a real time component.
If possible, have someone with the necessary hardware try this and report back
Many thanks

If you can reliably access the card on the RPI4, you would

sudo mesaflash --device 7c80 --spi --addr /dev/spidev0.0 --write 7c80d.bit
sudo mesaflash --device 7c80 --spi --addr /dev/spidev0.0 --write 7c80fall.bit --fallback

(7c80d.bit and 7c80fall.bit are in the 7c80.zip file in /configs/hostmot2/)
the zip file is available from the store in the card specification tab
 

PCW wrote:

You should be able to with the latest mesaflash

alright, putting the pi4 back in, let me know what needs done.

You should be able to with the latest mesaflash

PCW wrote:

I apologize, this is my fault, some production 7C80 cards ended up with
the wrong firmware. We can issue you a RMA for reflashing the card with
correct firmware. Sorry for the inconvenience.

 
So, since i have a pi4 that can see the card, is it possible for me to flash the correct firmware?

I'd much rather not kill a week plus in cross shipping.

I'd like to try it here if it doesn't require super-specialized equipment, I've made JTAG cables before.

You can download the support software from Mesa's web store
(specification tab)
 

I apologize, this is my fault, some production 7C80 cards ended up with
the wrong firmware. We can issue you a RMA for reflashing the card with
correct firmware. Sorry for the inconvenience.
 

OK the original attempts were with the official raspbian image. The supplied kernel is not one suitable for Realtime in the way Linuxcnc requires a realtime kernel. There was discussion a few months ago reagrding real time being included in the mainline Linux kernels. When building a real time kernel there are 3 options from memory, if you do not choose the correct type it is not what Linuxcnc expects.
It would depend whether the kernel was pinned (excluded from updates or not) but on further reflection the Raspbian kernel is different to the mainline debian kernel for arm boards.
And honestly when you do an update you should have a look at what is being updated. before proceding.
With the Linuxcnc image did you enable the SPI interfaces in config.txt ?
If you had of clearly stated at the beginning you were using a raspbian image to begin with it would have made life a whole lot easier. It would have been suggested to use the Linuxcnc image from the get go.

Just went back on this, you asked mesaflash to verify is the board has the pwm version and it does not, hence the result.
You would need to flash the board first with the firmware you need, and the files are on the Mesa web page
www.mesanet.com/software/parallel/7i96s.zip

Ah, sorry, my bad. I misinterpreted the options. Exchanged 'verify' with 'write' and it worked like a charm.
Correct version:

mesaflash --addr 192.168.1.121 --device ETHER --write 7i96s_2pwmd.bin

Also, thanks for pointing the location of the support package out. This website looks like they went bust 20 years ago...

It might have been nicer if the max travel was calculated based on the length to probe.
ie probe length = 10, max _over_ travel = 5 then anything that moved 15 would trip.

blazini36 wrote:

Yeah Tommy is pretty much correct in the fact that 1.5Mbaud does not equal 1.5Mbit because there are wasted bits.....start, stop, parity, address, etc
 

That will affect the overall byte rate, not the overall bit rate. If fact Tommy's definition made no mention of of protocols, which stop-start-parity etc would be part of.
When designing hardware for the transmission of serial data any control bits or bytes don't come into the equation.

pushed to master:

myHud.display_on_right()

Leme know if there is any problem.

In a purely digital system, one voltage equaling zero (0v) and another voltage equaling 1 (5v) baud rate with be the same as bit rate. It's when they start using voltage levels other than 0v & 5v, as given as the values (this includes single end voltage converted to differential voltages), that the difference starts happening. This is for simple serial comms, have not studied how manchester encoding for example would affect this.

I noticed your definition seems to be google's AI definition.

Yeah Tommy is pretty much correct in the fact that 1.5Mbaud does not equal 1.5Mbit because there are wasted bits.....start, stop, parity, address, etc