add putAll procedure

[Martinix75]

Putall () allows you to write the entire register by providing an Uint32. Much more comfortable than providing every single value for each individual bit. In addition you can use the bit meat and shift (right left of the bits)

[Martinix75]

Hi Jason, as you can see I added the "Putall ()" function to the gpio.nim file (and tested). I wondered if it is worth making a special example for this function or if not needed (it is very simple). Hi by Andrea

[beef331]

I think value should be a bool as it only cares if it's on/off, I do not recall well though.

[Martinix75]

putall() accepts a "uint32" (obviously first the pin must be enabled) here is an example "supercar" with 3 LEDs:

import picostdlib/[gpio, time] setupGpio(led1, 13.Gpio, Out) setupGpio(led2, 14.Gpio, Out) setupGpio(led3, 15.Gpio, Out) var xx: uint32 = 0x2000 #set register init @ 10000000000000b (led1 = on, led2= off, led3=off) var flag: bool = true

while true: putAll(xx) if flag == true: xx = xx shl 1 if xx == 0x8000: #= 100000000000b (led1=off, led2=off, led3=on) flag = false elif flag == false: xx = xx shr 1 if xx <= 0x2000: flag = true

sleep(700) run perfectly!

[auxym]

I think this function would be useful, but the argument being set[Gpio] instead of a bare uint32 would be nicer to use and a better fit with the existing api.

[Martinix75]

This function should (I think) be something similar to "DDRD= B11111110;" (avr/io.h) of Arduino. Then I don't know the internal implementation!

In any case, it is really convenient to write a number (Uint32) to set all the "qualified" outputs as such in a single shot.

[beef331]

I think this function would be useful, but the argument being set[Gpio] instead of a bare uint32 would be nicer to use and a better fit with the existing api.

Oh this makes all the pins in a set high? If so then yes set[Gpio] is the best parameter as it's much more sane to do

const AllPins* = {Gpio(0)..Gpio.high}
putAll(appPins)

[auxym]

Yeah.

@Martinix75 made a case that someone might want to do bit twiddling, like shifting to make LED effects. Sort of niche, but maybe a case for exposing both interfaces, bare uint32 and the set. Or we can make bit-twiddlers do some casting? Like putAll (mySet.cast[uint32] shl 1).cast[set[Gpio]].

Other point if we go for a set: currently Gpio is defined as 0..35 so a set doesn't fit into a uint32. Someone would have to dig into the pico/rp2040 docs to understand what's going on.

[beef331]

Yea I'll say lets get a overload that takes set[Gpio] and the uint32 variant, perhaps with a more elaborate comment.

[Martinix75]

In addition, it would also be nice (but later, maybe when I can test) also wrapping the function:

static inline uint32_t gpio_get_all(void) { return sio_hw->gpio_in; }

that it also returns an Uint32 (mask) always to handle a "number" instead of individual bite

[auxym]

So I'd be OK with merging a putAll(uint32) proc. My only remaining concern is naming. the current gpio procs are differentiated because they take a distinct Gpio type as argument. putAll(uint32) is a bit ambiguous in its naming. What does it do?

I'd propose maybe naming it putAllGpio? @Martinix75 @beef331 what do you think?

The absoluteTimeDiff one should probably go in a different PR though.

[beef331]

Your name is better, the docs also need to explain what it does better. Something along "Takes in the state of the gpio pins as a bit in an uint32, and sets the state of them to that." And yes absoluteTimeDiff should be in another PR.

[Martinix75]

The name "putAllGpio ()" seems better and clearer to me on what he does. I like!!!

I thought I had opened a new Commit for "absoluteTimeDiff" I am not very good with Git still struggling much to use it, I apologize !!