Luckily for this project I had a really great starting point laid out for me in the TeensyJVS code.yeah, wish I had the capital to hire this man. So many things can be improved via hobby projects like this. (like OSSC or HAS or USB-Decoder for example)
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.
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.3. Wire up my unused fighter cab and test non-driving games to ensure playability with games that have more digital buttons.
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.is that monochromatic or are multiple colors available?
did you touch anything else on the lindbergh at all? Stupid question but...are all cables in place?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.
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?did you touch anything else on the lindbergh at all? Stupid question but...are all cables in place?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.
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.
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?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?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.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.
PM if you want me to test anything or provide some help.
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.
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.My guts tell me it might be a timing issue.
I don't at the moment. I might be able to use a separate Arduino to help out here, though.Do you have an analyzer to see how it responds in one case and the other?
If you get some extracts from the sygnal analyzer post them or PM me and I can tell you where the problem is.I don't at the moment. I might be able to use a separate Arduino to help out here, though.Do you have an analyzer to see how it responds in one case and the other?
Thanks! I'll see what I can come up with.If you get some extracts from the sygnal analyzer post them or PM me and I can tell you where the problem is.
I'll try to resolve the current DUE Lindbergh issue.
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.My guts tell me it might be a timing issue.