This is a nice chip! It’s wakes up into Listen-Only mode, making it a “safer” way to play with logging data. SPI for config and reading (plus the interrupt pin routed to the plank) may allow for an essentially real-time responsive design (PIO + SPI), that just stuffs into a larger BP-side buffer. For example, in response to the interrupt line, PIO could initiate sending the pre-defined SPI packets that:
- read some registers and the new data to a BP-side large buffer, and
- tell the chip that the buffer’s been read (
BIT MODIFYcommand), which clears the interrupt.
For basic logging of the raw data in a single receive buffer, this might be all that’s needed?
other neat bits
- The second receive buffer can be configured as a roll-over buffer.
However, this might prevent the super-simple PIO+SPI real-time dumping of the data, so … win some, lose some? - The chip can be configured to log messages that were only partially transmitted (
RXM[1:0] = 0b11). This is recommended for the super-simple PIO+SPI dumping. - A datasheet gem:
Setting the RXM[1:0] bits to '01' or '10' is not recommended.
Thoughts on future changes
- The
/RXnBFpins (receive buffer full) go low when the corresponding buffer is filled, could these have LEDs (attached to Vdd on the far side)? Thus, if the pin stays low (i.e., plank is locked up) there’d at least be a clear visual indication. - Better yet, if easily done, would be great to have five additional test points (for connecting a LA to track errors)
- one for each of the five specific interrupt pins (
/RX0BF,/RX1BF,/TX0RTS,/TX1RTS,/TX2RTS) - I prefer a through-hole … gives more options than just a test pad
- I need to find a clip I can just place over a TSSOP-20 which exposes the pins in a more probe-friendly form. This isn’t the first time I’ve needed something like that…
- one for each of the five specific interrupt pins (
Overall, this seems a great chip choice for a plank, as it abstracts many of the difficult parts of CAN, while still allowing to get at partially-sent frames. Neat!
