Stories
Slash Boxes
Comments

SoylentNews is people

Raspberry Pi Releases "Pico" Microcontroller at $4 Per Unit

posted by Fnord666 on Friday January 22 2021, @12:31AM   Printer-friendly

canopic jug writes:

The Raspberry Pi Foundation's first microcontroller, the Raspberry Pi Pico is now on sale at $4. Raspberry Pi is normally associated with single board microcomputers. This microcontroller uses the RP2040 dual-core ARM Cortex-M0+ chip. The board has support for C, C++, and microPython.

We had three principal design goals for RP2040: high performance, particularly for integer workloads; flexible I/O, to allow us to talk to almost any external device; and of course, low cost, to eliminate barriers to entry. We ended up with an incredibly powerful little chip, cramming all this into a 7 × 7 mm QFN-56 package containing just two square millimetres of 40 nm silicon. RP2040 has:

  • Dual-core Arm Cortex-M0+ @ 133MHz
  • 264KB (remember kilobytes?[*]) of on-chip RAM
  • Support for up to 16MB of off-chip Flash memory via dedicated QSPI bus
  • DMA controller
  • Interpolator and integer divider peripherals
  • 30 GPIO pins, 4 of which can be used as analogue inputs
  • 2 × UARTs, 2 × SPI controllers, and 2 × I2C controllers
  • 16 × PWM channels
  • 1 × USB 1.1 controller and PHY, with host and device support
  • 8 × Raspberry Pi Programmable I/O (PIO) state machines
  • USB mass-storage boot mode with UF2 support, for drag-and-drop programming

And this isn't just a powerful chip: it's designed to help you bring every last drop of that power to bear. With six independent banks of RAM, and a fully connected switch at the heart of its bus fabric, you can easily arrange for the cores and DMA engines to run in parallel without contention.

[*] By comparison, the Apple II computer (introduced in June 1977) had: 4-48 KiB of RAM, a 6502 processor (running at 1 MHz), and an Introductory price of US$1,298 (equivalent to $5,476 in 2019).

Additional coverage:

Original Submission

 
This discussion has been archived. No new comments can be posted.
Raspberry Pi Releases "Pico" Microcontroller at $4 Per Unit | Log In/Create an Account | Top | 31 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 2) by VLM on Saturday January 23 2021, @04:55PM (1 child)

    by VLM (445) on Saturday January 23 2021, @04:55PM (#1104204)

    Not disagreeing with anything, but single threaded apps have it easy, the real killer is when you got multiple thread RTOS and each thread gets spawned off with a dedicated statically defined stack.

    So on a single thread app with one big shared stack things can get kinda sloshy and its OK if you can't do TCPIP stuff AND framebuffer graphics AND processing because being single threaded you can't do them all at the same time anyway... Multithreaded HURTS without enough memory.

    My favorite thing is how some RTOS like ARM Mbed OS just go insane if you overflow the stack. Hilarious! Or sometimes they crash. It can be a mess.

    I like using multithreaded RTOS to do stuff like decouple the scheduling of my IO, GUI, and processing, compared to doing in arduino-style in one big loop, but there is a memory cost...

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  
    Total Score:   2  

  • (Score: 3, Interesting) by JoeMerchant on Saturday January 23 2021, @05:04PM

    by JoeMerchant (3937) on Saturday January 23 2021, @05:04PM (#1104208)

    I have found that multithreaded RTOS work pretty well, as long as you are seriously underutilizing the capacity of the system, like 50% or less. When things get tight, prioritized interrupts and all the rest frequently throw hard to debug unpredictable behaviors into the mix and people really have a hard time setting them right.

    When possible and it's not always possible with things like TCPIP and framebuffer and others happening simultaneously, but when possible I like to define a single monotonic timed interrupt for the system, like once per 500uS or whatever, and then run a deterministic choreographed script of what happens on each phase of that interrupt, so maybe do 40 cycles with 20 of them servicing things that need to happen every 1mS, 10 more things that need to happen every 2mS, then the remaining 10 can service things that need to happen within 20ms... put an "in interrupt service" signal on a GPIO line and watch it on a scope, or if you can dump the assembly and ensure that your code WILL finish within the allotted 500uS. Now, anything else that needs doing but isn't time critical can get serviced in the "main loop" that runs whenever the time critical stuff isn't happening. I've made several systems that way and they never had the "jeez, it only happens once every 6 weeks or so, but it's really weird I can't explain it" bugs.

    --
    Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end