search

NicoHood / Nintendo

Use Nintendo Controllers with Arduino
http://www.nicohood.de
MIT License
278 stars 55 forks source link

Running on faster processors #12

Open rosshadden opened 7 years ago

rosshadden commented 7 years ago

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 commented 7 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 2 years ago

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

Skuzee commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

@Skuzee thats incredible. Thanks