machine.u2if.py line 40 self.serial_number = instead serial_number =

[PaulskPt]

when using machine.u2if.py I was confronted with an error
I investigated the cause. I found that
line 40 reads: serial_number = self._hid.serial

and line 49 reads: return self.serial_number.

When I changed line 40 into: self.serial_number = self._hid.serial
the error disappeared and I got an answer: the serial number of the Pico.

[execuc]

Hello,
I'm not sure I fully understand, is there a link between the description of the problem and the screenshot?

Normally the serial number is assigned to the object in line 20. Could you show the start of your script because normally there is no need to instantiate the class u2if.Device yourself (indirectly by a Machine class such as Pin).

If there is a need to select a pico with a particular S/N you can call machine.select_interface ("0xYYYYYYYYYYYYY") at the very beginning of the script.

[PaulskPt]

Hi execuc,
Thank you for your reply. I just got to know the existance of your repository. I came across it on Adafruit.com. I am currently experimenting with a RPi Pico and a Pimoroni Pico Audio Pack, connected back-to-back. I already managed to build a C++ example and getting a preprogrammed sequence to play. But I am not good at C++. It is like fighting a war for me. Especially the whole (extra) language for CMake around it. I prefer the freedom of Python. So, I followed the steps explained in that article of Adafruit. I don't have really a script yet. I was just doing some steps in a Python3 session from within Linux Ubuntu 20.04. Before writing this answer I looked again at the script of u2if.py, especially that for loop that surrounds line 40. Then I thought: ah, maybe execuc just meant to use 'serial_number' in there as being a local variable. Anyway, thank you for giving me clarification on not needed to instantiate the u2if.Device class and about selecting a particular pico. The latter is new to me. If you have more documentation I would gladly get to know it. I think your u2if repo gives me opportunities to reach several of my current goals.

[PaulskPt]

A question: the pcb 'PICO-DEV-V2' you created or is it a board that is commercially available?

[PaulskPt]

I created a script in which, among some things, I tried to blink the built-in led of the RPi Pico (Pin 25). See the attached images for the contents of the script and an image of the printed results. In the file u2if_const.py I inserted a definition for GP25 but nevertheless I get the error shown on the screenshot.

[execuc]

I understand better what you want to do and you may not have to use this project.

