I have created a spreadsheet with the various pin mux options for the header pins.
I have included the datasheet page numbers for the relevant pin mux options as I would advise anyone using it to double check my entries.
I have coloured some of the cells by type to make viewing a bit easier.
If anyone spots any errors, could you please let me know - thanks
bbai64-pinmux.ods (21.6 KB)
Hello @benedict.hewson ,
Seth here. Thank you, sir. I really appreciate you putting forth effort in this matter. Just for reference here, I am highly unskilled, lazy, and full of testing.
So, on w/ the testing!
Seth
P.S. Hello Again, sorry. I see UART3 has, count 'em, three TX outputs. Is this for use on a co-processor or many co-processors?
Hi Seth,
Often on these large MPU’s many functions are available on multiple pins. This is probably to ease PCB layout and to keep pin count down.
I have not checked everything, but I believe every core has access to all peripherals on the chip. You need to check the datasheet - [DRA829/TDA4VM Technical Reference Manual on the TI website. Look at the system interconnect section.
Hi Benedict,
I have a similar spreadsheet I made a while back. So thank you for providing a means for me to cross check mine. I only found two problems with yours:
P8_38 AJ20 (data sheet pg 42) PRG1_PWM2_A1 is mode3, not mode2
P9_33 K24 (data sheet pg 20) MCU_ADC0_AIN0 should be MCU_ADC0_AIN4 (AIN0 is on K25)
Thank you!
Cheers
Hi Jks,
Thanks for checking. I have updated the file on Google drive so the above link is fine.
Corrected pinmux spreadsheet.
bbai64-pinmux.ods (21.7 KB)
I guess beaglebone chose the way that user decide the pin and enroll by uEnv.txt or extlinux.conf, then is it possible to use the pin cross mux mode? (i.e. since mux mode 0 only has one CAN port P9.19, P9.20 as MCAN0_RX, MCAN0_TX, assign P8.5,P8.6 as MCAN7_TX, MCAN7_RX)
Yes, you can use P8.5 & P8.6 as CAN. You just need to set the correct pin muxing and enable the peripheral with an overlay.
/dts-v1/;
/plugin/;
#include <dt-bindings/pinctrl/k3.h>
&{/chosen} {
overlays {
BBAI64-MCAN7 = __TIMESTAMP__;
};
};
&main_pmx0 {
main_mcan7_pins_default:main_mcan7-pins-default {
pinctrl-single,pins = <
J721E_IOPAD(0x88, PIN_OUTPUT, 6) /* AH25: PRG1_PRU1_GPO12 AH25_MCAN7_TX */
J721E_IOPAD(0x8C, PIN_INPUT, 6) /* AG25: PRG1_PRU1_GPO13 AG25_MCAN7_RX */
>;
};
};
&main_mcan7 {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&main_mcan7_pins_default >;
};
If I would want to use 10 CAN for example I would have to write my own devicetree.
Michel
Yes assuming the pins don’t clash with anything else, you would need to create a dts overlay to enable the appropriate CAN modules and set the pinmux to the correct values. It is pretty simple to do. I have a custom cape with 6 CAN running on it.
I just receive a few boards, one is a USB to CAN with MCP2517FD with a CH341a. I wonder if I will need to update the kernel or if the kernel driver would support it even though it is on a USB to SPI device.
I have two custom capes, one with CAN drivers (MCP2562FD) for 5 CAN with some JST connectors and one with just JST Connectors. The first one is for the Beaglebone AI-64 and the other one for the Beaglebone AI (32 bit). That one is the old one and has just 1 CAN, the cape has several JST connectors (mostly 8 pins). I also have one small board for click board that has a small connector to connect with a cable on the beagleplay.
I am writing a gui program with Lazarus that supports GMLAN and J1939 and I want to get it to work with several different CAN boards.
Michel
There is a serial port driver for CAN - slcand (part of CAN utils) - This might work with your USB to CAN boards. You may need to modify it though to configure the
MCP2517FD. I have never used it so can’t say how good it is.
It is not an ideal solution, but handy if your MCU does not have native CAN.
If you really need more than 5 CAN I would suggest creating your own custom cape with more transceivers.
5 CAN is plenty. The display board that I test has 5 CAN, so far I have to test one at a time.
The USB to CAN is for connecting on the computer. I choose the MCP2517FD because the MCP2518FD isn’t available yet (part shortage). That is what we use where I work, as we did a redesign we were not able to get any RL78/F14 at the time so we picked a RL78/G14 and use the MCP2818FD. It works real well with the RL78. I was curious to see how it would perform on the computer and compare it with the ValueCAN. I just do those as a hobby, because of my non compete contract I wouldn’t be able to sell any until after I retire. I am 72, not sure when I will retire, depends when my employer thinks I am too old. Right now they are stuck with me but I am training my possible replacements.
I created a programmer board that I use at work for programming RL78/G14 and RL78/G10 so I don’t have to use the debugger. I program thru a single pin serial which Renesas call tool0. I use a CH340G which is a USB to serial, the kernel module is ch34x. I had to ugrade my yocto ch341x module since my kernel is 4.4 on our DRA726 board and the kernel module that came with it didn’t recognize the device. That kernel module only supports the CH341 as a uart which is one of the modes of it. My designs uses it as a SPI device. I guess that most people use the driver for the G340G mode.
I did find a kernel module that uses it as a spi device. I would think that once Linux can recognize the device as SPI I should be able to use the MCP2517FD kernel module with a custome devicetree.
My Linux is gentoo, I do have a debian install for when I do linux work from home for my employer. At work I use ubuntu on the linux intel computer and debian on the neovi-pi.
Michel
