Recent

Author Topic: using the raspberry pico to drive the electronics for a parcel delivery vault.  (Read 5193 times)

MiR

  • Sr. Member
  • ****
  • Posts: 274
The board is something different, it has an rp2040 and for wifi one can use the extra esp32-c3 soldered on the board.

Both devices talk to each other over a serial port.
From my point of view a much leaner solution than the rp2040w which imho adds a lot of bloat and complexity to the rp2040 code

MiR

Thaddy

  • Hero Member
  • *****
  • Posts: 16182
  • Censorship about opinions does not belong here.
And it has party tricks: either device can be master or slave depending on your mood of plugging in the usb-c powersupply..
I have my red and green markers out of the cupboard to make me remember how to plug in.
Will keep you posted about the project.
If I smell bad code it usually is bad code and that includes my own code.

avra

  • Hero Member
  • *****
  • Posts: 2532
    • Additional info
MCU can drive only a very limited current on it's pins, and without care you can easily hear a bang or smell a smoke  ;D. You need a driver circuit for high current actuators like solenoids, motors... And driver needs to match an actuator. Also some drivers require 5V logic while most MCUs provide 3.3V. Some MCUs are 5V tolerant on inputs (all inputs can be burnt if not protected properly), but need voltage level convertor to output 5V. You can find lots of drivers on Ali and eBay, and easiest way is to search for <arduino your-actuator-name driver>. However, you can be sure that it will work with your MCU only after reading datasheets of your actuator and driver (or driver chip) and looking at manufacturer's schematics if available. For a newbie, I would recommend searching the net for some example with schematics exactly for your specific MCU, if possible using some ready to use driver from Ali/eBay, and then purchase exactly that driver model. If you just want mailbox notification, you might use Home Assistant with some RF or WiFi integration (ESP32 I/O is best supported but there are other options). There you use MCU's as a dummy plug-and-play I/O and then do all the logic on pc in your favorite programming language. To do almost the same but without Home Assistant, you can use Firmata firmware for your MCU and then communicate with pc using some pc firmata lib. If I had to choose, I would use ESP32 MQTT server if I have 24/7 power available in mailbox, or ESP32 MQTT client that sleeps and just wakes on event and sends data to local Pi MQTT server if I have to power from a battery. Also, if you want your device to run reliably 24/7, you have to run a watchdog and implement a brownout detection.

https://learn.adafruit.com/use-dc-stepper-servo-motor-solenoid-rp2040-pico/solenoids
https://duckduckgo.com/?q=mailbox+detector+home+assistant&ia=web
https://duckduckgo.com/?q=mailbox+detector+arduino&ia=web
« Last Edit: June 07, 2024, 04:23:59 pm by avra »
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

MarkMLl

  • Hero Member
  • *****
  • Posts: 8030
The board is something different, it has an rp2040 and for wifi one can use the extra esp32-c3 soldered on the board.

Both devices talk to each other over a serial port.
From my point of view a much leaner solution than the rp2040w which imho adds a lot of bloat and complexity to the rp2040 code

MiR

Also leaves the flashable LED on the expected pin. I've got an RP2040W but haven't invested time into it.

When I was sniffing around in the region of Pico + Fuzix + 8266, the potential choices appeared to be /either/ an AT-style interface /or/ Packet Driver... with lots of people leaning towards Packet Driver as an antiquated- if not venerable- standard but not a great deal being done with it.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 8030
Also leaves the flashable LED on the expected pin. I've got an RP2040W but haven't invested time into it.

When I was sniffing around in the region of Pico + Fuzix + 8266, the potential choices appeared to be /either/ an AT-style interface /or/ Packet Driver... with lots of people leaning towards Packet Driver as an antiquated- if not venerable- standard but not a great deal being done with it.

Just a note to say that I've picked one of these up but haven't invested any time into it yet.

As an overview, it appears to be shipped with either minimal or no code on both chips, i.e. it might flash an LED but there is no comms stuff (unlike the way that most 8266s are shipped, i.e. with a minimal AT command set).

https://spotpear.com/index/study/detail/id/1101.html appears relevant.

Ultimately, I'd like to compare FUZIX on both that and the original Pico project board I've got, and to look at whether it would be possible to put something like a Packet Driver on the ESP32 that an OS might like to use without significant main-chip effort.

This https://hackaday.com/2024/05/14/breadboardos-a-command-line-interface-for-the-pico/ looks interesting for the Pico: extends FreeRTOS with a minimal shell etc.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Hmm, I have lost track of this thread.  Due the the extra complexity (that Michael mentions) with the 2040W, I got my project operational using C code on the 2040w. You are (or I was) locked into using the whole C stack and even their tool to make a cmake config. And that cmake config is critical. Honestly, worrying for me, I was left feeling I had very little control in the process.

https://github.com/davidbannon/SolarHotWater

Davo
Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 8030
Hmm, I have lost track of this thread.  Due the the extra complexity (that Michael mentions) with the 2040W, I got my project operational using C code on the 2040w. You are (or I was) locked into using the whole C stack and even their tool to make a cmake config. And that cmake config is critical. Honestly, worrying for me, I was left feeling I had very little control in the process.

Yes, I think I remarked when it came out that the -W looked like being a problem because- apart from anything else- the LED had been moved onto the WiFi chip. From our POV, the SpotPear board looks like a better bet.

