Open Source Breadboardable PIC32MZ Board

[RoadRunner]

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.html


Regards

[dmendesf]

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.

[RoadRunner]

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.

Yes i do have made few applications with it , I made a USB HS camera with it source code is available in my github

https://github.com/circuitvalley/USB-Video-Class-Stack-PIC32-UVC

and 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

[Nominal Animal]

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 the ILI9341 mental support thread, you see.  I'd prefer to just public domain my schematics and gerbers (like I 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!

[RoadRunner]

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 the ILI9341 mental support thread, you see.  I'd prefer to just public domain my schematics and gerbers (like I 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!

A 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 HS

https://www.circuitvalley.com/2020/01/spi-mipi-bridge-fpga-verilog-hdl-ipod-nano-nano-lcd-iphone-mipi-lcd-usb-pic32-usb-hs.html
https://www.circuitvalley.com/2020/01/spi-mipi-bridge-fpga-verilog-hdl-ipod-nano-nano-lcd-iphone-mipi-lcd.html

Regards

[Nominal Animal]

A 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 .

I 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-BY is 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, I really like Dave's Open Hardware logo idea: it makes things immediately clear, with just a single glance.

Just in case somebody interested in more project i did this USB Display project with same board with USB HS

Very 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).

[RoadRunner]

A 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 .

I 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-BY is 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, I really like Dave's Open Hardware logo idea: it makes things immediately clear, with just a single glance.

Just in case somebody interested in more project i did this USB Display project with same board with USB HS

Very 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).

I 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

[Nominal Animal]

I am having 480M USB HS here.

Yes, 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.

I observed 99% package arrive together but just 1 or two bulk package arrive with undefined delay. i have observed upto 100ms.

How 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?

In my blog post when i said 100ms delay i meant delay between individual usb bulk packets not delay between display frames.

Yes, 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.

It may be completely normal for bulk endpoint then i have to think better way to detect frame sync.

If 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 to glob() 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 via tcdrain() 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!