1. John Maloney Avatar John Maloney
  2. all
  3. SmallVM
  4. Issues

i2c pins for the XRP board

Issue #445 resolved
SC Spaeth created an issue

When I use the RP2040 firmware, I can access the XRP’s pins for the Pico-W LED, xrpButton, xrpLine and ultrasonic sensors, servos, motors and encoders. But I can’t get data out of the IMU (on i2c).

The XRP designers chose the same pins for i2c that designers chose for the Pico:ed board.

https://github.com/Open-STEM/XRP_MicroPython/blob/afd454d6482e3469b382885ffa4133a611a6b452/XRPLib/imu.py#L25C1-L29C38

https://bitbucket.org/john_maloney/smallvm/src/7df01ec56fdbea0f5ce82f7045136a40a09d9a86/vm/sensorPrims.cpp#lines-23 and ff.

So, figured that I could test to see whether the different pin assignments was the reason I could not address the IMU using the RP2040 vm.

When I unplug other sensors and motors from the XRP board (to protect against conflicts with other pin assignments), I can load Pico:ed vm onto the XRP board and then access the XRP’s IMU. (n.b. I don’t have a Pico:ed board).

The graph shows gryo responses for pitch, roll, and yaw of the XRP board.

So, I anticipate that I need an XRP specific vm that is similar to the RP2040 except that it assigns the i2c pins 

    SCL 19
    SDA 18

I welcome other interpretations or suggestions.

‌

Comments (45)

  1. SC Spaeth reporter

    Incidentally, the XRP board has built-in TI motor controllers and precise encoders for four DC motors.

  2. John Maloney repo owner

    So, figured that I could test to see whether the different pin assignments was the reason I could not address the IMU using the RP2040 vm.

    Nice idea to try this.

    The I2C pin assignments are hardwired into the VM for each board so you're right, you'll need a variation of the RP2040 VM for the XRP controller. We've had some conversations with the folks at WPI who created that board, and it has the potential to reach a lot of learners, so it would be good to support it. Do you have a link to hardware documentation for the XRP board? If not, the github link will have all the info.

    As a starting point, I can build an XRP VM that has the right I2C pins and is otherwise the same as the standard RP2040 VM. Are there other essential changes needed? For example, does the XRP board use the standard RP2040 GPIO pin numbers or does it use different numbers?

  5. John Maloney repo owner

    I found the XRP board documentation. (The "Makers Wanted" link on their website.)

    The IMU chip they use is in the same family as another chip we support, so I enabled that and updated the VM at the link above. If it works, you should now be able to use the tilt and acceleration blocks in the "Basic Sensors" library.

    Looks like the XRP board uses standard RP2040 GPIO pin numbers so, assuming the IMU code works, I think this VM is a good fit for that board.

    The rest of the support is a matter of writing MicroBlocks libraries for things like motor control, including support for the motor encoder feature. I didn't see any other features that would require changes to the VM.

  6. SC Spaeth reporter

    John:

    Thank you!

    I didn’t reply earlier because I was at school making additional tests of the WiFiRadio library on the school network. Succeeded in piping sensor data from one board to the other over the school network.

    Kids in the Robotics club saw me working and asked what I was doing. As I explained to them, I sensed anticipation for them getting to try the robots, too. So, yes, student testing and feedback are part of the plan!

  7. SC Spaeth reporter

    I first updated a bare RPi Pico-W using the new vm_pico_xrp.uf2

    It seems to work; I can turn the bare board’s LED on and off. Firmware version says “vm 210 RP2040”. But testing options are few because of limits on i/o for the bare board. Suggestions for other diagnostic tests?

    Then I used the same procedure to try to load the same new vm onto the XRP board, it does not work. Clicking on the usb icon responds “connect the board and try again.” Tried several times.

  9. SC Spaeth reporter

    Wondering whether you used the Pico2040 board or the Pico-W board as the starting point. The XRPs they are delivering now use the Pico-W.

  10. SC Spaeth reporter

    v1 loads on the bare Pico-W, responds to LED on/off, connects to the local network.

    v2 loads on the bare Pico-W, does not respond to LED on/off

    v3 loads on the bare Pico-W, does not respond to LED on/off

    v1,v2,v3 load on the XRP board, cause it to trigger the disconnect device from network alert, but then do not connect to the IDE

  12. John Maloney repo owner

    Thanks for doing all these tests. I'm not sure why none of the new VM's is working on the XRP board.

    You might try power-cycling the XRP board after installing new firmware before you try re-connecting to the IDE. If the XRP board has a battery connected, disconnect that (or turn off the power switch) and also disconnect the USB cable.

    Here's another VM to test. I made a small change the the compilation settings, but it includes support for both WiFI and the accelerometer, as well as changing the I2C pins.

    https://microblocks.fun/mbtest/tmp3/vm_pico_xrp_v4.uf2

  13. SC Spaeth reporter

    I have tried the power-cycling as you suggested.

    By the time I got to the mbtest/temp3/ directory, the file name had changed. But it seemed to be the most recent that you created so I tried that one:

    ../
