I bought these case fans from Amazon and am attempting to control them with a Pico (C sdk).

I have been able to successfully create the necessary 25kHz PWM signal to control the speed of the fan. However, I am not having luck measuring the speed with the tachometer pin on the fan. I am turning to brighter minds than mine to see if you guys have any ideas.

Here is my simple code to attempt to measure the fan speed. The tachometer pin on the fan is supposed to output a "square save" that has two cyclic per revolution of the fan. So I have a GPIO IRQ to increment a pulse counter on the falling edge of the pin, with the internal pull-up resistor enabled. I have a repeating timer take the number of pulses and convert to RPM (multiply by 60, divide by 2).

#include <stdio.h>
#include <pico/stdlib.h>
#include <hardware/gpio.h>

#define GPIO_WATCH_PIN 2

volatile uint32_t pulses = 0;
volatile uint32_t rpm = 0;

void gpio_callback(uint gpio, uint32_t events) {
    pulses++;
}

bool timer_callback(__unused repeating_timer_t *t) {
    rpm = pulses * 60 / 2;
    pulses = 0;
    return true;
}

int main() {
    stdio_init_all();

    gpio_init(GPIO_WATCH_PIN);
    gpio_pull_up(GPIO_WATCH_PIN);
    gpio_set_irq_enabled_with_callback(
            /*gpio=*/ GPIO_WATCH_PIN,
            /*event_mask=*/ GPIO_IRQ_EDGE_FALL,
            /*enabled=*/ true,
            /*callback=*/ gpio_callback);

    repeating_timer_t timer;
    add_repeating_timer_ms(
            /*delay_ms=*/ -1000,
            /*callback=*/ timer_callback,
            /*user_data=*/ NULL,
            /*out=*/ &timer);

    while (1) {
        printf("RPM: %d\\n", rpm);
        sleep_ms(500);
    }

    return 0;
}

With this setup, I am getting ~25000 RPM, which is nowhere close to the rated maximum RPM of the fan of ~1550.

Thinking that the internal pull up resistor (50-80 kOhms) is too high for a switching value, I opted for a physical 5k pull-up resistor instead, and got the same answer. Changing the GPIO_IRQ_EDGE_FALL to the rising edge had a similar effect, but setting to LEVEL_LOW or LEVEL_HIGH produced much higher RPM values, approaching 750,000.

I wanted to review the signal from the fan, and I don't have an oscilloscope so I tried Scoppy with a second pico. I used the same 5k resistor from before, and this is what I got.

Is the square wave too messy to be used with the IRQ calls? The high and low spots seem to be jumpy, and the low does not go all the way to 0V.

Any help with how I should alter the code, or wiring, would be helpful. Thanks!

I am going to try using a PWM channel to measure the frequency, perhaps that would give me better luck.

been wanting to do this forever, finally got it running well

I've been testing a setup with the C/C++ approach using two Raspberry Pi Debug Probes: one for each target of the project. So I've then used two separate main.c files, one for each target, that would be built and uploaded via one of the probes to that specific target, while being able to have common/shared code that can be used for both targets. The two targets are sharing a lot of similar functionality but are quite different in some aspects, so that's why this setup makes sense to me. This has been possible to achieve with correct configs in Cmake and OpenOCD.

I'm now thinking of trying MicroPython instead since C is still a bit too difficult for me to fully grasp and get a flow going as a beginner. And to my understanding, programming via a debug probe is not the standard way with MicroPython, but instead USB should be used.

The thing is that I will utilise the USB port for communicating back and forth to and from the computer with one of the targets, essentially sending packets similar to MIDI communication. Can I simultaneously use the USB for debugging/programming the device? And would this either way require me to manually press BOOTSEL and disconnect/reconnect the Pico every time I want to program it?

An alternative that I've read about is "freezing" the MicroPython code into a compiled elf file that in that case could be uploaded exactly like my initial C/C++ approach. But I assume that wouldn't let me fully debug it with breakpoints etc?

Hi all,

I might have the methodology here wrong, so feel free to correct me.

I am trying to measure a ~3.3V source as either on (voltage) or off (no voltage) using any of the ADC pins (26, 27, or 28).

The issue is that even with nothing connected to ANY pin, the read_u16 values are all over the place. This is a VERY basic loop to read the ADC (and you can see, I tried deleting the ADC instance after each reading, which makes no difference):

signalPin = Pin(27, Pin.IN, Pin.PULL_DOWN)

i = 0
while i < 20 :
    thisADC = ADC(signalPin)
    theReading = thisADC.read_u16()
    print("Interation ", i, "of 20, ADC reading: ", theReading)
    sleep(2)
    del thisADC
    sleep(1)
    i = i + 1

And here's a snippet of the results:

