added spi_get_baudrate() + some consistency changes

[Reneg973]

• new function to query the current baudrate
• new helper check whether SPI is busy

• consistency changes

• return a boolean for functions with a "is; has; can" in name
• return unsigned value for number of bytes read/written
• some const correctness

[lurch]

GitHub says that this has a conflict already?

[kilograham]

don't think this should be const; sure the method itself doesn't write thru it, but it sure does cast it to a mutable pointer

[Reneg973]

I propose an alternative, add an additional function:
static inline const spi_hw_t *spi_get_hw_const(const spi_inst_t *spi) {

Needs some more changes. Agreed?

[kilograham]

we don't do this for any hardware; not least there may be registers for which reading has side effects.

[Reneg973]

Your decision, both ways are possible. Anyway my experience is that const correctness can expose possible issues in code.

E.g. check function hw_is_claimed(), the function name says it just checks, but in reality it claims, so it does more than expected. One of the rules I try to follow - no surprises. And if hw_is_claimed() modifies something another function (hw_claim_or_assert) is made for, IMO this is a surprise

[kilograham]

ha - yes that is a bug! I'm all for const pointers to any data struct, i was just on the fence in the h/w pointer case. Anyway, we can't do this as it requires a cast away of const... as you say we could add a spi_get_hw_const which I'm not whoilly against, but I don't think is necessary.

[Reneg973]

right, that's ok here, it's just a simple function where const correctness is not of any meaning. I'll remove it - but then it must be removed for every const correct function which uses it... compiler thingy

[Reneg973]

I made a proposal with commit 5a043a2. Please check whether it's ok or needs a revert

[kilograham]

please rebase onto latest develop (as there is a merge conflict)

[kilograham]

ha - yes that is a bug! I'm all for const pointers to any data struct, i was just on the fence in the h/w pointer case. Anyway, we can't do this as it requires a cast away of const... as you say we could add a spi_get_hw_const which I'm not whoilly against, but I don't think is necessary.

[kilograham]

try building kitchen_sink ... there are a bunch of compiler warnings

[kilograham]

Also, frankly I'm not convinced by switching the return values to size_t... generally we haven't been using size_t stylistically (I know that the params were size_t), however where functions do return a value it tends to have the possibility of an error code.

[Reneg973]

try building kitchen_sink ... there are a bunch of compiler warnings

thanks for the tip. Building this also finds other warnings like unused functions in stdio and a missing delete operator in new_delete.cpp. How do you handle these?

[Reneg973]

however where functions do return a value it tends to have the possibility of an error code.

In general this is fine. Anyway for these functions currently there are 3 arguments against it.

1. the function never returns an error (it is automagically included, if the return is != input len)
2. the documentation doesn't tell anything about possible error code
3. even if the use case may not exist, providing a size_t len which is larger than int will result in a negative value, which is not expected.

Checking for transfer error is still possible by comparing the return value with the input len, but now without a signed/unsigned mismatch comparison.

[lurch]

a missing delete operator in new_delete.cpp

See #304 ?

[kilograham]

try building kitchen_sink ... there are a bunch of compiler warnings

thanks for the tip. Building this also finds other warnings like unused functions in stdio and a missing delete operator in new_delete.cpp. How do you handle these?

hmm; what compiler are you using... i don't see those warnings

[kilograham]

however where functions do return a value it tends to have the possibility of an error code.

In general this is fine. Anyway for these functions currently there are 3 arguments against it.

1. the function never returns an error (it is automagically included, if the return is != input len)

2. the documentation doesn't tell anything about possible error code

3. even if the use case may not exist, providing a size_t len which is larger than int will result in a negative value, which is not expected.

Checking for transfer error is still possible by comparing the return value with the input len, but now without a signed/unsigned mismatch comparison.

Yes, i was talking about consistency in the API with other APIs, so this is in general.

1. yes, but doesn't give you the option of return what error
2. sure
3. this is a 32 bit microcontroller; providing a >31 bit value is never going to be valid... this is why size_t wasn't used anywhere really (and when I say anywhere, yes these APIs do use it).

[Reneg973]

hmm; what compiler are you using... i don't see those warnings

PICO_GCC_TRIPLE defaulted to arm-none-eabi
-- The C compiler identification is GNU 10.2.1
-- The CXX compiler identification is GNU 10.2.1

[57/259] Building C object CMakeFiles/kitchen_sink_no_flash.dir/D_/PicoSDK/1.1.2-Git/src/rp2_common/pico_unique_id/unique_id.c.obj
[58/259] Building C object CMakeFiles/kitchen_sink_no_flash.dir/D_/PicoSDK/1.1.2-Git/src/rp2_common/pico_multicore/multicore.c.obj
[59/259] Building C object CMakeFiles/kitchen_sink_no_flash.dir/D_/PicoSDK/1.1.2-Git/src/rp2_common/pico_stdio/stdio.c.obj
FAILED: CMakeFiles/kitchen_sink_no_flash.dir/D_/PicoSDK/1.1.2-Git/src/rp2_common/pico_stdio/stdio.c.obj
D:\2020-q4-major\bin\arm-none-eabi-gcc.exe -DPARAM_ASSERTIONS_ENABLE_ALL=1 -DPICO_AUDIO_DMA_IRQ=1 -DPICO_BIT_OPS_PICO=1 ... lots_of_includes... pico_stdio/stdio.c
D:/PicoSDK/1.1.2-Git/src/rp2_common/pico_stdio/stdio.c:203:13: error: 'stdio_buffered_printer' defined but not used [-Werror=unused-function]

[Reneg973]

Yes, i was talking about consistency in the API with other APIs, so this is in general.

Ok, so revert?

[kilograham]

Yes, i was talking about consistency in the API with other APIs, so this is in general.

Ok, so revert?

yes please, whilst i can see why you might want to, I don't see enough value in changing the API

[lurch]

D:/PicoSDK/1.1.2-Git/src/rp2_common/pico_stdio/stdio.c:203:13: error: 'stdio_buffered_printer' defined but not used [-Werror=unused-function]

Perhaps that function just needs a #if LIB_PICO_PRINTF_PICO wrapped around it? https://github.com/raspberrypi/pico-sdk/blob/develop/src/rp2_common/pico_stdio/stdio.c#L219

[Reneg973]

ok is reverted. Did you realize that these function in no case return the transferred len? Should I do this with this PR too?

[kilograham]

ok is reverted. Did you realize that these function in no case return the transferred len? Should I do this with this PR too?

do you mean in all cases?

[Reneg973]

ok is reverted. Did you realize that these function in no case return the transferred len? Should I do this with this PR too?

do you mean in all cases?

I mean they return the input length and not what was really sent => wrong docu or wrong implementation?

[lurch]

I mean they return the input length and not what was really sent

This may be a stupid question, but for SPI how would those numbers ever be different? 😕

[Reneg973]

I mean they return the input length and not what was really sent

This may be a stupid question, but for SPI how would those numbers ever be different? 😕

Not with SPI itself, of course. But I am sure you heard about bit failures :)

Ok, it just a bit confusing for me seeing interfaces which force the caller to do error checking but there is no error checking in implementation at all.