- Thread starter winteriscoming
- Start date
winteriscoming
Champion
Luckily for this project I had a really great starting point laid out for me in the TeensyJVS code.
I honestly haven't been working with Arduino's for very long and am amazed at the things you can do with them, and about every little thing you'd want to do has an example posted somewhere. It's just a matter of figuring out which examples apply to what you're wanting to accomplish. For JVS communication that can essentially be broken down into digital inputs, analog inputs, digital outputs, and serial communication over RS-485. There are abundant and pretty clear examples of each of these available. Then it's just a matter of tweaking things and testing over and over and over.
I would encourage everyone to take a stab at using an Arduino, RPi, etc to try to come up with solutions. Don't just dismiss it as too difficult if you have no experience. Start with baby steps and get lights blinking at the push of a button and slowly build up from there.
try to go back to a version that you know it worked and introduce changes one by one until you find the one that breaks it. Also use a lot of printf. Sometimes those compilers are PITA and they will compile ok but mix variable types or formats. I know it's really frustrating debugging those things....Man, I almost feel like I'm back at square one, fighting with the code once it starts communicating with the mainboard. I've introduced something that breaks it now when reading/reporting switches.
It's something to do with the way I'm storing and applying profiles since that's the only major change that should have an impact here. I'll get it figured out eventually. It just sucks that my recent free time has been devoted to these new bugs instead of progress.
may the coder force be with you.
winteriscoming
Champion
I've spent a LOT of time troubleshooting my latest issues... after lots of frustration, I think I've isolated it to an array that has gone rogue (my fault) and corrupted some memory that was being used by inputs, breaking the entire thing under certain circumstances. I'm surprised I hadn't run into this before, because this particular array has been in use the same way for quite a while now. It must not have been corrupting anything necessary before my more recent code changes.
winteriscoming
Champion
While I haven't gotten to this yet, I did go ahead and set up a default profile that maxes out the controls pin for pin to the stock Type 1 I/O. This means that just like the Type 1, the MEGA JVS is reading and reporting data for all 29 digital inputs (including the 2 coin slots) and all 8 analog channels, whether or not they're used. I'm happy to report that I'm getting good performance out of the board in this state. If I'm still getting responsive controls in OR2 when using this profile, it means that any game that maxes out the controls should be fine.
In other news: I'm happy to report that compatibility between MEGA 2560 and DUE from the same code seems to be working out just fine.
My revised to do list is:
1. Install and wire up the little display in my cabinet, and make sure things are working ok there when the MEGA JVS is being used in a game. I haven't simultaneously had the screen wired up at the same time as playing. The code is still there driving the display even if it's not wired up, but I'll want to test this out in case there are any issues.
2. Finally get around to testing out in my fighter cab.
winteriscoming
Champion
Look what just occurred to me! I know where the display is going.
is that monochromatic or are multiple colors available?
winteriscoming
Champion
It's monochromatic. I'm not sure what the options are for colored displays this size. I know the library I'm using has support for colored displays, though.
I'd think for an application like this monochrome is sufficient. I would also think OLED would be superior to a TFT equivalent for clarity and viewing angle. I'm not sure on price for similar sized colored screens. For sure they're more than $10.
Edit: it looks like there are cheap colored OLED screens of the same size available on eBay from Hong Kong for about $12. They look like they require 7 wires instead of 4, so not sure what all they'd need for driving them with an Arduino. I don't need one for this project, but it's nice to know colored displays are out there.
Last edited:
winteriscoming
Champion
I've been playing through WMMT2 on Chihiro in manual transmission mode with the 2-position shifter and my card emulator. I'm able to drift well and win races, in spite of never going into neutral, so this seems like a totally viable way to play this awesome game if you didn't want to invest in a 6-position shifter and retrofit it to your driving cab.
The only thing missing with WMMT in an OR2 cab now is force feedback and I intend to address that with a future project.
The only thing missing with WMMT in an OR2 cab now is force feedback and I intend to address that with a future project.
winteriscoming
Champion
Great! These screens seem to work fine mounted remotely over a few feet of un-shielded wire in this high EMI environment.
The only potential for issues now that the screen is incorporated is that it takes a little longer to change profiles. I'm still able to swap profiles in realtime, but it's important not to be spamming the profile button during JVS initialization or you can cause the communication to break down and fail that process which needs quick, uninterrupted replies.
I could probably work in a suppression for profile changes during init.
The only potential for issues now that the screen is incorporated is that it takes a little longer to change profiles. I'm still able to swap profiles in realtime, but it's important not to be spamming the profile button during JVS initialization or you can cause the communication to break down and fail that process which needs quick, uninterrupted replies.
I could probably work in a suppression for profile changes during init.
winteriscoming
Champion
Ugh, one step forward and 2 steps back. I've been testing almost exclusively on the Chihiro as I've made changes. Now that I plug it back into the Lindbergh, I never get past the set address command at initialization...
I put it back in the Chihiro and things are good to go.
I did previously have this working on the Lindbergh, too, and none of my recent changes should have an impact on the initial JVS communication.
I put it back in the Chihiro and things are good to go.
I did previously have this working on the Lindbergh, too, and none of my recent changes should have an impact on the initial JVS communication.
did you touch anything else on the lindbergh at all? Stupid question but...are all cables in place?
If it's definitely a code thing, I'm afraid you have to undo your changes one by one until you find the one that broke it.
PM if you want me to test anything or provide some help.
winteriscoming
Champion
Well it appears to be a DUE issue, because the same code base running on the MEGA 2560 works with the Lindbergh. The only difference here would be that the DUE runs the RS485 module at 3.3v instead of 5v. I even swapped MEGA JVS boards between the MEGA and DUE and the issue stays with the DUE. I'm not sure what could be going on here. The I/O's perspective, there shouldn't be a difference between a Chihiro and a Lindbergh. It acts the same. Maybe the 3.3v results in a slightly weaker RS485 signal that the Lindbergh doesn't like?
The issue is during the very first reply back to the Lindbergh from the DUE. Its right at the period where the Sense line sinks to ground and the ACK for address has to be sent from the I/O.
This is probably my first time trying the DUE with the Lindbergh.
My guts tell me it might be a timing issue. Do you have an analyzer to see how it responds in one case and the other?
winteriscoming
Champion
Hmm... maybe. I confirmed the DUE can communicate with the NAOMI 2 successfully, so it's just Lindbergh that's the odd man out. Maybe it's being stricter on timing.
I don't at the moment. I might be able to use a separate Arduino to help out here, though.
If you get some extracts from the sygnal analyzer post them or PM me and I can tell you where the problem is.
winteriscoming
Champion
Thanks! I'll see what I can come up with.
winteriscoming
Champion
My main attractions to the DUE over MEGA 2560 are micro USB ports to distinguish from USB Type B port used for JVS and the built in native USB port for HID functionality.
I have previously played around with a MEGA 2560 as a HID keyboard, requiring a firmware flash, and have discovered that there's a more robust HID library available for the MEGA than the DUE. If I can get all the functionality I want out of the cheaper MEGA, I can likely get past the potential USB Type B port confusion with a micro USB adapter. BTW, I've accidentally plugged JVS into the MEGA's USB port and powered on without consequence.
I'll play around with the HID stuff on the MEGA and see where I can get
I'll continue supporting both devices in the code if I can, and I'll try to resolve the current DUE Lindbergh issue.
I have previously played around with a MEGA 2560 as a HID keyboard, requiring a firmware flash, and have discovered that there's a more robust HID library available for the MEGA than the DUE. If I can get all the functionality I want out of the cheaper MEGA, I can likely get past the potential USB Type B port confusion with a micro USB adapter. BTW, I've accidentally plugged JVS into the MEGA's USB port and powered on without consequence.
I'll play around with the HID stuff on the MEGA and see where I can get
I'll continue supporting both devices in the code if I can, and I'll try to resolve the current DUE Lindbergh issue.
winteriscoming
Champion
Apparently the DUE is replying too quickly to some of the commands (SET ADDRESS and READ ID). It must just be able to calculate the responses faster than the MEGA 2560. Putting a 1ms delay before replying to these 2 commands lets me get through initialization with the DUE on the Lindbergh now.
It's interesting that the Lindbergh has some stricter timing requirements than the Chihiro and NAOMI 2.