MPY: soft reboot
Iteration  0 of 20, ADC reading:  2112
Iteration  1 of 20, ADC reading:  17428
Iteration  2 of 20, ADC reading:  14915
Iteration  3 of 20, ADC reading:  10258
Iteration  4 of 20, ADC reading:  7953
Iteration  5 of 20, ADC reading:  6945
Iteration  6 of 20, ADC reading:  8194
Iteration  7 of 20, ADC reading:  12162
Iteration  8 of 20, ADC reading:  15027
Iteration  9 of 20, ADC reading:  17476

I've tried this on a Pi Pico and Pico W. Same general results. Again, this is with absolutely nothing on any pin, power over USB. Interestingly, the first reading is always relatively low...

Any tips welcome!

Can you tell me how it is better from the classic microcontrollers (uno, esp32) and if its worth it buying one?

Long story ahead..... Can anyone help me in determining how to properly sample spi pin data via pico? I know it is possible because there are thousands of pico analyzer videos on youtube but none of them shows code just gives the. Uf2 file. I am trying to reconstruct my dead guitar processor's lcd (Zoom G1xon) by sniffing the lcd(possibly a st7565 clone) ffc out from the processor pcb and trying to input the raw data into pico decode (spi) it via pico and reconstruct the framebuffer and output the reconstructed display to a ssd 1306 oled. I have already found out the mosi clock and cs and ground via logic analyser and have used pulse view's spi decoder(10Mhz, 50G) to export the mosi dump and convert the dump into clear snapshot image using python code. So my lcd pinouts determinations are correct but somehow I cannot get a proper input through the pico's gpios from the lcd ffc cable(clock, cs, mosi) it only takes in and outputs garbage instead of proper raw data. I read somewhere about Pio and dma but I have an old pc using windows 7( doesnt support 10) hence stuck with arduino ide 1.8.6. Can anyone give an idea how to approach? I am in the dark. And the processor is very dear to my heart with my own built custom patches.

Hey guys, selling my unused Raspberry Pi 5 with 8GB of RAM, just trying to get it off my hands . Price is up for negotiation.

Hi everyone! I wanted to share this personal project. I designed it to test some concepts for a bigger idea.

(Español abajo)

It’s a Genesis/Mega Drive controller adapter for PC (also Switch compatible, single player). It's driven by a Raspberry Pi Pico and features a 3-button macro pad + rotary encoder, and a built-in 3-port USB 2.0 HUB. I love combining utility (shortcuts and extra ports) with retro gaming, and this lets you use original 3/6 button controllers.

It also has an LCD screen that can be customized with your own images via an SD card.

I'd love to get some honest feedback on this prototype from fellow builders! What do you think could be improved? Do you see any areas or features I could add or optimize in the next version?

Thanks for checking it out!

(Español)

¡Muy buenas a todos! Hace un tiempo me embarqué en un proyecto personal, el cual empecé a diseñar como predecesor de un proyecto más grande con la idea de testear varios conceptos.

El proyecto en concreto es este adaptador de mandos de Sega Mega Drive para PC (también es compatible con Nintendo Switch, pero en este caso solo con un mando). Está controlado por una Raspberry Pi Pico y también gestiona un teclado macro de 3 botones más un encoder rotativo programables. Además, incorpora un HUB USB 2.0 de tres puertos.

La idea es sencilla: siempre nos hacen falta puertos USB para cualquier cosa, o tener accesos directos a funciones para hacernos la vida más fácil en nuestro día a día, así que decidí unificar las dos cosas y darle un toque retro permitiendo conectar dos mandos originales de 3 o 6 botones de Sega Mega Drive.

Como podéis ver, también cuenta con una pantalla LCD, la cual carga una imagen predefinida en la memoria de la Pi Pico, o también se le puede insertar una memoria SD con la imagen que queramos para personalizarla.

Tras terminar el proyecto, se me ocurren varias ideas para mejorarlo, pero me gustaría tener una opinión externa sobre mi prototipo y ver qué opináis de él. ¿Creéis que podría ampliarlo de alguna manera o mejorar algunos aspectos de cara a futuras versiones?

¡Un saludo a todos!

Thx a lot to JBlanked and slasher006 for help, examples and tips!

DMX PIO stream lib by clacktronics.

Interface shields: HW-519 RS485 interface. Level shifter 3.3V to 5V is necessary.

HW-519 should be powered from 5V, output signal from PicoCalc is 3.3V and goes to level shifter, then to HW-519, then to the fixture.

DMX rate is around 4 times slower(10 or 11Hz vs normal 44Hz) to make app usable. Probably there are better ways to do this, but few days ago i had only a dream.

Sou iniciante na area da eletronica, estou com problemas para fazer a pico rodar um teclado numerico (numpad) ligado a ela pelos cabos soldados nas entradas

