Open Source Breadboardable PIC32MZ Board  - Page 1
Forum section: electronics / general

author: RoadRunner
author_rank: Frequent Contributor
timestamp: April 22, 2019, 06:35:44 pm
content: I use PIC32 quite a lot, till now i was not having a versatile board that can be used to experiment. so i made this little board.This little Board might come useful if some is planing to do something with PIC32MZ.Board i have here is PIC32MZ2048EFM064 , TQFP 64 , 200Mhz, 512KB ram and 2MB Flash, quite unique USB HS.here the link to my website.https://www.circuitvalley.com/2019/04/breadboardable-microchip-pic32mz-diy-ardunio-usb-hs.htmlRegards

author: dmendesf
author_rank: Frequent Contributor
timestamp: November 07, 2019, 01:38:31 am
content: Hi, very nice board. Do you have more software for it? HS usb perhaps? I'd like to give a try to your board with it.

author: RoadRunner
author_rank: Frequent Contributor
timestamp: November 20, 2019, 04:31:50 pm
content: Quote from: dmendesf on November 07, 2019, 01:38:31 amYes i do have made few applications with it , I made a USB HS camera with it source code is available in my githubhttps://github.com/circuitvalley/USB-Video-Class-Stack-PIC32-UVCand more details about the DIY USB HS camera is available here.https://www.circuitvalley.com/2019/06/opensource-diy-usb-webcam-ov7670-ov2640-pic32-USB-UVC-Video-device-class.html

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 07, 2020, 11:40:44 pm
content: Hey RoadRunner, what's the license on the schematics?You see, I was wondering if I could make a variant of your board, for PIC32MZ1024EFG-064 with pads for ILI9341 or similar display modules. This came up in the Programming subforum, in theILI9341 mental supportthread, you see. I'd prefer to just public domain my schematics and gerbers (likeI usually do), but will of course use whatever license you use, if I can steal from you. Using an already tested schematic for the bypass caps, USB connector, and crystal would mean that I might have a chance of making it work!

author: RoadRunner
author_rank: Frequent Contributor
timestamp: February 08, 2020, 08:48:44 am
content: Quote from: Nominal Animal on February 07, 2020, 11:40:44 pmA development board such simple and generic thing, i believe can not have licence. i do not think there should a license but still for people who just absolutely want a license to know exactly what they are allowed. i have put license most nonrestrictive CC - BY .Just in case somebody interested in more project, i did this USB Display project with same board with USB HShttps://www.circuitvalley.com/2020/01/spi-mipi-bridge-fpga-verilog-hdl-ipod-nano-nano-lcd-iphone-mipi-lcd-usb-pic32-usb-hs.htmlhttps://www.circuitvalley.com/2020/01/spi-mipi-bridge-fpga-verilog-hdl-ipod-nano-nano-lcd-iphone-mipi-lcd.htmlRegards

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 08, 2020, 01:43:21 pm
content: Quote from: RoadRunner on February 08, 2020, 08:48:44 amI agree -- that's why I explicitly put stuff in CC0/Public Domain; that is the closest equivalent to "I don't think this is copyrightable anyway". In some ways,CC-BYis even better, as all it asks if one thinks stuff is copyrightable, is attribution; and we should do that anyway.In any case, don't think of a license statement as an assertion that things are copyrightable; but more like the sharing rules the developer would prefer.Because of that, Ireallylike Dave'sOpen Hardware logo idea: it makes things immediately clear, with just a single glance.Quote from: RoadRunner on February 08, 2020, 08:48:44 amVery interesting!Is the 100ms delay between frames correct, or did you mean 100µs = 0.1ms? And did you have any full speed (12 Mbit/s, like most HID) device on the same bus? While the HID devices get a frame reserved every millisecond (and that is not directly the reason for the delay between frames), it is possible the host USB stack (on the computer) does something silly that causes those delays. Testing on another machine or USB port is warranted. Also, if the root is an USB 3.x port, better put an USB 2.0 hub in between; I've heard of various issues with USB 3.x ports (that tend to be sorted by putting an USB 2.0 between the root port and the device).

