Rasberry pi pico

[dbanner]

Looks to be quite powerful little device. Superior to any Arduino.

[Mattnz]

Superior to any hobby micro controller - the new 16f877a

[Vadim18]

Looks to be quite powerful little device. Superior to any Arduino.

Yes, indeed powerful. I bouth one, about half of mounth ago, cost me around 8$. Main advantage is Python for any prototyping, also no need to flash firmware, no need to cycle onboard flash - just load python script with Tonny directly in to the RAM and thats all.
PIO is the most useful thing in that Pico, but not well documented yet or i am lazy searcher
So if anybody have already tasted PIO module, let's talk about PIO.

[Vadim18]

Some ugly and fast adaptation from existed example to generate Pi TX (not tested)

import rp2
from machine import Pin

@rp2.asm_pio(set_init=rp2.PIO.OUT_LOW)
def blink():
wrap_target()
set(pins, 1) [31] #Set TX at pin 25 "Hi" #That [31] is number of cycles (max - 31) to wait, speed of cycle defined in SM by "freq" parameter?
nop() [31] #Do nothing 31 cycle
set(pins, 0) [31] #Set TX at pin 25 "Low"
nop() [31] #Do nothing 31 cycle
nop() [31]
nop() [31]
nop() [31]
wrap()

sm = rp2.StateMachine(0, blink, freq=1000, set_base=Pin(25)) # Creating so called State Machine. "freq" can be changed to "period"
sm.active(1) # enable state machine
#sm.active(0) # disable state machine

[lucifer]

Sure you can use Raspberry to build a detector. It's good to see Pico has a 12-bit onboard ADC. But the SMPS will cause lot's of problems. See extract from datasheet:



It's a powerful device but the question is what would you do with that power? How will it make the detection better compared to any microcontroller?

[Qiaozhi]

Some ugly and fast adaptation from existed example to generate Pi TX (not tested)

import rp2
from machine import Pin

@rp2.asm_pio(set_init=rp2.PIO.OUT_LOW)
def blink():
wrap_target()
set(pins, 1) [31] #Set TX at pin 25 "Hi" #That [31] is number of cycles (max - 31) to wait, speed of cycle defined in SM by "freq" parameter?
nop() [31] #Do nothing 31 cycle
set(pins, 0) [31] #Set TX at pin 25 "Low"
nop() [31] #Do nothing 31 cycle
nop() [31]
nop() [31]
nop() [31]
wrap()

sm = rp2.StateMachine(0, blink, freq=1000, set_base=Pin(25)) # Creating so called State Machine. "freq" can be changed to "period"
sm.active(1) # enable state machine
#sm.active(0) # disable state machine

What I would like to see is someone code the PI pulse sequence using interrupts and the internal timer. It's fairly obvious that you can generate these pulses using a straightforward linear sequence, but this is very restrictive if you want the detector to perform other duties.

Since the Raspberry Pi Pico is such a new device, there is very little information available. The Official Raspberry Pi Pico Guide (MicroPython on Raspberry Pi Pico) seems to be aimed at children, as it's very cartoon-like and spends a lot of time on extremely basic stuff, such as how not to burn yourself with a soldering iron. In a similar way to the Hackspace magazines, it lacks any useful content. Often you start reading a section that shows some promise, and then it abruptly ends at the most interesting point.

I haven't delved into the RPI Pico in any real detail yet, but I suspect that sub-microsecond timing is going to be a big issue when using MicroPython. C/C++ is supposed to be supported, but (again) there is very little information available. I've heard that the Arduino development team are planning to support the RP2040 in their own hardware with programming via the Arduino IDE, so it may be worth waiting around for that to happen.

[Vadim18]

Yes, Qiaozhi, In many aspects i agree with you. Main auditory for RPI are kids, students and electronic entusiasts. Not oriented for commercial purpose. And because the RPI of a new product is not yet well documented, coding experiments and time are needed.
Thanks for your information lucifer, i have not tried ADC in action. I think for non direct sampling will suit fine.
This is my enclousure for RPI

