"LED" is universal but 25 still works on a Pico though not a Pico W. BIPES defines the pin as "LED/GPIO25" for a Pico and emits "25" and as "LED/WL_GPIO0" for a Pico W and emits "LED". It would be better if both emitted "LED".I'm surprised that Pin(25) still works: I thought that Pin("LED") was universal now.
I still believe MicroPython made a mistake in how they handled that refactoring, having '25' do something different on Pico and Pico W. My own universal port handles "LED" and "25" as synonymous, controls the LED either way, with "WL_CS" if you really want to control GPIO25 and the CYW43, throwing an exception if you try to use that on a Pico.
I was a bit surprised BIPES allows non-ADC pins to be selected for "Read RPI Pico ADC Input". When I was involved in creating a Blockly editor for a non-Pico product there was a lot of effort put into blocks only accepting what a block could accept, not allowing download of code which wouldn't compile or didn't do what would be expected. This was particularly the case for I/O when only a subset of pins could be used for input or output, ADC or other functions.
We also had error flags shown in blocks where the device had changed and what was specified was no longer valid so users could easily see what they had to change, such as having used 'LED/GPIO25' when changing to Pico W.
That's not to say BIPES isn't a great and useful offering.
I wasn't a great fan of Scratch, Blockly or Snap!, was rather dismissive and negative towards them, until I discovered MIT App Inventor for developing code for Android. That's when I came to understand why others found them so useful and easy to use.
Statistics: Posted by hippy — Thu Apr 11, 2024 2:03 pm