garinus

  • Content Count

    12
  • Joined

  • Last visited

About garinus

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, after having performed some tests I managed to have the mcp2518fd working with Armbian and Orange PI zero. In attachment there is a patch that works with the current version. The driver is the same as in the main kernel version: https://github.com/torvalds/linux/tree/master/drivers/net/can/spi/mcp251xfd after compiling the kernel it is necessary to add the following custom overlay in /boot/overlay-user /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun5
  2. Hi, I'm sorry you meant this as a claim for help, the request aimed to knowing if there were any guides on how to make these kernel changes. I will not enter more into the discussion as in my opinion we are already off-topic. The need to switch from MCP2515 to MCP2518 is due to the fact that the MCP2515 is at the end of its life cycle, so soon other people will have the same need and therefore it seemed to me a good way to bring together all the procedures within a topic. Our questions have always been of this type, and at the end of the topic if we found a solution we summar
  3. Hi, we are trying to make our Orange PI zero with custom shield working with an MCP2518FD on board with SN65HVD23 tranceiver. We started from the normal kernel already built, but according to this thread we found that it must be activated at compile time. So we downloaded the repo and built the Armbian image with this CAN configuration: CONFIG_CAN=y CONFIG_CAN_RAW=y CONFIG_CAN_BCM=y CONFIG_CAN_GW=y CONFIG_CAN_J1939=y # # CAN Device Drivers # CONFIG_CAN_VCAN=y CONFIG_CAN_VXCAN=y CONFIG_CAN_SLCAN=y CONFIG_CAN_DEV=y CONFIG_CAN_CALC_BITTIMING=y CONFIG_CAN_FLEXCAN=y
  4. Yes, the goal is to use a 485 tranceiver directly, without acting at high level on RTS pin. Now I use ioctl to verify the finish of the tx and i change the state of the pin. This works in 99% of cases except when the cpu is doing something and there is a delay before the change of the signal. I'm having diffculties in applying the patch because i'm a noob in git and kernel compiling. Please correct me if I do something wrong: put the file .patch in the folder build/cache/sources/linux-mainline/orange-pi-5.5 launch the command git apply rs485-825
  5. Hi, thanks Martin. I built the last image. There aren't errors on boot and the ttS2 now works when I add the param param_uart2_rtscts=1. I have still some problems on rts. The signal is high until I open the serial connection, then goes low for all the time the serial stay open and then it become high when I close the serial connection. I made several tries with all the settings I know. The simplest metod to test it is using tio: tio /dev/ttyS2 -f hard-b 115200 With -f none (no hardwae flow control) the serial has the same behaviour.
  6. thank you yoq, i did all what you said, but the serial works until i add param_uart2_rtscts=1 in the armbianEnv.txt file: verbosity=1 logo=disabled console=serial disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 overlays=uart2 usbhost2 usbhost3 rootdev=UUID=48c1e88a-b408-42ec-9d6c-9aaacd147312 rootfstype=ext4 user_overlays=uart2_rtscts_fix param_uart2_rtscts=1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
  7. I found this in boot: Applying kernel provided DT overlay sun8i-h3-usbhost2.dtbo 504 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-usbhost3.dtbo 502 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-uart2.dtbo 502 bytes read in 5 ms (97.7 KiB/s) Applying kernel provided DT overlay sun8i-h3-uart3.dtbo 4155 bytes read in 5 ms (811.5 KiB/s) Applying kernel provided DT fixup script (sun8i-h3-fixup.scr) ## Executing script at 44000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND libfdt fdt_path_offset()
  8. I'm trying to debug it using the oscilloscope, and I see that the TX signal is not initialized to 3v3 when I add the "param_uart2_rtscts=1" in the armbianEnv.txt file. If I do not edit the armbianEnv file, the board initializes correctly the TX and RX signals.
  9. Hi all, I need to enable rts/cts on my OrangePi Zero with Armbian buster with Linux 5.4.26-sunxi installed. I added the "param_uart2_rtscts=1" (I'm using /dev/ttyS2) to the /boot/armbianEnv.txt file On mi code I use this initialization of the port. xxxxx.c_cflag |= port_parity | port_bits | port_stop | CLOCAL | CRTSCTS | CREAD; Not only rts/cts but also the tx and rx pin aren't working now. Has anyone managed to enable the port on this board? Am I doing something wrong?
  10. Hi, I have 3 Orange Pi Zero running with the same sd image. It's all working fine, but yesterday I added a fourth device, which for some reason took a MAC address that is the same of another device, causing issues on the connection for both of them. I'm using the mainline kernel ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.14.18-sunxi. Searching on the internet, I found someone saying that mac addresses for Orange Pis are randomly generated every time the device reboots, but in my case the taken MAC address is always the same for every device. I saw to
  11. Sorry I check a second time on the schematic and I saw the two resistor. I dissoldered them and now it work as i expected. On these pin i have two relays, so when it turns on the relay switch on for some seconds until or the bootloader or the program takes over the control of the pins. Yesterday I tried other option to clear the pins, I report them here to share: connecting on serial press space on the reboot until the console of the bootloader came up (it shows a line: Autoboot in 1 seconds, press <Space> to stop.) write on the console the command: sete
  12. Hi, I'm tring to solve an issue on my Orange Pi Zero: at boot time the pins PA18 and PA19 are stucked to Vcc. I tried a lot of solution, now the best result is to add at the beginning of the file boot.cmd the command to clear the gpio configuration: gpio clear PA18 gpio clear PA19 and recompile the boot.scr. Despite this the pins goes HIGH for some seconds until the bootloader reach this line. What is the boot scheme? Why i get this pin HIGH? Is it because the I2C1 is configured? Is it possible to disable it? Thanks Simone