[Teleno]

What I would like to see is someone code the PI pulse sequence using interrupts and the internal timer. It's fairly obvious that you can generate these pulses using a straightforward linear sequence, but this is very restrictive if you want the detector to perform other duties.

Since the Raspberry Pi Pico is such a new device, there is very little information available. The Official Raspberry Pi Pico Guide (MicroPython on Raspberry Pi Pico) seems to be aimed at children, as it's very cartoon-like and spends a lot of time on extremely basic stuff, such as how not to burn yourself with a soldering iron. In a similar way to the Hackspace magazines, it lacks any useful content. Often you start reading a section that shows some promise, and then it abruptly ends at the most interesting point.

I haven't delved into the RPI Pico in any real detail yet, but I suspect that sub-microsecond timing is going to be a big issue when using MicroPython. C/C++ is supposed to be supported, but (again) there is very little information available. I've heard that the Arduino development team are planning to support the RP2040 in their own hardware with programming via the Arduino IDE, so it may be worth waiting around for that to happen.

There seems to be a good C/C++ API, take a look here https://datasheets.raspberrypi.org/p...pico-c-sdk.pdf

[Qiaozhi]

There seems to be a good C/C++ API, take a look here https://datasheets.raspberrypi.org/p...pico-c-sdk.pdf

From the C/C++ SDK:
************************************************** **************
4.1.22. hardware_timer
Low-level hardware timer API.
This API provides medium level access to the timer HW. See also pico_time which provides higher levels functionality
using the hardware timer.
The timer peripheral on RP2040 supports the following features:
• single 64-bit counter, incrementing once per microsecond
• Latching two-stage read of counter, for race-free read over 32 bit bus
• Four alarms: match on the lower 32 bits of counter, IRQ on match.
By default the timer uses a one microsecond reference that is generated in the Watchdog (see Section 4.8.2) which is
derived from the clk_ref.
The timer has 4 alarms, and can output a separate interrupt for each alarm. The alarms match on the lower 32 bits of
the 64 bit counter which means they can be fired a maximum of 2^32 microseconds into the future. This is equivalent
to:
• 2^32 ? 10^6: ~4295 seconds
• 4295 ? 60: ~72 minutes
The timer is expected to be used for short sleeps, if you want a longer alarm see the hardware_rtc functions.
************************************************** **************

It appears that the internal hardware timer increments every microsecond, which doesn't look promising.

[Teleno]

From the C/C++ SDK:
************************************************** **************
4.1.22. hardware_timer
Low-level hardware timer API.
This API provides medium level access to the timer HW. See also pico_time which provides higher levels functionality
using the hardware timer.
The timer peripheral on RP2040 supports the following features:
? single 64-bit counter, incrementing once per microsecond
? Latching two-stage read of counter, for race-free read over 32 bit bus
? Four alarms: match on the lower 32 bits of counter, IRQ on match.
By default the timer uses a one microsecond reference that is generated in the Watchdog (see Section 4.8.2) which is
derived from the clk_ref.
The timer has 4 alarms, and can output a separate interrupt for each alarm. The alarms match on the lower 32 bits of
the 64 bit counter which means they can be fired a maximum of 2^32 microseconds into the future. This is equivalent
to:
? 2^32 ? 10^6: ~4295 seconds
? 4295 ? 60: ~72 minutes
The timer is expected to be used for short sleeps, if you want a longer alarm see the hardware_rtc functions.
************************************************** **************

It appears that the internal hardware timer increments every microsecond, which doesn't look promising.

That's the system tick timer. You have to look at the PWM slices, each with its own 16 bit timer/counter at full speed.

4.1.17. hardware_pwm

This datasheet explains these timers/counters https://datasheets.raspberrypi.org/r...-datasheet.pdf

