Support for more boards

[sonik-br]

Hi!

This is not really an issue.
I want to port the library to other boards. Mainly STM32 and RP2040 based boards.
Those boards are cheaper (currently) and natively works at 3.3v.

The DigitalIO lib is too much "black magic" to me :)
Any tip on how to add a new board to it?

[SukkoPera]

It's pretty much black magic to me, too :). But DigitalIO has an example that, when run on a board, will produce the output that should be added to the library in order to enable support for it. Try it!

(Be sure to use my fork and send a PR if you manage to come up with anything. Upstream doesn't seem to care anymore.)

[tbillion]

hey throw me in the hat for looking to get this done as well ... my project is a little more real world application and i think i just outgrew the uno328 so any luck with this?

as far as the PSXnewlib goes what does digital io do for the library ? why do none of the other psx libs have it ?

[SukkoPera]

DigitalIO is just a way of driving the GPIOs as fast as possible and with as little code as possible (i.e. 1/2 ASM instructions on AVRs). It's not strictly necessary and you could easily write new versions of PsxControllerHwSpi.h and PsxControllerBitBang.h that do not require it.

[sonik-br]

I tried to port the DigitalIO library but those processors works quite differently.

But looks like at least on the RP2040 digitalWrite() and digitalRead() are fast enough!

I was testing with a modified (simplified) version of DigitalIO that does passthrough and call directly the digital/Write/Read methods of the arduino ide. Doing this way I don't need to modify the PsxNewLib.

The code builds but I have not tested yet as I still need to wire an psx input port to the Pi Pico.
The STM32 should be fast enough too.

[tbillion]

I spent most of yesterday looking at the code for your library, if I understand it correctly the protocol is defined in one file and the comms is determined in another . I also opened an issue with the digital io maintainer showing the errors I was getting and he believes that it is an implimentation that is causing the errors however when I compile the example he has requested I get similar errors . I was looking at sitting down today and doing it but I'm not the most magical coder ever and while at the end it would work, I'd rather not be banged up as a hack like the front page calls the original lib programmer. My suggestion would be if it is possible could you make a 3rd protocol, you have one, for spi, one for bitbang with digital I/o , and one for just straight bitbang. This way it by proxy becomes more universal by just changing the protocol type. This would also not modify the whole library but instead add a file and it would also allow people to choose if they wanted to use the digital I/o lib .

…

On Fri, Jul 22, 2022, 7:33 AM Matheus Fraguas ***@***.***> wrote: I tried to port the DigitalIO library but those processors works quite differently. But looks like at least on the RP2040 digitalWrite() and digitalRead() are fast enough! I was testing with a modified (simplified) version of DigitalIO that does passthrough and call directly the digital/Write/Read methods of the arduino ide. Doing this way I don't need to modify the PsxNewLib. The code builds but I have not tested yet as I still need to wire an psx input port to the Pi Pico. The STM32 should be fast enough too. — Reply to this email directly, view it on GitHub <#19 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD3MNO4FVONPCCNHTECMG3DVVKII3ANCNFSM5ZQFAB6A> . You are receiving this because you commented.Message ID: ***@***.***>

[tbillion]

Also I have the hardware in question wired up already and would be happy to beta test for you over the next few days since I'm currently off work for surgery and have nothing better to do . :)

…

On Fri, Jul 22, 2022, 8:10 AM t gillespie ***@***.***> wrote: I spent most of yesterday looking at the code for your library, if I understand it correctly the protocol is defined in one file and the comms is determined in another . I also opened an issue with the digital io maintainer showing the errors I was getting and he believes that it is an implimentation that is causing the errors however when I compile the example he has requested I get similar errors . I was looking at sitting down today and doing it but I'm not the most magical coder ever and while at the end it would work, I'd rather not be banged up as a hack like the front page calls the original lib programmer. My suggestion would be if it is possible could you make a 3rd protocol, you have one, for spi, one for bitbang with digital I/o , and one for just straight bitbang. This way it by proxy becomes more universal by just changing the protocol type. This would also not modify the whole library but instead add a file and it would also allow people to choose if they wanted to use the digital I/o lib . On Fri, Jul 22, 2022, 7:33 AM Matheus Fraguas ***@***.***> wrote: > I tried to port the DigitalIO library but those processors works quite > differently. > > But looks like at least on the RP2040 digitalWrite() and digitalRead() > are fast enough! > > I was testing with a modified (simplified) version of DigitalIO that does > passthrough and call directly the digital/Write/Read methods of the arduino > ide. Doing this way I don't need to modify the PsxNewLib. > > The code builds but I have not tested yet as I still need to wire an psx > input port to the Pi Pico. > The STM32 should be fast enough too. > > — > Reply to this email directly, view it on GitHub > <#19 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AD3MNO4FVONPCCNHTECMG3DVVKII3ANCNFSM5ZQFAB6A> > . > You are receiving this because you commented.Message ID: > ***@***.***> >

[SukkoPera]

@tbillion Your idea is fine to me, but I am not going to do that. It's very simple however, you can do it yourself: just make a copy of PsxControllerBitBang.h, name it PsxControllerBitBangSlow.h and replace all DigitalIO calls with straight Arduino calls (pinMode(), digitalRead() and digitalWrite ()). Finally submit a PR :).

[tbillion]

10-4 i have done that part this part though is outside my scope of understanding what to do with, what needs to be done here in the beginning of the code to transfer the pin numbers to the now "dumbed down" version of the code.

template <uint8_t PIN_ATT, uint8_t PIN_CMD, uint8_t PIN_DAT, uint8_t PIN_CLK>
class PsxControllerBitBang: public PsxController {
private:
	#define <PIN_ATT> att
	#define <PIN_CLK> clk;
	#define <PIN_CMD> cmd;
	#define <PIN_DAT> dat;

because what i have does not work 🥇 surprise

below compiles but i am not sure it is correct. I am away from my desk so i cannot test to ensure that will work.

template <uint8_t PIN_ATT, uint8_t PIN_CMD, uint8_t PIN_DAT, uint8_t PIN_CLK>
class PsxControllerBitBang: public PsxController {
private:
	uint8_t att = PIN_ATT;
	uint8_t clk = PIN_CLK;
	uint8_t cmd = PIN_CMD;
	uint8_t dat = PIN_DAT;

	//#define <PIN_ATT> att
	//#define <PIN_CLK> clk
	//#define <PIN_CMD> cmd
	//#define <PIN_DAT> dat

[sonik-br]

Comment out this block
https://github.com/SukkoPera/PsxNewLib/blob/master/src/PsxControllerBitBang.h#L24-L28

Change the calls low() and high() to digitalWrite(PIN_NUMBER, LOW) and digitalWrite(PIN_NUMBER, HIGH)
IE: att.high() would be digitalWrite(PIN_ATT, HIGH)

Here it's used to read..
https://github.com/SukkoPera/PsxNewLib/blob/master/src/PsxControllerBitBang.h#L70

Change dat to digitalRead(PIN_CMD)

And here it needs to call pinMode(). For the ones that are OUTPUT you will also need to call digitalWrite()
https://github.com/SukkoPera/PsxNewLib/blob/master/src/PsxControllerBitBang.h#L82-L85

IE:

//Change from
att.config (OUTPUT, HIGH);

//Change to
pinMode(PIN_ATT, OUTPUT);
digitalWrite(PIN_ATT, HIGH);
//Do this for the 3 input pins

//Then do this for the output pin
//Change from
dat.config (INPUT, HIGH);     // Enable pull-up

//Change to
pinMode(PIN_DAT, INPUT_PULLUP);

[tbillion]

@sonik-br I got all of that I have to test it later, based on context do you think it would be more expediant to change the uppercase variables to the lower case variables to avoid changing too much from the original. I submitted a pull request as suggested with the extra file it could use some deletions because I just commented out and replaced also a clear explanation of why you'd use this one vs the original is probably needed to clarify the use case .

If redeclaring them as private variables is unnecessary then changing PIN_CMD to cmd may be the most fluid solution?

[sonik-br]

Got it working?

If redeclaring them as private variables is unnecessary then changing PIN_CMD to cmd may be the most fluid solution?

I don't see why redeclare them. Just use what's defined in the template. (ie: PIN_CMD).
But I'm not good at C and I have no idea what's the "best practices" for the language.

[tbillion]

ok so the bit bang example works on rp2040 however it was not a library issue.

well actually it was a library issue, and a hardware issue. firstly i think that the actual installation of the digitalio library from git hub instead of the arduino repo for library manager is a MUST DO, like bold italic the whole nine.

then as far as hardware is concerned, the pico either doesn't have pull ups, or they don't work, so you need to follow the suggestions here :

https://store.curiousinventor.com/guides/PS2/
and here :

http://sophiateam.undrgnd.free.fr/psx/index.html

and place a 10k pull up on the i/o pin that is associated with DAT pin.

on an RPI PICO in overclock this thing is smooth as butter, way better than arduino i will come back and edit in a while when i attempt to retry the library extension i made with out digital IO and see if i can get that one and the HWSPI to work.

//EDIT : apparently what i was trying out originally when it worked was my fastproc.h which true to its name on the pi is actually faster than the Digital IO extension. I just finished trying that out and both bitbangs work.

//EDIT : HWSPI doesn't work. not sure why as i have a functional bitbang on the correct pins for HWSPI so i know its connected correctly, not sure how to proceed on this.

[sonik-br]

The PI PICO does have pullup. I tested it in some random pins and it worked.
Using pinMode(PIN_NUMBER, INPUT_PULLUP); ?