Fu-.
Members-
Content Count
17 -
Joined
-
Last visited
Community Reputation
0 NeutralRecent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
Fu-. started following OpenCV + YOLO & libmali too slow
-
Hello @tooz, I'm using a different YOLO onnx. This input size is 640x640. It's not sample onnx(convertimg from yolov7l), this takes about 10sec per inference. Regards,
-
Hello @tooz, Thank you. I hope you can find a good solution. Regards,
-
Hello @tooz. The zip archive contains to build the sample sources and Makefile. So, extract zip to /home/linaro/, Please make here. Regards,
-
Hi, tooz. I'll provide a test environment where the problem occurs. Please download from below. https://drive.google.com/file/d/1222dOTwmF18_-sgBqk_YtPRJfL-DzPN4/view?usp=drive_link Regards,
-
I've tested on the latest debian 11, but it seems to look like nothing to do with debian version. The inference is too slow.
-
Hi, I'm using yolo v7. I've just noticed that the debian 11 was released. I'll try the new image and test. Regards,
-
Hi, I am challenging image judgment using OpenCV and YOLO. When I ran libmali using OpenCL, multiple threads took the form of one mutex, and the operation speed was abnormally slow. The expected speed is about 100ms per judgment, but it takes more than 10 seconds when it actually works. Is there any way to solve this? I'm using the latest Tinker2S debian image and OpenCV 4.8.0. Regards,
-
I want to use Pin #7(GPIOB0) as 1-wire like a RaspberryPi. Drivers(wire,w1-gpio,w1-therm) are loaded. But, Pin #7 does not appear to be working correctly. I modified a little on rk3399-tinker_board_2.dts like this: / { : (SNIPPED) : w1 { compatible = "w1-gpio"; pinctrl-names = "default"; pinctrl-0 = <&w1_pin>; gpios = <&gpio0 RK_PB0 GPIO_ACTIVE_HIGH>; status = "okay"; }; }; &pinctrl { pinctrl-0 = <&gpio_init &test_clkout2 &w1_pin>; : (SNIPPED) : w1pin { w1_pin: w1-pin { rockchip,pins = <RK_GPIO0 RK_PB0 RK_FUNC_3 &pcfg_pull_up>; }; }; }; --- dmesg says, [ 5.245994] Driver for 1-wire Dallas network protocol. No devices detected. gpio readall says Pin#7(GPIO 8) is GPIOB0, NOT CLKOUT. Does anyone know a better way? Regards,
-
After further investigation, it seems that GPIO#15 (gpio2c_4) is correctly set to pull-down GPIO mode. read GRF_GPIO2C_IOMUX: io -4 -r 0xff77e008 ff77e008: 00000000 bits 9:8 is 2'b00 = GPIO read GRF_GPIO2C_P: io -4 -r 0xff77e048 ff77e048: 0000fd3f bits 9:8 is 2'b01 = weak 0(pull down) Nevertheless, once the input changes from Low->High and the High input is nothing, GPIO#15 continues to stay High. Is there something else I should be setting? From these conditions, it does not seem to be a problem with wiringPi. Is this not a problem with RK3399, but a specification of Tinker2S?
-
> 4. GPIO #15 (wiring Pi #3) pulled down <-> up switch How to do this?
-
Hmm... The value remains latched even when the input of GPIO#84 is manipulated directly (once Low->High and then High input is turned off, the value remains High).
-
I found and wrote into /boot/config.txt; gpio=84=ip,pd but this doesn't make any sense. I did notice one odd thing. Looking directly at GPIO#15 (pin No.84), the value seems to be changing correctly with no input (but I had to change active_low to 1 as follows). # echo 84 > /sys/class/gpio/export # cd /sys/class/gpio/export/gpio84 # cat active_low 0 # echo 1 > active_low # cat value 0 Also, # cat/sys/kernel/debug/pinctrl/pinctrl/pinmux-pins : pin 84 (gpio2-20): (MUX UNCLAIMED) gpio2:84 : It doesn't look like the multiplexer is selecting a GPIO. Does wiringPi correctly select Func_1(gpio2_c[4])?
-
Thanks Joe, Result is this: --- linaro@linaro-alip:~$ gpio readall +-----+-----+---------+------+---+--Tinker--+---+------+---------+-----+-----+ | CPU | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | CPU | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | | | 3.3v | | | 1 || 2 | | | 5v | | | | 73 | 8 | GPIO2B1 | IN | 1 | 3 || 4 | | | 5v | | | | 74 | 9 | GPIO2B2 | IN | 1 | 5 || 6 | | | 0v | | | | 8 | 7 | GPIO0B0 | IN | 0 | 7 || 8 | 1 | IN | GPIO2C1 | 15 | 81 | | | | 0v | | | 9 || 10 | 1 | IN | GPIO2C0 | 16 | 80 | | 83 | 0 | GPIO2C3 | IN | 1 | 11 || 12 | 0 | IN | GPIO3D0 | 1 | 120 | | 85 | 2 | GPIO2C5 | IN | 0 | 13 || 14 | | | 0v | | | | 84 | 3 | GPIO2C4 | IN | 1 | 15 || 16 | 0 | IN | GPIO2C6 | 4 | 86 | | | | 3.3v | | | 17 || 18 | 0 | IN | GPIO2C7 | 5 | 87 | | 40 | 12 | GPIO1B0 | IN | 1 | 19 || 20 | | | 0v | | | | 39 | 13 | GPIO1A7 | IN | 1 | 21 || 22 | 0 | IN | GPIO3D4 | 6 | 124 | | 41 | 14 | GPIO1B1 | IN | 1 | 23 || 24 | 1 | IN | GPIO1B2 | 10 | 42 | | | | 0v | | | 25 || 26 | 0 | IN | GPIO0A6 | 11 | 6 | | 71 | 30 | GPIO2A7 | IN | 1 | 27 || 28 | 1 | IN | GPIO2B0 | 31 | 72 | | 126 | 21 | GPIO3D6 | IN | 0 | 29 || 30 | | | 0v | | | | 125 | 22 | GPIO3D5 | IN | 0 | 31 || 32 | 0 | IN | GPIO4C2 | 26 | 146 | | 150 | 23 | GPIO4C6 | OUT | 1 | 33 || 34 | | | 0v | | | | 121 | 24 | GPIO3D1 | IN | 0 | 35 || 36 | 1 | IN | GPIO2C2 | 27 | 82 | | 149 | 25 | GPIO4C5 | IN | 0 | 37 || 38 | 0 | IN | GPIO3D3 | 28 | 123 | | | | 0v | | | 39 || 40 | 0 | IN | GPIO3D7 | 29 | 127 | +-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+ | CPU | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | CPU | +-----+-----+---------+------+---+--Tinker--+---+------+---------+-----+-----+ Even though there is no input to GPIO#15, it is high.
-
Thanks Joe, I tried your sample, but I still have problems. A High is input to GPIO#15 once, and the original value is maintained even when the input is released. I want GPIO#15 to go Low when the input is released. Any solution?
-
I wrote and test this dts; ----- /dts-v1/; /plugin/; / { compatible = "rockchip,rk3399"; /* disable spi5 */ fragment@0 { target = <&spi5>; __overlay__ { status = "okay"; spi5 { status = "disabled"; }; }; }; fragment@1 { target-path = "/"; __overlay__ { gpio15 { compatible = "gpio2"; pinctrl-names = "default"; pinctrl-0 = <&gpio_pins>; gpios = <&gpio2 20 0>; status = "okay"; }; }; }; fragment@2 { target = <&gpio2>; __overlay__ { gpio_pins: gpio_pins { rockchip,pins = <2 20 0 &pcfg_pull_down>; }; }; }; }; ----- However, this did not work. It still behaves as if it is latching.