Running on faster processors

[rawsp33d]

Is there a reason, other than this hardcoded check, that this library wouldn't work with higher clock speeds? Could I run it without issue on, for example, a 72MHz ARM processor?

[NicoHood]

@rosshadden The inline assembler only runs on 16Mhz platforms. You could port the code to faster MCUs using c (as they should be fast enough then). I never used faster MCUs, feel free to port the code.

[Skuzee]

I don't mean to raise a dead post/project, but this code is a staple part of an open-source gamecube controller adapter. Specifically for Ocarina of Time, but can be used to make the analog stick feel more like gamecube or n64 (on wii).

I'm interested in running it on a trinket m0 48mhz processor. Can you point me in the right direction if I were to take steps to either redo/adjust the assembler code or port it to python or c? Is there a particular program needed to view the assembler code your talking about?

I know me asking these questions reveals that I don't know a lot about these subjects, but I do have programming experience.

Any help or information would be greatly appreciated. Thank you for your contribution.

[Skuzee]

To answer my own question a little bit, and suggest a possible alternate solution: there is a setting "System Clock Prescaler" that's supported on a lot of arduino/clones. So until I find another way, I might be able to run at a slower clock speed (16mhz)!

[NicoHood]

Yes you can do that, but all other functions also has to run slower and support 16mhz on an mcu that is run normally faster.

You need to add additional timings to the assembly. but the assembly will not work for arm MCUs I guess. So the whole library requires a rewrite. I've documented the code very well, so feel free to read it and adapt it.

[eadmaster]

@rosshadden The inline assembler only runs on 16Mhz platforms. You could port the code to faster MCUs using c (as they should be fast enough then). I never used faster MCUs, feel free to port the code.

So this means it won't work even with Arduinos running at 8MHz/3.3v.

The ideal choice for me would be an STM32 board since these are cheap and easy to find, and they are running natively at 3.3v .

[NicoHood]

8MHz would be too slow to manage the reading. If the MCU is faster, you could switch out the inline assembly with "normal" c code that runs slower, but since the MCU has more MHz it would still work.

The only thing you need to port is this file:
https://github.com/NicoHood/Nintendo/blob/master/src/Gamecube_N64.c

[NicoHood]

Did anyone manage to implement the missing file? shouldn't be so hard to do it with more clock cycles available. Not even assembler is required, just use micros() or delayMicroseconds().

[Skuzee]

Did anyone manage to implement the missing file? shouldn't be so hard to do it with more clock cycles available. Not even assembler is required, just use micros() or delayMicroseconds().

Doge wrote his own program in C for use on a teensy. They mentioned that they used teensy specific registers and stuff, so it's not completely universal.
https://github.com/DogeSSBM/DogeBawx

[NicoHood]

@DogeSSBM would you mind porting your code for this library, so it could also support teensy? It would benefit from any API updates, such as the recent addition of different reading modes.

[mintcheetos]

Would it be possible to run this on a trinket at 12mhz? Its just so perfect to drop into controllers

[Skuzee]

Would it be possible to run this on a trinket at 12mhz? Its just so perfect to drop into controllers

Currently the timing sensitive code is hard coded in assembly for a 16mhz processor. I would suggest checking out the "sparkfun pro micro" It's quiet small and has built in hardware serial if that;s important. It's a 5v device.

[Skuzee]

Would it be possible to run this on a trinket at 12mhz? Its just so perfect to drop into controllers

Currently the timing sensitive code is hard coded in assembly for a 16mhz processor. I would suggest checking out the "sparkfun pro micro" It's quiet small and has built in hardware serial if that;s important. It's a 5v device.

If you have a 5v power source, or are willing to power via usb, and want to communicate with 3.3v device without needing a logic level converter, I have a version the library that is safe to do so, https://github.com/Skuzee/Nintendo It does not put 5v to the 3,3v data line, but does require a resistor.

[mintcheetos]

Would it be possible to run this on a trinket at 12mhz? Its just so perfect to drop into controllers

Currently the timing sensitive code is hard coded in assembly for a 16mhz processor. I would suggest checking out the "sparkfun pro micro" It's quiet small and has built in hardware serial if that;s important. It's a 5v device.

If you have a 5v power source, or are willing to power via usb, and want to communicate with 3.3v device without needing a logic level converter, I have a version the library that is safe to do so, https://github.com/Skuzee/Nintendo It does not put 5v to the 3,3v data line, but does require a resistor.

Its perfect

[Skuzee]

@mintcheetos If you're using a 5v device to only listen to the controller data the normal library is fine, but if you intend to communicate with a controller, then my version and a 750ohm pull-up resistor is needed between 3.3v power and controller data line. (not the console side, since that already has an internal resistor.) I should probably link this too. It has a little info about the wiring. https://github.com/Skuzee/ESS-Adapter

[mintcheetos]

@Skuzee thats incredible. Thanks