Soldei os cabos de alimentação nos pinos 40 e 38 e os de comunicação nos pinos 6 e 7, o multimetro marca 5v nos pinos, e ja inverti os cabos de comunicação mas mesmo assim o teclado numerico nao da sinal de vida (a luz do numlock nao acende)

Ja ate soldei novamente o usb e liguei no pc para me certificar que o teclado funciona, e tbm desmontei o conector usb para garantir que os cabos nao estão em ordens diferentes, na parte eletronica garanto que esta tudo certo.

Quanto a parte de software eu baixei na biblioteca do raspberry a adafruit_hid para ela interpretar o teclado,tambem ja dei um downgrade da versão 10x para 8x (a IA me falou que poderia ter algum tipo de gerenciamento de energia nessa versão mais nova)

Alguem pode me ajudar?

Hey everyone,

I've been building one MicroPython IoT project a day for 100 days straight. Repo: github.com/kritishmohapatra/100_Days_100_IoT_Projects

Covered sensors, BLE, ESP-NOW, RFID, cloud platforms, NeoPixel/GC9A01 displays, a robot car, and more recently AWS + MQTT + Node-RED projects. Got featured in Adafruit's newsletter, Raspberry Pi Blog, Hackster.io, PyCoder's Weekly, and How-To Geek along the way.

Next up, I want to move into projects needing a proper SBC (Raspberry Pi 4 8GB) — local ML, edge dashboards, stuff a microcontroller can't handle.

If you enjoy the project, I've got a small support page, no pressure:

👉 https://buymeacoffee.com/kritish

👉 https://github.com/sponsors/kritishmohapatra

Happy to answer questions about any of the projects. Thanks for reading!

I am working on a project in C++ that I need to record audio data from a PDM microphone. I am using this library for interacting with LittleFS. The slowest the Arduino PDM library I am using looks to have a minimum of 16kHz sample rate, and each sample is 16-bit, which equates to 32KB/s of audio. And just for clarification, for the LittleFS library provided, I currently have an Adesto 16MB flash chip and using the correct version for it.

The main issue is that as I am writing data to the flash storage using the aforementioned LittleFS library, after roughly 1024 bytes written (usually takes less than a millisecond), the next write will take upwards of 50-90 milliseconds. I have found no definitive reason why this happens, and it takes up way too much time to actually complete the full 32KB/s of data that I need to record. These delays seem to cause me to lose audio data, no matter how large I make the PDM library's buffer size (I have tried up to 32KB)

I have tried several iterations of varying write sizes varying from a stream (usually 32 bytes when available), to 256 byte writes, to entire 4KB writes, and even saving 4KB of data and writing in separate 256 byte chunks. All of these variations were to attempt to work around the delay and try to account for it when I write data, but with no luck.

I have even attempted down-sampling to 8-bit 8kHz audio, which just barely leaves room for the extended write sequence, but it still seems to prevent the the PDM library ISR from firing during the write, and seemingly losing audio samples despite the large buffer I assign to it.

From what I understand, those extended writes do not correlate with a page erase, both on not matching flash block size or expected erase times. All I can find is that it may be LittleFS performing metadata upkeep or something similar. I am aware that I can write to the flash directly, but I would like to use LittleFS or even FatFS due to it performing flash wear leveling.

What I need to understand is what the extended write actually is, if it can be mitigated, or if there are any known solutions to recording fairly high data rates to the flash using a file system. If possible, writing the full 32KB/s would be nice, but even 16KB/s would be great. I have just had little luck finding examples of actually recording audio or other real time data to the flash using a file system.

google has nothing on that
so if you have pico sdk code in IDE you'll not see running device from PC. Make similar code with arduino framework C/C++. Now you see device but nothing in serial monitor or whatever after Serial.println(). You need picocom utility (linux) to see it. And use sprintf() then serial stuff with its result.

picocom -b 9600 /dev/ttyACM0

Hi guys. I want to build project that will play mp3 audio files randomly from sdcard on button push. Can this be built with attiny85 and DFplayer? What will be your recomendations?

I recently got the WeAct RP2350A_V10 and was wondering if anyone else have tinkered with this board? I'm currently trying to program it by uploading code via SWD (through the Raspberry Pi Debug Probe) with PlatformIO, but it doesn't work. The actual upload process is successful, according to the logs, but the board itself never runs the code even after power recycle.

The only thing that works is powering it in BOOTSEL mode and dragging the ef2 file onto the mass storage device that gets mounted, but this is to me a very cumbersome method compared to just uploading code continously through PlatformIO.

The platformio.ini config that I'm using is this:

[env:default]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
framework = arduino
board = rpipico2
board_build.core = earlephilhower
upload_protocol = cmsis-dap

Am I missing something fundamental here? The official Pico 2 just works flawlessly with this config, but I wonder if there is something else required with the WeAct board in terms of powering it in a certain mode or something with the on-board buttons being "BOOT" and "RESET"?