We just acquired a few of these programmers for use as a gamepad for our second driver. We were looking for sample FRC code (we are also wondering what the full capability beyond A/DIO is; it would be cool to wire up a gyro if possible).
We looked at the FIRST guide, but all of the reference links to the sample code are broken. Does anyone know where we can find it? They also mention that it ships with the NI Suite, but I cannot find it on my machine. Is that still a thing? If it is, can someone help me find it?
We are looking to possibly create a Mascot controller
Might be useful stuff here. I see it was broken from the doc. http://www.cypress.com/file/202626/download
Thank you. I found that, but I am looking for the FRC Example which that manual references. All of the materials links are broken.
I may see if I can recover it from our old device.
Thank you. I did make a bit of progress, but I cannot figure out how to assign pin assignments (I will go through the complete tutorial when I get a chance). It is kind of cool how this is like a combination between LabView and CPP programing.
This may be too much this late in the build season, but it will work for us eventually. I added them to our First Choice assuming they would be easy plug and play. Which, they are not really. But they are still cool.
I assume this isn’t much help, but just in case. https://www.cypress.com/file/202626/download
Many of the links were broken. I have the FRC update from that year. I’m trying to also find the firmware…
Thank you. Yes, I have gone through that document. It is helpful, but the firmware, and even better, a sample FRC project will be even better.
I took a read from our PSoC. I’m not exactly sure how to make it work with a new device, but wanted to go ahead and share in case others are more experienced in doing that.
log-programmer2.txt (2.2 MB)
Thank you for posting that. I may be able to figure that part out. I assume that that is really a .hex file correct?
Also, I found this document which may be what we need to program from scratch.
To add the pin maps, it is easy. In the creator software, double click on the [project name] ->Design Resources->Pins, and you can set them there. You do need to update to version 4.4 (3.3 may work too) and update your firmware to get the creator app to talk to your device.
That is a log, so a text file not the hex file, so it has more info, but inside is the flash memory read in 4kb segments it seems. I’m not quite sure how the flash read gets into a workable hex, but it should at least be possible I think.
I had a little confusion about the creator, but may be able to pull some more useful info from it. I’ll post whatever new details I might find.
I did update the kitprog firmware, but it still had some error. I thought that maybe I should using Debug>Attach to running target to access the device but that didn’t connect for some reason. I’m not sure how to read the device flash in the creator and I am being cautious not to wipe the program, etc.
My creator version is 4.2, and the update utility doesn’t show an update path to 4.4. The programmer could be updated from 3.27.1.
Thank you. I downloaded 4.4 directly from the Infeon website. I hope it still works, but it looks as though it will.
There is a chance that the update could wipe it. I do not think mine was wiped when I upgraded though.
Good news, I have a hex file!!
I upgraded the programmer to 3.29.1 and also the Kitprog to 2.21, and then a new option to read to hex appeared.
Here it is: cyfirstkit.hex.txt (639.7 KB)
edit: Make sure to discard the “.txt” needed to upload to CD.
Thank you so much. This is excellent!!!
To the best of my knowledge this is the original source provided by Cypress. Unfortunately I deleted the original .zip that was available in their forum, so I can’t say that for sure, but what I committed there looks to me like an unmodified copy.
I successfully built this project on a fresh install of PSoC Creator 4.4 on a clean VM, but I have not tested the resulting .hex file on hardware. I will try to do that this evening, as well as get the version we modified in 2019 to support more buttons posted. (Getting this off of an old Windows 7 VM has been on my to-do list for a while - thanks for the motivation to actually do it!)
One caveat from several years of using button boards created around this device at competition: Sometimes when the computer comes back from sleep the device appears to be plugged in but the inputs don’t actually register in Windows. Our workaround is that our SOP for Driver Station setup is: 1. plug in to the field and power, 2. check that button presses register in the DS USB tab, and 3. if not, unplug and replug the device, and repeat step 2.
I confirmed that the .hex file built from our source works correctly and I’ve posted that file as a release on the main branch.
I’ve also uploaded our more buttons/less everything else modification on a separate branch.
Thank you so much for all of this. It has been a busy end of the week and weekend and I have not yet begun to test it, but I am incredibly excited.
As a side project, we are going to try to use one of these to create an assistive joystic (to function as a mouse) that they can use to navigate their chromebook. I think this will be an incredible start to that project as well.
Now that I have a bit more time, I dug into this a bit more. It works well and is incredibly helpful.
Do you have any idea about how I would add a rumble? I know how the output should work, I am just wondering how I expose the interface on the joystick end so that the driver station knows how to give it feedback.
Also, and on a related note, do you know how to trigger the digital outputs from the robot code? What started this journey was trying to get some feedback for a visually impaired member (and to design a non-frc Joystick for another student with physical fisabilities as a chromebook mouse interface), but I am realizing that, as always, universal design is helpful for everyone. There are some potentially valuable feedback mechanisms here.
The outputs should be controllable using the setOutput method of genericHID: GenericHID (WPILib API 2022.4.1)
I’m guessing this doesn’t get a lot of testing, though.
Thank you. I am thrilled by this. I will post updates as I make progress. It is definitely not as simple as I thought, but I am learning a lot.
So at least on the surface (linting and building), the Joystick class inherits all classes from the GENERICHID. Is this an accurate assumption, or if I want to play with some things (like kRight and kLeft Hand and the outputs) should I just create a GenericHID object? We are using Java if that is relevant.
Edit: Thank you @Joe_Ross for mentioning about the lack of some testing. That was the missing piece. I am working on this with the simulator, and Glass is not simulating the Joystick correctly for some reason. When I used the Sim DriverStation, it worked perfectly. I did not run rumble, but digital out works as expected. If you change the pin assignments on the joystick, you can even set it to the built-in LED. Oh, and if anyone else comes looking, it does seem like Joystick does inherit the output method at least from GenericHID, but I am assuming, all of the other pieces will work too.
These are certainly nifty little pieces of hardware.
Thank you all once again for your help.
Another piece that was confusing me was not understanding how the objects in the joystick were exposed to the driver’s station. I am still working through some things now, but in another accessibility quest (I want to one of our members make a joystick mouse to help them make their Chromebook accessible), I found this document which helps a lot.