Hi, i am 15 year old student i was always interested in technologies more on the software side i did some web dev (JavaScript, Go, PHP) i really like GO and i would like to stick with it ik that Pico supports TinyGo but is that a good fit for me I want to do some simple stuff to learn the basics because i no longer do anything software and i thought this would spark things out or do you have any other recommendations?

im using a raspberry pi pico that has micropython installed with an spi screen (driver ili9341).

im trying to play bad apple on it but i only have ~ 1mb left on the pi pico.

the images are 16x12 and take up 630bytes by themselves but, despite the small file size, not all of them can fit on the pico due to its 4kb minimum per file. is there any way to fit all 1000 images onto the pi pico to be able to draw them on the screen?.

im not too knowledgeable in micropython so please excuse me if i don't understand some things

This project shows how the BleuIO Bluetooth Low Energy USB dongle can add BLE communication to an Adafruit Fruit Jam powered by the RP2350 to access BLE air quality data.

I have been building USBSID-Pico for a while, an RP2040/RP2350 board that talks to real MOS SID chips over USB. Most of the fun was on the Pico side, and that part is what I want to share.

PIO layout (PIO0)

• The SID clock is generated by a tiny PIO program on GPIO 22. It is two instructions with side-set, and the clock divider is computed from the system clock and the configured SID clock rate.
• Three more state machines run off that same clock pin. One latches the control lines (RW, CS1, CS2), one drives the 16 data/address pins, and one is a delay timer that counts SID clock edges and then raises PIO IRQs to release the other two. That is how a write lands on an exact SID cycle.
• A fifth state machine on PIO1 is a free-running cycle counter that waits on the clock pin and pushes into the FIFO. DMA drains it (endless transfer count on RP2350, two chained channels on RP2040). This creates a 32-bit wide cycle counter.

DMA and cores

• Separate DMA channels feed the control, data and delay FIFOs and read data back from the bus. A hardware spinlock guards the shared words.
• Core 0 runs TinyUSB and config. Core 1 runs MIDI and Network SID Device writes, the LED, and the optional embedded c64 emulator for playing SID tunes without an external player.

Other bits

• USB composite device: 2x CDC (1 for Data and 1 for WebSerial), MIDI, and two vendor interfaces (WebUSB and a second one for fast reads).
• pico_w/pico2_w builds can run a Network SID Device server over TCP with UDP discovery.
• Builds exist for pico, pico_w, pico2 and pico2_w. Default optimization in CMake is -O3 to be sure everything stays in sync.

It plays C64 music with real chips, but I am posting for the Pico side. Source: https://github.com/LouDnl/USBSID-Pico

Happy to answer questions about the PIO side, especially the timing handshake between the SMs. Has anyone else used a PIO cycle counter slaved to an external pin like this?

Hi everyone,

I'm trying to interface a Waveshare ADS1263 High-Precision AD HAT with a Raspberry Pi Pico W using the Waveshare Pico-to-HAT adapter, without jumper wires.

I'm porting the official Waveshare Raspberry Pi Python driver to MicroPython.

Hardware setup:

• Raspberry Pi Pico W
• Waveshare ADS1263 High-Precision AD HAT
• Waveshare Pico-to-HAT adapter
• SPI1: SCK=GP10, MOSI=GP11, MISO=GP12
• RESET=GP18, CS=GP22, DRDY=GP17
• SPI mode: CPOL=0, CPHA=1
• SPI frequency: 100 kHz

What works:

• Power supply and RESET appear normal.
• CS can be controlled between HIGH and LOW.
• DRDY transitions from HIGH to LOW after starting ADC conversion.
• Chip ID reads successfully.
• Several configuration registers can be read back correctly.

The problem:

When I send the RDATA1 (0x12) command to read ADC1 conversion data, the response contains only zeros.

Example output:

REG 0 READ: 0x23
REG_MODE2 success
REG_REFMUX success
REG_MODE0 success
REG_MODE1 success
REG 6 READ: 0x0A
DRDY is LOW
SPI STATUS: 0x00
RAW DATA: ['0x0', '0x0', '0x0', '0x0', '0x0']
Received checksum: 0x00
ADC1 checksum mismatch

I've verified the power rails, RESET, CS, and DRDY using a multimeter. I've also reduced SPI frequency from 1 MHz to 100 kHz, but the problem persists.

My questions:

1. Is there a difference between MicroPython's machine.SPI.read() and the SPI behavior expected by the original Raspberry Pi driver?
2. Could the ADS1263 require a specific SPI transaction sequence, CS behavior, or dummy clocks that I'm missing

Any advice would be greatly appreciated!

def ADS1263_Read_ADC_Data(self):
        config.digital_write(self.cs_pin, GPIO.LOW)#cs  0
        config.digital_write(self.cs_pin, GPIO.LOW)
        try:
            config.spi_writebyte([ADS1263_CMD['CMD_RDATA1']])
            status = config.spi_readbytes(1)[0]
            buf = config.spi_readbytes(5)

            print("SPI STATUS:", hex(status))
        finally:
            config.digital_write(self.cs_pin, GPIO.HIGH)

        read  = (buf[0]<<24) & 0xff000000
        read |= (buf[1]<<16) & 0xff0000
        read |= (buf[2]<<8) & 0xff00
        read |= (buf[3]) & 0xff
        CRC = buf[4]
        # print(read, CRC)
        if self.ADS1263_CheckSum(read, CRC) != 0:
            print("ADC1 checksum error")
            print("RAW DATA:", [hex(x) for x in buf])
            print("Received checksum:", hex(CRC))
            raise RuntimeError("ADC1 checksum mismatch")            

        return read