My new project requires a simple (for the User) interface to control a PIC32. I'm a long-term Linux user - haven't used M$ since last century - so my own executables will not work for a majority of prospective Users.

I've decided that the best solution would be for the PIC32 to present HTML pages over a USB connection, since this would not only work on desktops and laptops, but on smartphones as well. However, I've never coded anything like it, and this is my first use of the PIC32.

If anyone has experience, advice or information that could assist I'd be most grateful for their input.

 

How do you plan on connecting a Smartphone (usually a downstream device, rarely a host unless it supports OTG) to a PIC32 (most definitely a downstream device, not sure it can be a host)? I think your starting premise is problematic. USB is a host (PC/laptop) to slave device communication. You can implement a serial conversation across the link, instigated by the host, but that would do all the rendering. Writing HTML on the pic seems unnecessarily complicated when all you're doing is moving text around...

 

Thanks for the critique. Yes, the smartphone will use OTG so that it acts as host to the PIC. "USB is a host to slave device communication". Correct, and the PIC will be the slave.

"... a serial conversation across the link, instigated by the host ...". Yes: once connected, the host (computer or phone) would use a new browser page to connect to the PIC, probably using 192.168.X.X or similar, and the PIC would return a control page containing links. Clicking a link would send an HTML request to the PIC with a query string as in standard Internet activity, which would trigger events in the PIC and the return of an updated page.

"... all you're doing is moving text around..." Aha! No, each click on the HTML page will trigger a control request in the PIC before the new or updated page is returned; the text is just the User interface.

BTW, have decided to use one of the smaller ARM chips (Cortex-M) since Microchip doesn't support Linux. The reason for using a browser page as a control interface is because it's completely generic and cross-platform, whereas the conventional solution (and what I'll use for development) is a GUI app written in C/FLTK on the host.

Appreciate your input. Forced me to think things through a bit further.

 

Before you go any further, have a look at Onion Omega2 and Omega2+.

 

Thanks for the tip - VERY interesting! Certainly a well-thought-out and well-presented package.

I've put it on the list of candidates.