Touch V2.ubl                                       20-Nov-2023 19:46                4342
vm_pico_xrp.uf2                                    21-Nov-2023 16:44              973312

    Still no luck.

    I also tried using the browser-based IDE but it throws a javascript exception and invites inspection of the console:

    Uncaught TypeError: Cannot read properties of undefined (reading 'apply')
    at _emscripten_asm_const_int (gp_wasm.js:1:128170)
    at gp_wasm.wasm:0x1d629
    at Module._main (gp_wasm.js:1:179084)
    at callMain (gp_wasm.js:1:180399)
    at doRun (gp_wasm.js:1:180796)
    at gp_wasm.js:1:180951

    Could that be part of the problem? Just fishing…

  14. SC Spaeth reporter

    Thank you for producing all of these cases to test. It is very clear to me now why this part of the process is not as straight forward as the library development!

  15. John Maloney repo owner

    By the time I got to the mbtest/temp3/ directory, the file name had changed.

    Try refreshing that page in your browser. I'm seeing:

    Screenshot 2023-11-21 at 4.15.50 PM.png

    The latest version is:

    https://microblocks.fun/mbtest/tmp3/vm_pico_xrp_V4.uf2

    Check that the downloaded file size is correct (e.g. 973312 bytes for V4).

    I also tried using the browser-based IDE but it throws a javascript exception and invites inspection of the console:

    I think this problem is probably unrelated to the VM issues.

    Does the IDE finish loading in the browser or do you get that error while it is loading? If the IDE doesn't load, try holding shift while clicking the page reload button to force the browser to fetch the most recent versions of everything from the server. The "about" box should show version v1.2.46.

  16. John Maloney repo owner

    Thank you for producing all of these cases to test. It is very clear to me now why this part of the process is not as straight forward as the library development!

    Yep! This is a good example -- it seemed like a simple matter of changing the I2C pin numbers but there seems to be something else going on that is specific to the XRP board. (Something like that also happed with the Wukong2040 board and it eventually turned out to be which pin was being used to power the RP2040 board, strange as that may seem. This could be a similar issue.)

    I'm going to see if I can get an XRP kit so I can debug this problem and any other issues that arise. However, it may take a few weeks to get a board. Meanwhile, thanks for doing all these tests.

  17. SC Spaeth reporter

    You were right about browser caching issues. Solved both immediate problems. I’ll go back and check each of the earlier versions. But Thanksgiving dinner preparations will intervene for a bit. ;)

  19. SC Spaeth reporter

    With the refresh of IDE and power down of the board, I am now getting a slightly different response from the connect board request. It opens the dialog but tells me that it cannot find any compatible devices. It’s as if it is not recognizing the serial connection on the XRP.

    In using the PicoBricks library as a template, I recall that you all specifically set the pb_rx and pb_tx pins in the pin assignments:

    https://bitbucket.org/john_maloney/smallvm/src/7df01ec56fdbea0f5ce82f7045136a40a09d9a86/gp/Libraries/Kits and Boards/PicoBricks.ubl#lines-56 and 57

    My list of pin assignments for the xrp library has two gaps in the diagram because I have not found them explicitly identified for the xrp. Did the designers of the XRP board choose a different pair of pins for rx and tx that MicroBlocks is not recognizing?

  20. SC Spaeth reporter

    Similarly: the serialPrims.cpp show that Pico:ed explicitly sets the rx and tx pins because of conflicts with other pin assignments.

            #if defined(PICO_ED)
            // pico:ed edge connector pins 0-3 are analog pins 26-29
            // so use pins 4-5 for serial
            SERIAL_PORT.setTX(4);
            SERIAL_PORT.setRX(5);
        #endif

    Do we need something similar for the xrp?

  21. John Maloney repo owner

    We may need to change the serial pins for the XRP, but the RP2040 doesn't use those pins to communicate with the IDE. Instead, it uses the USB controller module built right into the RP2040 chip.

    Looks like the Pico-W module is soldered on the XRP board, is that right? If it were socketed you could remove the Pico-W from the socket to see if would connect to the IDE by itself.

    Also, be sure that the only power is coming from the USB cable when you test. The external power could be confusing a low-level test for the existance of the WiFI chip that it does at startup.

    It’s as if it is not recognizing the serial connection on the XRP.

    I suspect it is failing early the boot sequence. You might try the V2 (no WiFi) variation again, with the power cycling after installing the firmware. That version is very similar to the pico:ed VM which I think you said did work on the XRP board.

  22. SC Spaeth reporter

    Yes, the Pico-W module is soldered to the XRP board. I repeated tests with careful power cycling. Still no connection for any of the four vm variants.

    But I have a second Pico-W bare board that should act the same way as a socketed Pico-W removed from a hypothetical XRP board (ala Pico-WH on the PicoBricks board). The bare Pico-W loads the vm_pico_xrp.uf2, connects to the IDE, lights the on-board LED, and connects to local WiFi.

    So I returned to the vm_pico:ed and tested it on the XRP again. Confirmed that it connects and supports limited i/o:

    The user LED does not work. I can detect analog data on only the first three pins. Of the basic sensors, only temperature gives any output. The Data Graph shows the active analog pins. I have connected a joystick potentiometer to the Line sensor connector. The red trace represents joystick deflection for one axis. The green trace seems to mimic the red trace at a different scale. I have no idea about the blue trace.

  23. John Maloney repo owner

    Thanks for doing these tests. I'm busy with Thanksgiving stuff most of today but will try to figure out why only vm_pico_xrp.uf2 and the pico:ed VM's are working on the XRP board.

    How would it work for me to buy a board with your teacher discount? Could I pay for it and have it shipped directly to my address?

    I'm hoping that the WPI folks will send me an XRP in return for us adding MicroBlocks support for it but don't expect to hear back from them until next week.

  24. SC Spaeth reporter

    No rush on resolving the vm issues. Family and Thanksgiving are important, too.

    I sent another message to the interest@ account.

  26. SC Spaeth reporter

    It seems as if you are making some progress: v1-v4 could not find any compatible devices.

    But, v5 finds a compatible device, however, when I try to connect to it with the XRP, it does not complete the connection:

    v5 does complete the connection on the bare Pico-W board and supports LED and WiFi services.

    I made some more progress on the parts of the MicroBlocks library for XRP that do not depend on i2c. I have some questions about how to implement those blocks. Where is a good place to discuss those issues?

  27. John Maloney repo owner

    You can send an email to interest (at) microblock.fun to ask about the other issues.

  28. John Maloney repo owner

    Yet another attempt:

    https://microblocks.fun/mbtest/tmp3/vm_pico_xrp_V6.uf2

    This version lacks WiFi support. The user LED will not work because, on the Pico-W, the user LED is controlled by the WiFi chip. I'd like to see if this version will connect to the IDE and allow basic pin IO.

    It includes support for the accelerometer, so if the IDE connects you might try the tilt blocks in the Basic Sensors library.

  29. John Maloney repo owner

    Another experiment you might try with V6 and perhaps also with earlier VMs. After power-cycling the board, try connecting the IDE both with and without external power being supplied through the barrel connector.

  30. SC Spaeth reporter

    Additional information about vm_pico_xrp_v5

    To clear the decks, I remove all pico devices from the serial connection history. Then I try to connect to the XRP board:

    The MicroBlocks tab in my Chrome browser adds the serial connection icon between the tab name and close tab ‘X'. It also adds the Pico W Serial Port to the list of devices that have been connected. But the usb connection icon doesn’t change to solid green circle around the usb icon. Occasionally I have seen an intermittent switching between the ‘connect’ and ‘connected’ icons. As if it briefly makes a connection but can’t sustain it. Have a video if that would help.

  31. John Maloney repo owner

    Thanks for trying this. I know the "flickering green circle" symptom, so no need to send a video.

    One possible problem that has nothing to do with which VM you are running. If you have another instance of MicroBlocks running (e.g. the stand-alone MicroBlocks app) or if you have Makecode running in any tab, even if it is not selected, that can interfere the communications and cause the flickering green circle symptom.

    However, if that were happening, you would see the same behavior with the pico:ed VM.

  32. SC Spaeth reporter

    New reference point for developing a fully functional vm for XRP:
    I have been successfully using a pico vm to develop the XRP library (pin assignments, non-i2c sensors, servos, motors, enoders, …). After trying another experimental vm, I updated the firmware using the the IDE to load the current Pico/Pico-W vm directly in the browser. That vm reproduced some of the same responses that I have described in recent posts on this thread.

    But I knew that I had a working vm on the XRP for all but the i2c control. So, I searched again and found the specific vm that works for a majority of functions on the XRP. Could the failure to connect come from a conflict between the pico and pico-w versions?
    vm_pico_w.uf2 Created: Monday, July 24, 2023 at 11:35 AM

  33. John Maloney repo owner

    I think the issue involves using the Pico-W VM's on the XRP board. More precisely, I think the Arduino startup code is not correctly detecting that it is running on a Pico-W when it is run on the XRP board.

    Re:

    vm_pico_w.uf2 Created: Monday, July 24, 2023 at 11:35 AM

    Does that VM run on the XRP? Where did you get it?

    Which VM have you been using to develop the XRP library?

  35. SC Spaeth reporter

    If it’s important, I’ll have to dig further to refresh my memory of how it found it.

  37. John Maloney repo owner

    Yep! I think you got that .uf2 from a pilot release around July. We don't archive every Pilot release, only stable releases, so that version is no longer available.

    Does the current version work:

    https://microblocks.fun/downloads/v1.2.46/vm/vm_pico_w.uf2

    If not, could you see if the previous stable release worked:

    https://microblocks.fun/downloads/v1.2.24/vm/vm_pico_w.uf2

    Thanks for all this testing. I should be getting my XRP tomorrow so then I can do my own testing.

  39. SC Spaeth reporter

    Don’t worry about requests for testing. They are all part of my learning process that I welcome. But I also understand that it will make your work-flow smoother to be able make your own tests!

  42. John Maloney repo owner

    Yep! But now I'm puzzled about why most or all of the WiFi-based test versions failed. Probably something silly that I overlooked...

  43. SC Spaeth reporter

    Gyro data from the XRP board using the new vm!

    Red: pitch, Green: roll, and Blue: yaw. Chalk one up for open source collaboration!

  45. John Maloney repo owner

    Great work on the gyro library. Makes sense to mark this issue resolved but open for comments about XRP development.

  46. Log in to comment
Assignee
–
Type
enhancement
Priority
minor
Status
resolved
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!