Make quantum/split_common/serial.[ch] configurable

[mtei]

quantum/split_common/serial.c change to helix-serial.c style serial configuration

This request does not change the compilation results.

reffer #3709, #4254.

[drashna]

Rather than changing all of the files, it may make more sense to add:

#ifndef SOFT_SERIAL_PIN
#define SOFT_SERIAL_PIN D0
#endif

[drashna]

Couldn't this be added to serial.h, rather than using a separate file?

[mtei]

Do not worry, this serial_backward_compatibility.h will be deleted in the next phase.

[drashna]

Could define the default here:

Suggested change

	// #define SOFT_SERIAL_PIN ?? // ?? = D0,D1,D2,D3,E6
	#ifndef SOFT_SERIAL_PIN
	#define SOFT_SERIAL_PIN D0 // D0,D1,D2,D3,E6, etc
	#endif

This way, there is no reason to define it elsewhere.

[mtei]

see
#4419 (comment)

[drashna]

Suggested change

	// #define SERIAL_SLAVE_BUFFER_LENGTH MATRIX_ROWS/2
	#ifndef SERIAL_SLAVE_BUFFER_LENGTH
	#define SERIAL_SLAVE_BUFFER_LENGTH MATRIX_ROWS/2
	#define SERIAL_MASTER_BUFFER_LENGTH 1
	#endif

[mtei]

see #4419 (comment)

[drashna]

Shouldn't this be left in serial.h?

[mtei]

see
#4419 (comment)

[drashna]

This should probably be changed to something like

Suggested change

	#ifndef USE_I2C
	#if defined(USE_SERIAL) || (!defined(USE_I2C) && !defined(USE_SERIAL) )

[mtei]

The USE_I2C,USE_SERIAL problem can be discussed by me or someone else in the next next phase. I will not change it now.

[mtei]

I posted #4522. This is the solution to this problem I thought.

[mtei]

Rather than changing all of the files, it may make more sense to add:

#ifndef SOFT_SERIAL_PIN
#define SOFT_SERIAL_PIN D0
#endif

Yes, I know that. But I chose to add the definition of SOFT_SERIAL_PIN to each config.h. Because other drivers do not have a default value, so I think that serial.c should also have no default value.
(quantum/quantum.c:BACKLIGHT_PIN, drivers/avr/ws2812.c:RGB_DI_PIN, quantum/audio/audio.c:??_AUDIO)

[drashna]

Yes, I know that. But I chose to add the definition of SOFT_SERIAL_PIN to each config.h. Because other drivers do not have a default value, so I think that serial.c should also have no default value.

If that's the case, we're getting to the point where we NEED documentation for the SPLIT code.

Though, on the flip side, for the boards that don't want to define a soft serial pin, and want to leave it using the same pin as i2c, this is essentially an added, unnecessary change for those boards. It also make porting new boards over more problematic (though, I think travis should catch that).

[mtei]

If that's the case, we're getting to the point where we NEED documentation for the SPLIT code.

Though, on the flip side, for the boards that don't want to define a soft serial pin, and want to leave it using the same pin as i2c, this is essentially an added, unnecessary change for those boards. It also make porting new boards over more problematic (though, I think travis should catch that).

Please do not do that discussion here. Let's discuss that in #4254
#4254 (comment).

In here, I want to talk about whether serial.c should have default value or not.

We can easily change it to have a default value at any time. However, If we want to explicitly define SOFT_SERIAL_PIN it is the easiest to do now. The more keyboards we add, the harder it is to work. So, now, I think that it is better to explicitly define SOFT_SERIAL_PIN.

[nooges]

I do prefer that there be a default value for the serial pin to minimize overall code changes.

[drashna]

Thanks!

Now to phase 2?

[mtei]

Thank you.

I will start the next phase.