Jump to content
  • 0

uC32 communication with PC


JColvin

Question

A customer on our website asked the following question:

Good day. I'm using the uC32 board. I'd like to control my board through a GUI in my PC. However, i just learned that i cannot use the PIC32 USB Application Library because the chip on board has no USB peripheral, instead an FT232R IC serves as interface between the USB the UART Peripheral. Is there an easier way of communicating with the PC?

Thank you very much.

The response is below.

Link to comment
Share on other sites

3 answers to this question

Recommended Posts

Hello,

You are correct, you will not be able to use a USB Application library because the uC32 does not have a USB host receptacle on board. There are only two ways that I am aware of that you would be able to control the uC32 from your PC. One is the communicate with the board through the Serial Monitor of MPIDE or the Arudino IDE and have the uC32 preprogrammed to execute different functions when you type different lines of text into the Serial Monitor. You can learn more about this in one of Digilent's blog posts.

The other way that I know of is that you can actually control the uC32 through LabVIEW. I have used LabVIEW Home Edition combined with LabVIEW MakerHub LINX (following this tutorial to get everything set up; it's for the WF32, but you can choose the uC32 instead) to get a lot more interaction (and more friendly GUI) to control the board.

Let me know if you have any more questions.

Thanks,
JColvin

Link to comment
Share on other sites

You do know, don't you, that you can control a device through a GUI even if the actual control takes place over a UART backbone, right?  I've done this with several of my projects.  When you click on a button in the GUI, a command is then sent to the UART.  When a particular string is read from the UART later, such as for example a prompt string, the GUI then determines that the UART is free for its next command.  Further, most GUI's are event driven, and can be programmed so that characters that need to be read from a file (such as a UART device) become a GUI event that you can then process as such.  The biggest difficulty is that the return UART processing tends to be a bit more disjoint: you need to build a routine that maintains its state between calls, but this isn't all that much different from the rest of your GUI processing discipline.

Gosh, I've even built a spectrum analyzer in this fashion.  It was as slow as all get out, but it still worked.

Dan

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...