The Raspberry Pi Pico is a handy little microcontroller that has become a widespread addition to many hackers’ workbench. The Pico W has a CYW4342W module (just like the Pi Zero W) to add WiFi capabilities and [Jeremy Bentham] ported his bare-metal WiFi driver to the Pico W.
The CYW43438 is an SDIO interface, so most of the code ported over from his Zerowi project, but there were a few notable tweaks along the way. Given that the Pi Pico SDK has the complete source code to drive the CYW43439 with an open source TCP/IP stack (lwIP) and the datasheets from Infineon are pretty detailed, why create your own driver?
The short answer is…because why not. But a second answer is to tweak it just how you like it. With his own implementation, [Jeremy] can focus on maximizing throughput and making WiFi a little easier to debug. He deeply delves into the hardware, scope traces, and code samples. It’s a tremendous five-part read over lunch. Some highlights include writing some code for the PIO (Programmable I/O) to interface with the SPI interface, bank switching in the WiFi RAM, handling the 140 different events, connecting to a network, and sending pings.
The PicoWi code is available on GitHub. Perhaps it can be integrated with this PCMIA interface to offer outstanding performance to an older laptop.
https://hackaday.com/2022/06/30/raspberry-pi-pico-w-adds-wireless/#div-comment-6488126 suggests a good reason for rolling your own — dodging the alleged lawyerbomb, since Jeremy’s code is MIT-licensed.
i use them non-commercially at home. which is covered by the regular firmware.
But does it support BT yet? To me that is the disappointment with the Pico W right now. Not enough for me not to want one to play with but still a downer. But I have the ESP32 in the meantime to keep me busy.
What would really be cool IMHO would be a PicoW SBC using RiscV with WiFi and BT.
Stop calling it a “microcontroller”…IT’S AN **ARM**!!
How about you stop confusing an instruction set with an MCU. A microcontroller contains one or more CPUs (processor cores) along with memory and programmable input/output peripherals.
Even the official foundation calls it an MCU, fully correctly.
Imbecilic pedant…IT’S AN **ARM**!!
Repeating it like it means something. LOL
Really? But they have so many legs?
It’s an arm-based MICROCONTROLLER.
And technically, it’s not an ARM, because NOTHING from the modern era is an ARM. ARM simply licenses intellectual property that others use to develop microprocessors or microcontrollers (usually the latter) to meet their own specific needs.
Eh, that too is imbecilic and pedantic. It’s actually a ***SEMICONDUCTOR***
:D
You are wasting bandwidth. When someone is that dumb and arrogant they are just trolling to troll or are a lost cause. Ignoring them is the best option and they will just give up in frustration which is really for the best.
Have a nice day.
So Hitomi what do you think ESP32 v Pico?
I would say whichever is available and cheap, unless your task requires a certain level of precision only an STM32 Arm Cortex M4, ARM Cortex M0+ or Extensa can offer.
I quite fancy and enjoy the Nucleo-32 STM32L432KC development board.
It damn well IS a microcontroller by definition.
I just with they’d stop calling it a “Raspberry Pi” when it literally has nothing in common with one aside from branding..
If it can execute code it’s a microprocessor not microcontroller. MCUs are by definition used to do one thing like operating a motor and do it well once designed into system.
Microprocessors are meant to run various run operating systems, games, display photos, play music etc. and this is what Pi Pico as well as its bigger cusin Pi 4 are used for.
Are you confusing the Pico with the Zero?
Wrong, since high level programming languages like python can run on a microcontroller with an interpreter since years by now: MicroPython – Python for microcontrollers, as they self describe.
Stop calling python a programming language… Ok it works great for use on a full computer, but using python on a microcontrolelr just isn’t appropriate. An interpreted language has opportunities for types of bugs which crash the whole program and which simply can’t occur in a compiled language, simple spelling mistakes in rarely entered loop branches for example. Python/micropython also has far too much overhead to be realtime fast, being realtime fast is the whole point of microcontrollers. I’ve taught students a project module with microbit microcontroller dev boards, they are SO GLAD when they realise they can load C code via an arduino IDE rather than bleep around with micropython crashes all day.
@Robort
Yet python is a high-level, general-purpose programming language. No matter your bruised ego only wanting to develop in your $otherLanguage.
I also love C, but you write a lot of words about some deep resentment you need to cope with. Python will remain a programming language no matter the tantrum you can create.
Wrong. As explained before, a microcontroller is a microprocessor with ram and programmable I/O on the same die.
Technically (there are overlapping definitions, so I can pick the one I think is most appropriate), most microcontrollers may contain microprocessors, althought they don’t have to.
The main difference seems to be that microcontrollers mostly expose peripherals and microprocessors expose address and data buses. Obviously something that is one thing on the outside can be made by wrapping the other thing in an appropriate adaptor layer.
It’s been a few years, but I’ve even worked with a small specialty microprocessor that turned out to be a die expansion of a chinese microcontroller; it simply created an external parallel address/data bus from a couple of internally serially-attached shift registers and a mux. And under the hood of that microcontroller core was itself a highly-bastardized 8051 core.
This is like pointing at an i7 and yelling “Stop calling it a CPU…IT’S AN x86-64!!”
CPLD can be made to emulate i7 in real time but you can’t emulate CPLD in real time on i7, it’ll always lag behind instruction cache.
How is that even relevant? Besides missing the point.
Coldfire is a microcontroller per NXP’s documentation, but it’s just a dolled-up 68k and could probably run some Amiga and early Mac programs with a little help.
PIC32M is a microcontroller by Microchip’s standards, but it’s MIPS inside, same as SGIs and two generations of Playstation.
microcontrole no have MMU and can run directly without any other controler to start.
The technical definition is a little different, mainly because the language is sloppy and many of the original considerations are now mostly obsolete.
An ideal example of the original context and definition of the term would be found by considering the Motorola 6800 (sixty-eight hundred, not its later bigger relative), and the MCS6801.
There’s nothing you can’t build with a 6801 that you couldn’t build with a 6800 and peripheral chips. It’s just that pins and board traces take up a lot of space when compared to just merging the silicon dies and exposing only the actually-needed lines to the outside world.
The “microprocessor” was a more general-purpose building-block. Given enough board area, you could wire up any number of peripherals, rams, roms, whatever it took to solve any arbitrarily complex problem.
But, if you could cram your problem within a subset of the possibilities (chosen because MANY problems only needed that subset), you could simplify everything by just using a microcontroller that simply merged the features you needed into a common die and deleted any pins that weren’t of interest to that common subset.
Later, of course, things got more complicated, and the terms got muddied to fit.
A microcontroller can have a MMU, and some do. It’s not at all uncommon for microcontrollers to expose some or all of their address/data bus, whereas the cost per pin on early ICs made many early microcontrollers avoid this.
A microprocessor can have built-in memory and peripherals, and most do.
To further muddy the water, most modern general-purpose desktop microprocessors power on in a mode where they’re using their onboard cache in write-back mode (but without any exernal ram to write back TO). As such, they can act as a microcontroller, at least for long enough to initialize the ram controllers and the rest of the chipset.This really simplifies the chipset and doesn’t add any complexity that wasn’t already required for the cpu cache.
In the most traditional sense, having a cache alone would be enough to move a chip from “microprocessor” to “microcontroller”. It’s a technically true but largely pointless distinction, these days.
Probably most relevant to the modern era:
* If it can’t be used standalone to get even basic work done, it’s definitely a microprocessor.
* If it can be used mostly standalone to get useful work done (and the work isn’t related to a general-purpose operating system), it’s a microcontroller.
* If it can be used mostly standalone to get useful work done (but the work IS related to general-purpose operating systems), it’s a system-on-chip.
Microcontroller and SoC are similar concepts, and simply cover different areas of interest and complexity.
CPU (ARM) + Peripherals + RAM + Program Code In A Single Chip = MCU
CPU (ARM) = ARM Processor
Nit-pick: “Perhaps it can be integrated with this PCMIA interface to offer outstanding performance to an older laptop.”
PCMIA > PCMCIA