quote
A lot will depend on how much Microchip want to reveal about their device, and how much they are comfortable to make “open”
/quote
Microchip reveal everything about it already in the datasheet and “MCP2200 HID Interface Command Description” PDF. It is a pretty standard HID thing. Making a config tool for Linux would not be too hard at all and any competent embeded+linux programmer should be able to do it in a day if they already are set up for that kind of thing.
Why the config tool needs to be in Linux was my query as from what I have been told about it the config only needs to be programmed once. Not over and over again in the final system.
I get the final product is going to have Linux computer attached and there are “fine and noble” reasons to avoid the software of satan for the end user.
Why the one time config that is going to set up the chip needs to be Linux I still don’t understand. In the end when it’s made in some factory in china they are going to have windows machines doing a lot of other things in the factory, what does it matter if they are going to set the config in windows or Linux.
Or if I am miss understanding what is being meant by the word “product” and there is only going to be 3 units ever made and its not going to be some factory in China. In that case I will happily reprogram the config on the 3 units for you on one of my windows machines for a lot less money than I will charge you to make a config tool that runs in linux.
Hi Steve,
I was looking around seems there is a python interface on github. https://github.com/cdtx/mcp2200/blob/master/cdtx/mcp2200/device.py
I dont think it would be hard to make a gtk2.0+ interface in gcc. I have some familiarity about the GTK 2.0 interface from debugging gpsdrive on ubunutu.
Pyhton uses:
import sys
I will say there is a bit more to the configurator project that makes it difficult or impossible to achieve on Windows (I believe). That detail I don’t want to discuss out in the open but it isn’t too difficult to achieve in Linux. The recent attempt by a programmer did nearly work in that respect.
I will say also that this configurator project is just the start of a further 3 projects. I have approached USQ some time ago and have had a formal quote from them too. So I know how much is too much ! (With their lawyers and admin taking a huge chunk … the guy doing the programming was left with bugger all in comparison !!)
Andrew has said it is a days work to someone with some experience in this field. I believe this is the attitude from various people who respond to my adverts also. The problem is that most (nearly all) of them don’t have the experience. I will be fair to say that having hardware to test on is another issue. In my most recent attempt, I had setup a server and left it running overnight with hardware attached for the programmer to test. It hardly ever worked out for him. If I can get someone to work on this locally, I would of course give them hardware.
Worst case is that I somehow gain the skills ! Hey ! I’m a tinkerer and a startup like you, OK ?
OK - If there was more to the configuring that means it needs to be done over and over again I accept that a linux tool may be desirable.
From what I had heard so far it seemed like the reason for wanting a linux tool was open source zealotry. I was trying to save you from suffering for religious reasons in pointing out that configuring once on windows (or Mac) is not sooo evil as to damn you for eternity. Also if a config tool for an ancient outdated USB chip like the MCP2200 is NOT needed - the overall improvement to the world would be greater if you took the money that would be spent developing that tool and donated it too a small struggling open source project you like.
I have the skills and have done this kind of thing before. That is making a HID interface work with linux using libusb. I don’t however have a dev environment set up for doing it at the moment. So would not be a day project for me as it would take several days to get up to speed and then a day to do the last bit.
My offer still stands to give you advice on the “big picture” part of the project and why there is a USB bridge at all.
I might order one on the grounds that there’s a jumper to switch between 3V3 and 5V. I have two FTDI cables lying around (genuine ones), one 3V3 and the other 5V, but the annoyance being you must grab the right one. This kinda solves that problem elegantly, as it can be wired to a switch.
I’m not sure if that’s compatible with the test hardware you’re using, but might be in the ballpark at least.
I’m an electronic engineer who has been making / developing all sorts of hardware for 30 years. My boards are well tested by now.
If you want me to make you something just for general use I could adapt a previous design quite easily. I also have a good number of electronic parts if you need a more left-field application.
The design you link to is extremely limited in its abilities.
Well, the principle thought was that it appears to have all the signals broken out; if it’s the same chip as what you’re using, it should be possible to write something against that which allows programming of the chip, and then apply it to whatever you’re using.
It’d be a good first step. If however, it’s not the same chip, then okay, sure, we’ll need to keep looking. It just struck me as being reasonably minimalist and not expensive.
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.
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.
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.
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.
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
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.
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.
