@lex

  • Content Count

    511
  • Joined

  • Last visited

2 Followers

About @lex

  • Rank
    Embedded member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2735 profile views
  1. Try removing the config file with Htop closed: sudo rm /root/.config/htop/htoprc Start Htop and make your changes.
  2. This is a classical memory corruption. Htop has possibly crashed. During a crash Htop emits a backtrace with some info. If you have the backtrace info, please post here with your Htop version. You can also try a few things: * Remove every meter, F2 and delete all the meters, exit. Start again and add one cpu bar. If it is Ok then proceed with the rest. * If you have some skills build Htop with debug info, the backtrace will show the function previous to the free() memory.
  3. Can you post the format info for your USB camera? v4l2-ctl -d 4 --list-formats or v4l2-ctl -d 5 --list-formats I have seen some USB camera has a YUY2 format. Cpu usage ~52% looks good for OpenCV.
  4. Ok. In the JPEG_1X8/640x480@30FPS case you should expect a bit more cpu usage than the USB camera, say ~5% more cpu usage and not the ~35% increase you see. The reason is you get 640x480x3 pixels from the sensor instead of only the compressed image. I would build opencv with debugging info and try to find the bottleneck. And why there is an image conversion in the DVP case. Push the limits to 720P/30fps or even 1080P and see what you get.
  5. No GPU/VPU involved. I think there is a conversion from YUV to rgb in opencv and possible a decompression from jpeg to rgb, i am not an opencv expert, maybe someone can give more details about what's going on inside opencv. There is still room to optimize the JPEG_1x8. That's pretty good. There must be no conversion in the image format to achieve this. It is interesting to find out more about it. Can you share more about your application and your setup and usb camera?
  6. What are the compiler options in use? You could try to put a break before you call **WrTSpec** and check the stack. You can also use valgrind to check for stack corruption.
  7. Yes, it works fine, but be careful with mainline kernel AVDD / DOVDD / DVDD supply, i have burned out 6 sensors with the wrong settings. Search the forum for OV5640, i have advised one with ~130º lens if i remembered correctly. I would buy 2 or 3 from different sources (or different models) since you are not sure what you will get.
  8. This error is: /* No such device or address */ You should double-check: 1. Is your sensor OV5640? 2. Check the connector, some are reversed 180º which is the case for BPI and Orange Pi. There is a Thread about it, 3 years old a think.
  9. if you have pwm exposed you can control the speed and lower the noise.
  10. I am not sure if I can give you a direct and correct answer without resorting to reading the code "sun6i_csi". The format can be inferred from there. A good reading: https://linuxtv.org/downloads/presentations/summit_jun_2010/20100614-v4l2_summit-media.pdf https://linuxtv.org/downloads/v4l-dvb-apis-new/userspace-api/v4l/v4l2.html I don't use Zoom or GoToMetting, but basically any of these program to work must use the frame size and image format (yuv) set in media-ctl, if they try to get sensor capabilities and choose any one different from what you have set with
  11. media-ctl --device /dev/media1 --set-v4l2 '"ov5640 0-003c":0[fmt:YUYV8_2X8/1280x720]' From the topology (your case): --device /dev/media1 => this is your media for the OV5640 '"ov5640 0-003c":0[fmt:YUYV8_2X8/1280x720]' | +--> sink '"ov5640 0-003c":0[fmt:YUYV8_2X8/1280x720]' +-> :YUYV8_2X8 --> image format = YUV420P = YU12 '"ov5640 0-003c":0[fmt:YUYV8_2X8/1280x720]' +-> 1280x720] -> frame size ( sensor ava
  12. You need to tell v4l2 some info prior to capture images. Capture Images: https://github.com/avafinger/fswebcam#mainline-kernel-support I think is possible to grab images with 'Cheese' but you need to instruct Cheese to use the previous Image size set with media-ctl.
  13. can you print the output of: lsmod|grep ov ov5640 28672 1 v4l2_fwnode 20480 2 ov5640,sun6i_csi videodev 163840 7 ov5640,v4l2_fwnode,sunxi_cedrus,videobuf2_common,sun6i_csi,v4l2_mem2mem,videobuf2_v4l2 mc 28672 7 ov5640,sunxi_cedrus,videobuf2_common,videodev,sun6i_csi,v4l2_mem2mem,videobuf2_v4l2 This is valid if ov5640 is enabled with 'm'
  14. Changing from 'm' to 'y' would not make a difference, so the problem is somewhere else. You should see this: [ 3.999211] i2c-gpio i2c-csi: using lines 141 (SDA) and 140 (SCL) Try this change: sda-gpios = <&pio 4 13 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN|GPIO_PULL_UP)>; /* CSI0-SDA: PE13 */ scl-gpios = <&pio 4 12 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN|GPIO_PULL_UP)>; /* CSI0-SCK: PE12 */