However the fact remains that we are very much in the minority, and there are probably more people entirely happy with the innards of cmake than are prepared to consider FPC etc. as a viable tool for working with the Pico. I fall in between those camps: I'm uncomfortable- due to lack of familiarity- with cmake, but would be even less comfortable trying to discuss the RP2040 architecture with hardcore developers unless using the tools they were familiar with... which regrettably revolve around cmake since the other documented contenders quite simply don't appear to be up to it.

As an update, I'd like to make it clear that I very much liked the ease of development that Lazarus+FPC offered on the Pico: my notes show that with a bit of fiddling I was able to get OpenOCD etc. working in the context of a Docker container which offered a very comfortable development/upload/debugging experience. I just feel that it would be a very hard sell to the bulk of the Pico/RP2040 community.

MarkMLl
« Last Edit: August 06, 2024, 04:21:40 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dbannon

  • Hero Member
  • *****
  • Posts: 3156
    • tomboy-ng, a rewrite of the classic Tomboy
Personally, I believe that cmake should be a useful tool in the Obfuscated C Code Contest.

The problem is, we have had a couple of very talented people making FPC work with these devices as they come out. But they are appearing too fast.  I saw great opportunities to use a esp32, purchased a couple of esp32c3 only to find that they use a different instruction set (RISC). A whole lot of work ensure but I lost track of where they were up to due to some health issues.

I'd love to use Pascal for these projects, I enjoy using Pascal and consider myself moderately competent. My C is very rusty and C++ almost no existing. And the old adage applies, if it compiles with Pascal, it will probably work ! 

Sigh ....

Davo

Lazarus 3, Linux (and reluctantly Win10/11, OSX Monterey)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

MarkMLl

  • Hero Member
  • *****
  • Posts: 8030
Personally, I believe that cmake should be a useful tool in the Obfuscated C Code Contest.

The problem is, we have had a couple of very talented people making FPC work with these devices as they come out. But they are appearing too fast.  I saw great opportunities to use a esp32, purchased a couple of esp32c3 only to find that they use a different instruction set (RISC). A whole lot of work ensure but I lost track of where they were up to due to some health issues.

Yes, I agree and sympathise respectively.

cmake increases the complexity substantially: even when compared with the Arduino build environment. And I consider the -W obfuscation somewhat of a home goal: not being able to inspect and understand exactly what happens when the LED is flashed is a serious flaw.

Apart from the price, the major thing that the RP2040/Pico has is the PIO devices. But somebody's already reverse-engineered those to Verilog, and once you're at that stage the next obvious question is how easy it would be to systematically convert an I/O device specification (e.g. for a special purpose serialiser etc.) to Verilog which some back-of-an-envelope sums suggest would save an order of magnitude of gates. At that point what we need is for somebody- almost certainly in China- to bring out a cheap "stick of gum" board with a RISC-V and a small FPGA.

I've played with the Sipeed Tang Nano FPGA and been impressed: the tools did require registration (hence at some point might be revoked) but you got both Verilog and VHDL and with a little bit of digging can work out how the special-block functionalities are being defined https://github.com/MarkMLl/tang_nano_as_shipped All in all, an enjoyable experience (and no cmake stuff).

I've played with some of the cheap WCH RISC-V boards which are broadly Arduino- or Pico-class and been impressed. What's more the manufacturer actually responded to tech questions, has made the debugging stream format public, and generally appears to care about "engaging with the community". It was Eclipse-based, but was by far the best Eclipse bundle I've come across.

Most recently, I've been playing with a Milk-V Duo: two RISC-V cores (one Linux, one Arduino-class) plus an 8051 controlling a watchdog etc., plus extra stuff for image classification that I've not played with. I'm not saying it was 100% troublefree, but the level of pain was bearable.

Having onboard WiFi is a big thing. But so it good documentation and an overall "open" design philosophy, and while it is obvious that a substantial proportion of the community is happy with cmake one has to ask how many of those are actually building up projects from scratch rather than copying of slightly-modifying existing work.

MarkMLl

p.s. Working notes available on any of the devices I've mentioned above, although the only one that I've used with FPC yet is the Pico.
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

MarkMLl

  • Hero Member
  • *****
  • Posts: 8030
I've played with some of the cheap WCH RISC-V boards which are broadly Arduino- or Pico-class and been impressed. What's more the manufacturer actually responded to tech questions, has made the debugging stream format public, and generally appears to care about "engaging with the community". It was Eclipse-based, but was by far the best Eclipse bundle I've come across.

Most recently, I've been playing with a Milk-V Duo: two RISC-V cores (one Linux, one Arduino-class) plus an 8051 controlling a watchdog etc., plus extra stuff for image classification that I've not played with. I'm not saying it was 100% troublefree, but the level of pain was bearable.

Geoff Geerling at https://www.youtube.com/watch?v=oXF_lVwA8A4 reports that there is a new Pico2 using an RP2050 chip which can be switched between 2x ARM or 2x RISC-V cores, plus 3x PIOs. Other details scarce so far.

I will definitely not be putting time into this in the short term, since I want to continue exercising the Milk-V and RP2040+ESP32 boards, but I consider one significant question to be what happens to the debug pins: do they always use the same "PicoProbe" protocol, or do they switch between ARM and RISC-V modes?

MarkMLl
« Last Edit: August 08, 2024, 08:28:57 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories


MarkMLl

  • Hero Member
  • *****
  • Posts: 8030
Yes, but to put things into context: a former employer had 8051-based telemetry hung off a POTS 'phone line (and fully approved). My recollection is that he claimed to have got the quiescent draw down to 20 nA, which is impressive even when one considers that it was Frankensteined into life by an incoming ring and had no timer- or event-controlled outgoing call capability.

Good old 1980s technology.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018