author: RoadRunner
author_rank: Frequent Contributor
timestamp: February 08, 2020, 04:56:59 pm
content: Quote from: Nominal Animal on February 08, 2020, 01:43:21 pmI am having 480M USB HS here. Right now Source code which is published online use interrupt end point, which means on USB HS 1024 bytes every 125us because of this limit maximum frame rate is limited to around 20 but with interrupt endpoint bandwidth is guaranteed .Initially i was using bulk end point, which can send lot more data but delay between individual 512 bytes bulk packets was really pain. I observed 99% package arrive together but just 1 or two bulk package arrive with undefined delay. i have observed upto 100ms.In my blog post when i said 100ms delay i meant delay between individual usb bulk packets not delay between display frames. One display frame was 240x240x2 bytes need multiple individual bulk packet transfers. Even though i queued whole display frame at a time. The text on blog was little ambiguous so i have rephrased it.I did not used USB HID because i wanted to use Bulk endpoint for the sake of higher bandwidth but as it turned out delay between individual bulk packet on the bus had become unmanageable because i could not able to detect frame sync. I am using UVC like protocol but in reverse, instead of send video to PC i am sending from PC application.Moving to HID would mean i need to change lot in firmware and PC application, so instead of moving to USB HID class i remained custom class with libusb and used interrupt endpoint.I will at some point reopen this project and find out what is the issue. It may be completely normal for bulk endpoint then i have to think better way to detect frame sync.Regards

author: Nominal Animal
author_rank: Super Contributor
timestamp: February 08, 2020, 06:32:56 pm
content: Quote from: RoadRunner on February 08, 2020, 04:56:59 pmYes, I understood; I just meant that some USB host implementations seem to behave wonkily, if physically separate HS and FS devices are mixed on the same bus. Similarly, some FS devices (like ATmega32u4-based keyboards and other HID devices often used in DIY controllers) don't work at all with USB 3.x ports, unless you stick an USB 2.0 hub in between.I have seen various delays and latencies between URBs in the millisecond range; 100ms is an order of magnitude higher than anything I've encountered.Quote from: RoadRunner on February 08, 2020, 04:56:59 pmHow annoying! Have you verified with another OS or host machine, to ensure it is just not a coincidence, an unfortunate a combination of hardware and driver on the host side?Quote from: RoadRunner on February 08, 2020, 04:56:59 pmYes, that's how I understood it. I just haven't observed that long delays between bulk packets. I mostly use USB serial endpoints for this, and although I have a couple of Teensy 4.0s with HS interfaces and a Cypress FX2LP, I am most familiar with FS. (The aforementioned ATmega32u4 with a native FS interface can do a megabyte per second over USB serial, for example; pretty close to the theoretical 12 Mbit/s limit if one considers the overheads.)If I may suggest, see if you can get better bandwidth and lower latencies using USB serial. Because it is ubiquitous, the OS stack is more likely to handle it without gross issues.Quote from: RoadRunner on February 08, 2020, 04:56:59 pmIf I were you, I'd see if a USB Serial + HID device endpoint combination would work. I've done this before, albeit FS only, using Teensyduino (Arduino environment for Teensy microcontrollers), and it has worked well for me. (Teensyduino support for such configurations isn't complete yet for Teensy 4.0, so I haven't tested this on HS. Basically, the core Teensyduino includes the USB endpoint support magic.)The HID device, having a 64-byte packet reserved on the bus every millisecond, should allow 1-3ms practical response time to frame sync -- I mean, as measured between the microcontroller and an userspace application. For best results, in Linux, I'd use a dedicated thread that blocks on the event device, to get the minimum latency. A standard 10-byte custom HID report should work fine for this: USB stacks need to handle these correctly, or game controllers would be glitchy.If there is only one hardware device in use at any time, then in Linux, a simple udev rule can be used to create persistent device symlinks (a separate one for the USB serial endpoint and the HID event device), and optionally limit the access to the devices per user and/or group. It's pretty easy to set up. Then, if the device (symlinks) do not exist, the application can ask the user to plug it in. (For multi-device support, you need toglob()for the symlinks, and have them include a serial number or similar to make them unique.) Makes things especially easy, in my opinion.In my experience, USB serial, even full duplex, tends to be quite efficient and work fine. At least in Linux, you won't even need libusb for the communications, just basic termios support (included in the standard C library). You might need to add tty layer drain viatcdrain()after a full update, though, as the stack usually waits a small while for data before sending the final URB. It essentially blocks until data written to the character device is actually sent by the kernel.In particular, if implementing a Python Qt interface for such a device, I like to use a dedicated thread for the communication, and use a Queue to pass info between the main thread doing Qt, and the communications thread. Full duplex via USB serial seems to work very well even using separate send and receive threads, although for any command-response protocol you'll want to use a single thread. Interesting stuff!