Відео

Yes, absolutely. That's how I've used it before: the MCU listens for a command, sends a response. But it can do more sophisticated things like the master asking for a periodic sampling of a sensor until sending a "STOP" command.

@@kentindell Ok thanks. Did you use the min protocol with or without "transport protocol"? Will it be possible to use Min with transport protocol in half duplex mode?

@@GaganHCLGupta Yes, it was originally without transport mode and intended to be used as datagram messages. So you can use it like that with a simple controller asking the MCU for a response. For simple systems that's completely fine. For more complex systems, where there might be side-effects from re-send of a request after a timeout, you can add some sequence number to the request (and so duplicate requests are removed) or you could just switch the transport back on.

@@kentindell Ok thanks. Do you know if "Will it be possible to use Min with transport protocol in half duplex mode?"

@@GaganHCLGupta Yes, once the response message has been sent and been ACK'd it should go quiet.

Thank you! It's more than 40 years old and my favorite sweater.

Thank you! It's more than 40 years old, designed on an 8-bit home microcomputer to produce the knitting pattern.

That's a CAN transceiver, not a CAN controller. So only the CANHack functions will work. You can breadboard up a CANHack solution, as described here: kentindell.github.io/2021/02/06/canhack-pico/

@@kentindell I see, thanks for help. :)

It's on the list to do. The MCP2517FD drivers are separate in the firmware source code and in C (they consist of SPI drivers for the bottom half and the remaining driver for the top half). The intention is to cut them into a C SDK and then refer to them in the MicroPython firmware so it's a common code base.

Oh, I forgot: if you don't want to use Thonny you can use rshell (pip install rshell). It's a command line interface to MicroPython that handles the file system as well as jumping in to REPL.

@@kentindell Good to know

You can set an environment variable, but the simplest is to put it in your home directory on Linux: ~/.local/share/libsigrokdecode/decoders or on Windows: %ProgramData%\libsigrokdecode\decoders You can also use the environment variable SIGROKDECODE_DIR to point to where the decoders are.

That's to be expected: the code is spinning round recv(), a frame comes in (via an ISR), it goes off to process it. The time taken to print is actually very slow, and in that time another 5 frames arrive. They're all processed together, the next time round the loop, that printing is very slow, and so on. Instead of printing the whole frame, try printing just the number of frames. And then try removing even that print and simply appending the length to a list, and at the end of the test run printing that list.

You'll get another strange effect on transmitting: if you transmit a list of frames, starting low priority and going up to high priority, the frames will likely be transmitted in priority order except for the first one: the first one starts transmitting as soon as it's put into the controller (assuming the bus is mostly idle) then the subsequent frames are stacked up, with the controller choosing to send the highest priority first.

@@kentindell thanks for the info and support, I’ll take onboard your feedback and experiment some more.

Working on some support for the trigger API so that it can trigger on specific J1939 CAN ID fields. Hope to have something released soon.

That's an error message to say that the CAN controller chip refuses to be reset. It shouldn't normally happen.

It sets the C1CON register REQOP field to 4 (request configuration mode) and then reads the OPMOD field to see if it went into configuration mode. Out of reset this it the default, so it should always be OK after power on. This means either the SPI interface isn't working or the CAN controller chip isn't working. One possibility is that the power supply is below voltage and the controller isn't coming out of reset cleanly. Does it do this on a powered USB hub?

A thought: can you also try adding hard_reset=True parameter to the initialization call?

@@kentindell yes it is usb powered

@@kentindell i do it but i have de same error

i think we cant

The CANHack board has a transceiver but no controller and uses software on the RP2040 to bit bang the CAN protocol. It's primary purpose is to demonstrate CAN protocol attacks. You can run this software on the CANPico board because we designed it to have direct access to the TX and RX pins of the transceiver. It's possible to use the PIO to provide the raw CAN bitstream but there's a lot more to the protocol than just the bits, and the second CPU core would have to be dedicated to the job.

Because the Janus frame includes two CRCs as well as payloads. If you go to 7m06s you'll see the two bit patterns of each sequence printed out.

@@kentindell Ah got it, 2 payload and CRC One is actual while the other is spiking only at 50% sampling point. Each receiver based on their sample point sees different data and CRC, so both acknowledges it. Wondering how the receiver controller managed phase errors and ReSync Jump Width due to more transitions from recessive to dominant introduced due to spiking.

It exploits CAN sync rules: CAN only syncs on falling edges, only once per bit, and only if the previous bit sampled as a recessive.

@@kentindell Thank you very much for your time and explanation.

I don't think the Sparkfun Thing has the same pin layout, but I'm pretty sure if you deal with that with jumper leads then it should work: the CANPico interfaces via SPI and a couple of GPIO pins.

A CAN transceiver has two digital pins: CAN TX is the output of the CAN controller, and CAN RX is input to the CAN controller. Decoding CAN RX is the same as decoding the CAN bus. You can decode CAN TX too: you just add a second decoder to the CAN TX line in the logic analyzer. But the decoder will flag a potential error because the TX line is missing the ACK=0, but otherwise this is fine. Generally you only bother to decode RX because what is sent on TX gets looped back, but you very often want to connect the TX pin to the logic analyzer at the same time because you can then see whether the device was transmitting or receiving: if it's receiving then it will send recessive bits except for ACK=0, if it's transmitting then TX and RX lines will look the same.

It should be fast enough to read a fully loaded 500kbit/sec bus. You can also use the hardware filtering API on the CANPico to cut out frames you want to ignore. If you wanted to look at specific situation you could use the logic analyzer trigger API on the CANPico and a Sigrok logic analyzer running the can2 protocol decoder to see what happened before/after the event. More on can2 here: kentindell.github.io/can2

@@kentindell Thanks. I think that pretty much answers all my questions. I was hoping I could filter before/during/after capture to lessen the load. So that's awesome. Thanks.

Hi! You can use MCP2517FD CAN controllers instead of MCP2518FD - they're functionally almost identical (the firmware runs wiht both).

Good idea, will add to the list!

@@kentindell Thanks :) glad to see you planning for the future too!