There is always the possibility of programming the pico directly in C ++ but it is also possible to code in Python with MicroPython (https://www.raspberrypi.org/documentation/rp2040/getting-started/#getting-started-with- micropython) or Adafruit CircuitPython (https://circuitpython.org/board/raspberry_pi_pico/).

If you want to control electronics from your PC, for example, to have buttons that launch actions on your PC and status leds, then you can use this U2IF project. It is then necessary to install the firmware u2if.uf2 in the PICO.
Then there are two possibilities:

• Either you use the python code of this repository.
• Either you use Adafruit's Blinka python code (https://github.com/adafruit/Adafruit_Blinka) which is compatible with a lot of libraries (lcd, sensors ...). They added compatibility with u2if firmware.

In the u2if case, if you want to light a led, all you have to do is:

import time
from machine import u2if, Pin, Signal

# Initialize GPIO to output and set the value HIGH
led = Pin(u2if.GP3, Pin.OUT, value=Pin.HIGH)
time.sleep(1)
led.value(Pin.LOW)
time.sleep(1)
led.value(Pin.HIGH)

However, it is not possible to act on led of Pin 25 in the u2if case because it is permanently modified by the firmware (status led).

About PICO-DEV-V2, it is a board that I created with KiCAD, there are gerber files if you want to make one.

[PaulskPt]

Hi execuc,
Thank you very much for your reply, your explanation and advice.
Yes, the first thing I did was flashing u2if.uf2 to the Pico.
OK on the built-in led used as a status led. Yes, I saw, that the led blinked in a certain fashion during as soon as the reset() was passed.
I'll go to do a test with an external led tomorrow.

I worked the whole day intensively to find solutions to several problems I was confronted with.
Getting the board found. When found saving vid, pid and serial_number into the self. variables. I found it more practicle to put the vid and pif of the pico as last items in the COMPATIBLE_BOARD_PID_VID list. In my case, using a Pico, the last board will be found.
I inserted a lot of print statements (for debugging and seeing: 'where are we?). I switch them on/of with a global my_debug flag.
The main problem that I encountered were 'ValueError : not open". Then, due to these errors, the subsequent "if res[1] != report_const.OK:" resulted in an error because res was of NoneType. I inserted checks for NoneType to catch them.
I created while loops in which I catched and handled the ValueError : not open errors.
When they occurred I opened the device in an added function: open_hid() and continued the loop until ready to exit the loop.
I counted that the res lists contained 64 items, so I created a function create_lst() that creates a list of 64 items, all value 0.
OK, maybe not everything I did is/was necessary but for me the important thing is that I got it working now. A simple script to get the built-in led blinking.
FYI I'll add the modified u2iu.py, pin.py, u2if_const.py and my script: psk_blink.py.
I appreciate your comment(s).

mods.zip

[execuc]

Hi,
Thank you for your feedback. I modified this part (opening and COMPATIBLE_BOARD_PID_VID) not long ago to be compatible with Adafruit board and there is surely a bug. In addition I have only tested under Linux (Debian). What is your OS ?

I will take a look as soon as i can.

[PaulskPt]

Hi execuc,
I think the COMPATIBLE_BOARD_PID_VID list is OK. I only moved the part for the Pico to the last position because that had just a cosmetic effect during the tests. Before the move there was first a message that the Pico board was found and then followed four messages for other boards not found. After the move the last board checked, the Pico, was reported found and so de device.open() was called etcetera.
Yesterday I did all the modification and testing while running my main desktop PC in Linux Ubuntu 20.04. On my main desktop PC I have a separate harddrive from which I can boot Linux at boot-time from a BIOS boot-menu (F12).
Before, when u2of still was not running for various reasons, I was working on the same PC but booted with MS Windows 10 Pro (latest) but in WSL1 Ubuntu 20.04. Now I have u2if running I go to check today in the Windows environment.
I just looked into a set of screenshots I made the past few days. I came across one (see attachment 1) during a "hand" run of Python3, from within MS Windows / Terminal -> WSL1 -> bash. I tried to do a "device.open(0xcafe, 0x4005)" and it failed with "OSError: open failed". Next I upload here two other screenshots.
So far this feedback. Greetings from Lisbon.

[PaulskPt]

I just ran a successful test within MS Windows 10 from within Windows Terminal.
A few minutes b4 I ran it with the command 'python3 psk_blink.py' and got a module hid not found. I then did a 'pip3 install hid' with success. Ran again. Yet, another 'module hid not found' error. I then issued: 'python psk_blink.py' and that ran OK. I discovered that 'python3' in fact is 'Python ActivePython 3.8.2 (ActiveState Software Inc.) and 'python' is: 'Python 3.9.0 [MSC v.1927 64 bit on win32] from Microsoft.
Attached a short video made with my mobile phone. (Attachment #2)

Yesterday late evening. I made a short video of a testrun at that moment. See Attachment #1 for a snapshot of that video showing the search for a compatible board results.

2021-06-16_12h39_psk_blink.py_testrun.mp4

[PaulskPt]

Conclusion about experiment results yesterday: I think that various error like 'module hid not found' and 'OSError' were caused by the fact that I used that 'ActivePython' from ActiveState Inc. that did not do its job as expected but I did not realize myself that I was using a 'special' version of Python3.

[PaulskPt]

OK, I uninstalled ActivePython 3.8.2 from ActiveState Inc. Then there were two Python versions, both Microsoft's, active. (See attachment #1). Running psk_blink.py with 'python3' again resulted in module 'hid' not found. Running the script with 'python' ran OK. A 'pip3 install hid' reported various 'Ignoring invalid distribution'. After reading an article on StackOverflow I checked and discovered that I had three folders in C:\Python39\Lib\site-packages subfolders which names started with a tilde (~). I removed them. After this I checked 'pip3 install hid' again and no more install error. Instead: 'Requirement already satisfied: hid in c:\python39\lib\site-packages (1.0.4)'. Conclusion: on my desktop PC running MS Windows 10 I have to run u2if scripts using 'python' (3.9.0 from Oct 5 2020, installed in c:\python39).
I checked also the env var 'PYTHONPATH' which was set for 'F:\python38'. I changed it to 'c:\python39'
Excuse me for bothering you with all this 'noise'.

[PaulskPt]

Hi execuc,
A short update. Yesterday I made changes to some previous changes I made to u2if.py, especially the checks for res being None. I changed them all to 'if not res is None:' instead of my earlier (more complicate version). I also experimented with tests to check if the serial port was open or not. The files modified are in the attached mods2.zip. Then: Yesterday evening late, I started with trying (for a second time?) to run that play sound example in Ubuntu Linux. The script ran. The serial port was open. I saw the buffer being rapidly filled with a datastream until the script at the end reported 'Done' but I did not hear sound. I have some screenshots. This morning I tried the same play sound script from within MS Windows 10. It failed, reporting it could not open the port, which I checked in the O.S. that COM27 was attached to the RPi Pico in use. Attached the two modified files (u2if.py and i2s.py), a .txt file with the audio stream data and my observations and a screenshot of the test this morning in Windows 10.

mods2.zip

[PaulskPt]

An 'afterburner' This morning, after playing the sound script was no success within MS Windows, I booted my desktop PC into Ubuntu 20.04. I ran the play soundfile script again. It ran. The built-in led (status) blinked in a fast rythm (when putting the datastream into the buffer?). At the end the script printed two numbers and on the next line 'finished'. But I did not hear sound out of the speaker wired to the 'line out' or the 'phones' connector of the Pimoroni Pico Audio pack. Maybe I'am using the wrong pin's. On the webpage of the Pico Audio Pack is written about the Pin's: You'll need to #define PICO_AUDIO_I2S_DATA_PIN and PICO_AUDIO_I2S_CLOCK_PIN_BASE to 9 and 10 respectively to tell the examples which pins are being used for the audio data.'
Attached a screenshot of this test

[PaulskPt]

To be sure that I have the right firmware flashed I: from within Ubuntu I re-flashed the Pico with the 'u2if_pico_i2s_v0.5.0.uf2' from /u2if/firmware/release (built on 2021-06-15) just a moment ago. Ran i2s_play_sound.py again, but no audio. Only the led (status) blinking in the rythm of the datastream transfer. I am almost sure that the 'no audio' is caused by Pin definition.

[PaulskPt]

2021-06-17_RPi_Pico_U2IF_I2S_play_sound_test.mp4

In u2if/firmware/source/source I found the files: board_config.h and board_config.h.in. Each of them defines for the Pico's I2S,
U"IF_I2S_SD 12. Guessed that this is the definition for the 'DATA'. I changed it to 9. The other 'U2IF_I2S_CLK 10' for the CLOCK appeared OK to me. I modified the definition for the DATA pin in both files, re-built using /u2if/firmware/build-all.sh. Flashed the /u2if/release/u2if_pico_i2s_v0.5.0.uf2. Then ran the 'i2s_play_sound.py'. And: voilá: I heard the sound coming out of the loudspeaker! I created a video of 10 seconds but it is too large: 19,6 Mb. I have to boot MS Windows and use my Nero/Video editor program to shorten and convert it to .mp4. Then I'll upload it.
To conclude: I am happy/satisfied. The things that I initially wanted to achieve through your U2IF repo has been acomplished.

[PaulskPt]

Latest. The U2IF I2S play a song does not work in MS Windows 10. Looks like a rights problem. Also it doesn't work in MS Windows / WSL1/Ubuntu. In that environment it does not show a comport like /dev/ttyACM0 like in a 'real' Ubuntu O.S. session. I edited a Starwars intro .wav file. The I2S player didn't accept because it detected it was mono. So I converted the file into stereo (L and R the same audio). That worked.

[PaulskPt]

For me we can close the issue.

[execuc]

First of all, thank you for persevering. It really pleased me to see your video with the PICO playing the sound!

Indeed I looked the Pico Audio Pack and it does not use the same pins as what I fixed in #define. For information the file "board_config.h" is generated from "board_config.h.in" by the cmake.

For mono sound, it is normal that it does not work because for the moment, the firmware only manages 16bits stereo. I have to make it evolve, knowing that now there is a user! Mono would reduce the bandwidth of the usb.

Do you have several PICOs connected at the same time ? Because otherwise there is normally no need to specify the serial number. Anyway, it should work on Windows 10 and WSL base so I'll investigate when I can.

[PaulskPt]

Hi execuc! Thank you for your reply. I am happy that you liked the short video. I did not have other Pico's attached at that moment. I own four of them. I have also a Arduino Nano RP2040. An hour ago I was studying the c:\python39\Lib\site-packages\serialwin32.py and .win32.py. I hoped to get a grasp why your U2IF repo I2S play a song example does not go in Windows or Windows/WSL1. OK, fine that you want to investigate more when you can. I am already some time in pension. So, I have a lot of free time :-) If I can be of some assistance don't hesitate to ask.

[PaulskPt]

I have been spitting a little time in MS Win 10 using SysInternals.com's Process Explorer. Attached a annotated/cleaned screenshot giving details and Symlinks to two entries as USB and HID for the serial port the RPi Pico currently is connected to (COM27).

[PaulskPt]

Popped back into my mind the following question: why has your repo a complete copy of the pico-sdk ? Because you modified some of that repo's file(s)? I see that it is a little over 1,4GB of disk space it takes. I already have pico-sdk installed on the pc and have set the PICO_SDK_PATH. If you did not modify anything then I think I can delete that (double) installation. Don't you think?

[execuc]

Hello,
I didn't make any changes on pico-sdk, you can delete it if you set PICO_SDK_PATH elsewhere. It is to facilitate the compilation that it has been included as a git sub-module.