From Steve’s previous posts I thought it was pretty clear that he already has working hardware. He’s not “looking” for more hardware, he’s looking for someone to code the configurator and to understand the basic requirements of his project, something that remains astonishingly difficult, it seems.
Correct, now… the original request was for an equivalent of Microchip’s tool, which would be completely ignorant of the “working hardware” that sits behind the MCP2200. Microchip’s tool just configures the MCP2200, and not whatever is connected to the UART/GPIO pins.
As it happens, @swmcl may have hardware with this chip, but I do not. I found that board, which I think could be useful for other reasons too.
If this board is representative of the chip he’s using, then it should be good enough to get 80-90% of the way there at little expense. We’re not going to fry something because we set a GPIO as output-high while some peripheral connected to said GPIO is trying to pull said pin low for example. We can theoretically test all the functions of the MCP2200 chip being used, and provide a complete tool for that chip.
Once that is done, figuring out the extras for the hardware behind the MCP2200 should be a fairly trivial matter by comparison, for that, yes we’ll need @swmcl’s hardware.
All,
Pamela was the first to offer to have a go. So she has been given two little boards that I used to use for something which would allow her to complete the task.
Ashley has also indicated a willingness to help and I will follow up with him if Pamela finds something she isn’t able to knock on the head. Ashley won’t be available after a shortish period of time.
If anyone else wants to have a go even to just hone their skills then I would set about making some hardware for them too.
I do appreciate the response from the community. This task has been difficult for me to define - let alone find someone who has this particular skillset. It seems to involve aspects that people don’t get much practice at during a usual programming career so it seems !
This kind of thing is something that is good to put on the CV I should imagine … not everyone has it for sure.
Cheers,
1 Like
Query … where do I discuss the best or various software options with this project ? When discussing how the device would be setup in Linux, Pamela raised the possibility of piping the data through a ‘socket’. Now this is completely over my head and I would like members to help me out here.
I thought the device hanging out at the end of a USB cable would be enumerated as a ttyUSBXYZ01 etc. and it would work through udev. I don’t understand how a serial device could be attached to a socket and what ? Would it then have an IP address and port number ??
I’m sure that this method might have some advantages but I don’t know what they would be apart from a potentially easier way to connect a database.
My device using the MCP2200 should be considered a data logger essentially. The data comes into the computer in a byte stream but it might get interfered with in some way - including a poor / unstable physical connection. So I’ll need to timestamp the bytestream and any breaks in the bytestream would be considered either the end of the data or a break in transmission. (One method of sending data could be a remote control type device with an infrared beam which can be cut by a bug.)
I will want to build or modify a tool to see the data and also I’ll want to stuff it into a database at some point.
Would you use a serial port or a socket ?
Rgds,
Steve
1 Like
The MPC2200 will enumerate as two devices. A CDC UART (TTYxxx) and as a HID.
The HID is what is used for configuring the UART parameters.
Once that is done you don’t need to interact with the HID part any more unless you want to reconfigure it.
I assume the “Socket programming” is an abstraction layer that helps making the final GUI bits more hardware agnostic. I am sure Pamela knows what she is doing.
1 Like
Yep, as andrewm said, the physical device presents two interfaces to the system, one for its pass-through comms on /dev/ttyUSBsomething or whatever (ie, the job you actually selected the part for in the first place), and the other the HID interface which is just used to configure the device (and is what this sub-project has thus far been about).
It’s worth noting that in general, configuring the MCP2200 is a separate job from receiving data from it, and those jobs would typically be done by separate tools, but they don’t have to be.
A socket, in unix/linux terms, is a thing that allows two processes(or programs) to communicate with each other. You can have TCP/IP sockets (presented as a port on an IP address, as you surmised) but unix systems also have unix sockets, which the system implements as a node in the filesystem, so that programs can open it as if it’s a file, and read and write from/to it. They’re just “plumbing” for defining how two or more programs can talk to each other, through a simple pipe, and are a fairly common thing on unix/linux systems.
Whether it’s a good choice for use in your project depends on the details of Pamela’s solution, so she will be the best person to explain the choice. Perhaps she is planning to implement the project in two parts - a small program or service that talks to the hardware and a socket, and then the GUI which talks (via the socket) to the service. That’s only one assumption though, and it depends on the other details of the project.
As for the data logging, that would be (presumably) a different task, and depending on the details, could be done by a simple shell script talking to the virtual serial port and pushing the data to a database, or any combination of things - but it wouldn’t need to be specific to the MCP2200 as it’s just talking to the ttyUSBwhatever device that the MCP2200 presents. It will be specific to the needs of your project, though 
1 Like
I’d imagine the HID part would play a part if you wanted to use the GPIOs in your application.
e.g. you might have 3 or 4 RS-485 transceivers all wired up, and you use the GPIOs to turn one receiver or one transmitter on.
True, good point. All comes down to the specifics of the project.
There is also a 256 byte user EEPROM area than the HID interface is used for.
However I believe OP is not using the GPIO or the EEPROM and only wanted to program the UART settings, VID/PID and identifier string.
BTW - The datasheet says that the user EEPROM area is high endurance, but does not mention what the config EEPROM is like. So having a tool that changes that too often may end up being a problem.
I’m not using the GPIO. My configuration of the MCP2200 at this stage is to change the baud rate, blink rate of the LEDs and will be to change something in EEPROM (perhaps on of the strings). In the beginning of my work I didn’t know whether I’d need hardware control. In the future I might take advantage of the USBCFG.
My initial choice in choosing this chip was:
- size for my tired eyes (tiny is not good in a prototype)
- configurability (being able to retain something like a customer number in a string)
- having a ‘unique’ serial number
- availability
In Linux, the udev rules can be changed to search for the customer number or/and serial number and enumerate to a known static name. This is so any following software simply works on this basis without user intervention.
In Windows, the port can change depending on where you plug it in on a computer. Downstream software has to change to operate on the different COM port. Take the software for my gas computer on my car for example, I have to remember to plug it into a particular USB port on the left of the laptop otherwise it gets given a different COM port number and I have to change the settings in my software.
This is a big issue if you want hardware to just work from a Black Start once it is configured. I believe potential customers are like myself. They couldn’t give a $%^ about sitting at the computer and re-configuring things every time it gets plugged in or the power goes out or something else.
This tool is simply to allow me to work in a single environment doing my prototype. I am miles away from even knowing if the prototype will work. I’ve already gone through 4 different PIC chips for various reasons are not capable. The road is long and with many potholes so I thank you all again for your interest and input.
2 Likes
Just to let you know that although there has been some progress on this project Pamela has encountered some difficulties. We would appreciate it if someone could perhaps just help us get over the hump or maybe we need to re-think our strategy.
I personally am not able to drill down to the issues Pamela faces so Pamela will advise of the technical details.
I don’t expect you to work for free and am willing to discuss a reasonable remit for your work. Please use this forum to make contact and go from there.