Each PWM slice is equipped with the following:
? 16-bit counter
? 8.4 fractional clock divider
? Two independent output channels, duty cycle from 0% to 100% inclusive
? Dual slope and trailing edge modulation
? Edge-sensitive input mode for frequency measurement
? Level-sensitive input mode for duty cycle measurement
? Configurable counter wrap value
◦ Wrap and level registers are double buffered and can be changed race-free while PWM is running
? Interrupt request and DMA request on counter wrap
? Phase can be precisely advanced or retarded while running (increments of one count)

Slices can be enabled or disabled simultaneously via a single, global control register. The slices then run in perfectlockstep, so that more complex power circuitry can be switched by the outputs of multiple slices.

[Qiaozhi]

That's the system tick timer. You have to look at the PWM slices, each with its own 16 bit timer/counter at full speed.

4.1.17. hardware_pwm

This datasheet explains these timers/counters https://datasheets.raspberrypi.org/r...-datasheet.pdf

Each PWM slice is equipped with the following:
? 16-bit counter
? 8.4 fractional clock divider
? Two independent output channels, duty cycle from 0% to 100% inclusive
? Dual slope and trailing edge modulation
? Edge-sensitive input mode for frequency measurement
? Level-sensitive input mode for duty cycle measurement
? Configurable counter wrap value
◦ Wrap and level registers are double buffered and can be changed race-free while PWM is running
? Interrupt request and DMA request on counter wrap
? Phase can be precisely advanced or retarded while running (increments of one count)

Slices can be enabled or disabled simultaneously via a single, global control register. The slices then run in perfectlockstep, so that more complex power circuitry can be switched by the outputs of multiple slices.

I see ... you have to use the PWM counters to generate an interrupt. This is quite different to a PIC processor, and why I was looking for the usual timer/counter registers.
The RPI Pico does appear to be a step up from a standard PIC or Arduino Nano, but not so intuitive to use.

[Teleno]

I see ... you have to use the PWM counters to generate an interrupt. This is quite different to a PIC processor, and why I was looking for the usual timer/counter registers.
The RPI Pico does appear to be a step up from a standard PIC or Arduino Nano, but not so intuitive to use.

Look at this example Atmega328P code I posted a while ago: https://www.geotech1.com/forums/show...400#post257400
It is possible to generate pulses without interrupts by configuring the PWM waveforms.

[Qiaozhi]

Look at this example Atmega328P code I posted a while ago: https://www.geotech1.com/forums/show...400#post257400
It is possible to generate pulses without interrupts by configuring the PWM waveforms.

Thanks for that. Very interesting.

This is obviously a way of generating shorter delays without the overhead of entering and exiting the interrupt routine.
I must study this more closely. Yet another item to add to my list of things to do.

[Vadim18]

I see another posible way to deal with submicroseconds delays
1. Use traditional PIC microcontroller to generate all TX Timings.
2. Use UART (i2c) protocol to setup timing scheme (2-4 chanel) and all delay values
3. Use RP Pico for hi level signall processing, user control, and other tasks with MicroPython
Thanks Teleno for pointing to PWM section!

[dbanner]

Hooray, hoorah. The pico is here to stay. I wonder if it's on the Mars copter. You'd need a Superfly for such a task, which the pico obviously is. A god dammed super little creature.
Micro Python I'm not inclined to get involved. It's rather too efficient for my mind. I'm a dummy.
Architecturely, it's quite advanced, obviously in the clandestine world of exploring the solar system in search for microbes, or so I've been told. Now it's been made available to the general public. Robotics, that's it's primary aim.
It's a wet dream for young enthusiasts.
Now raspebbery picos will soon be first responders, accompanying the police. They send in something resembling an apocalyptic dog, which is supposed to sniff out any hidden offenders. But the really crazy thing is that it's got a gun strapped to it's back, not remote, but AI in real time. I was killed by a pico. That's frightening.