This doesn’t really have anything to do with the topic discussed here. You might have more luck at https://forums.raspberrypi.com/viewforum.php?f=143.
@neilstansbury Do you have any news on your activities? Do you have a github link or anything where we can follow what you are doing? Do you need any help at all?
Thanks for your post anyway, helped me understand this complicated topic.
Hey @luke234234124 yeah sure, this is where I currently stand personally…
I forked all the Wizio repos here: Tactory.io · GitHub and I am and will continue to bug-fix back to them as I find stuff. Nothing magic just bug fixes. PRs to those are very welcome.
Wizio is obviously done with this, so I am on my own AFAIC.
I haven’t looked to target the RP2040 SDK v1.5x
yet, it’s on my to-do list, but at the moment everything I want works so the pain hasn’t been justified for me. It will be in the near future as there are some SDK updates I’d quite like. When that time comes, that will be a complete re-write and a new PIO Framework.
I did look at writing shims for the Arduino APIs as I mentioned and got through a few, but the more I dug into the Arduino API internals the more I realised I disliked them and frequently found them ill-conceived and poorly designed, and they mapped poorly onto the RP2040 calls.
I did get some way cherry picking stuff from the EPH core, but got into dependency hell and started having to include and/or re-write a ton of stuff I didn’t need or want.
In short I made the decision to dump Arduino and use Wizio baremetal
for my key projects and then only use the EPH Core
when I need a load of Arduino stuff or I’m just being lazy.
I want the complete RP2040 SDK and full access to the C++ dev environment, I don’t “do Python” so that stuff is of no interest to me personally.
I love the RP2040 and will be my chosen MCU for all work going forwards. The docs and examples are great and the community help is awesome, to the extent I have just finished building my first RP2040 PCBs.
The RP2040 SDK is really well documented and dead easy to write to, and you get to screw around with the proper low level stuff when you need or want to.
I have finished porting directly over some 3rd party libs like TinyGPS+ and some key parts of Adafruit GFX and need to get those published.
Feel free to ping me if you have any more questions.
try this
I have a sort of a basic question but I am using WIZ-IO to program Raspberry Pi Pico and the content available on the internet is either too basic or too professional and I cannot find help with nitty gritties that I sometimes require.
I am trying to operate PIO´s state machines, here is my PIO code.
.program data_sender
.wrap_target
pull block ; Wait and pull next data from FIFO
wait 1 pin, 0 ; Wait for the clock (base pin) to go HIGH
out pins, 1
.wrap
% c-sdk {
void data_sender_program_init(PIO pio, uint sm, uint offset, uint pin, float div) {
pio_sm_config c = data_sender_program_get_default_config(offset);
pio_gpio_init(pio, pin);
sm_config_set_out_pins(&c, pin, 1);
sm_config_set_clkdiv(&c, div);
pio_sm_init(pio, sm, offset, &c);
pio_sm_set_enabled(pio, sm, true);
pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, true);
}
%}
Then in the main code, this is the state machine,
//Initialize data sender
uint data_sm = pio_claim_unused_sm(pio_0, true);
uint offset_data = pio_add_program(pio_0, &data_sender_program);
pio_sm_config c = data_sender_program_get_default_config(offset_data);
data_sender_program_init(pio_0, data_sm, offset_data, AUDIO_PDM_PIN1, div_clock);
pio_sm_set_enabled(pio_0, data_sm, true);
sm_config_set_out_pins(&c, AUDIO_PDM_PIN1, 1);
pio_sm_set_consecutive_pindirs(pio_0, data_sm, AUDIO_PDM_PIN1, 1, true);
and then
in the while loop I am doing this
if (buffer_data_index > 0) {
uint byte_to_process = buffer_data[0];
uint bit_to_send = (byte_to_process >> (7 - bitPos)) & 1;
if (!pio_sm_is_tx_fifo_full(pio_0, data_sm)) {
pio_sm_put_blocking(pio_0, data_sm, bit_to_send);
}
As far as I can understand, this should output the bit_to_send on the selected GPIO. But it doesn´t, and I have to do this
gpio_put(AUDIO_PDM_PIN1, bit_to_send);
gpio_put(AUDIO_PDM_PIN2, 0);
I am doing
gpio_put(AUDIO_PDM_PIN2, 0);
this because I don´t want my other pin to be working when first pin is sending data. This also cannot be achieved by doing something like,
set pins, 0
or some combination of wait instrcution with “nop”.
I don´t know what am I missing here but can you help?