I think Christo Crause has done some threads groundwork for freepascal on the esp32-freertos platform, theoretically freertos should run just fine on the board so what he did should also apply to the Pico.It (https://github.com/ccrause/fpc-esp-freertos/blob/master/freertos-fpc/fthreads.pp) is a proof of concept with some ESP specific bits, but that can be fixed. An alternative could be to use the pthreads (https://www.freertos.org/API/FreeRTOS_POSIX_pthread.html) library add-on which should be (more or less) compatible with FPC's cthreads wrapper unit.
There is a bare metal version of FreePascal for the Raspi: Ultibo.
Perhaps these sources could help develop a Pi Pico version of FreePascal
No. I tried to say that there is a version of FreePascal (Named Ultibo) that creates Bare Metal code for a Raspberry Pi.
Perhaps these sources could help develop a Pi Pico version of FreePascal
Ultibo is the version of FreePascal that create 'Bare Metal' code. Do you know what that is?
No. I tried to say that there is a version of FreePascal (Named Ultibo) that creates Bare Metal code for a Raspberry Pi.Ultibo is an operating system, not a compiler. Do you know the difference?
Perhaps these sources could help develop a Pi Pico version of FreePascal
MarkMLl
To quote the ultibo site ( http://www.ultibo.org ): [... snip ...]
What is Ultibo?
Ultibo core is an embedded or bare metal development environment for Raspberry Pi. It is not an operating system but provides many of the same services as an OS, things like memory management, networking, filesystems and threading plus much more. So you don’t have to start from scratch just to create your ideas.
So it's "kind of but not quite" an OS providing a minimum environment for application level development. Kind of like MS-DOS on steroids for RPi :D
The important point though is that Ultibo itself is not a compiler, and is of limited direct help when considering porting a compiler to a new target.
The important point though is that Ultibo itself is not a compiler, and is of limited direct help when considering porting a compiler to a new target.
One (maybe the only?) thing which might relate to that is their adaptation of the RTL. Other than that ... I can think of nothing; maybe they built Ultibo with FPC in mind, so it's better adapted to FP programming than other OS(-alikes) but whether that is germaine to the point ... I don't really know. I don't know that much about it. :-[
Has anybode else beside me already bought a pico?Not yet, I'm still trying to understand 8 bit AVRs. And ESPs. So much to learn, so little time :o
Has anybode else beside me already bought a pico?
Just found this interesting project on github:
https://github.com/majbthrd/pico-debug
looks like it is possible to debug one single raspi with itself.....
As a noob I ordered 1 pico only, so I'll buy the debugger soon.
In the YD-RP2040 board, the pin for connecting the reference voltage for the ADC is leaded out separately. It seems to me that the YD-RP2040 board is better designed than the original (ie RPi Pico) and the Waveshare clone. I do not see any advantages of the solution introduced by the RPi foundation regarding the ADC3 signal. It struck me as a quirk from the beginning.
Anyway, the actions of the RPi foundation are a mixture of good ideas about hardware solutions (e.g. RPi 1-4, RP2040 microcontroller) with stupid software ideas (OS for RPi based on Debian /root account locked in GUI/,
choice of Visual Studio Code and CMake for RPi Pico, Python). Python is not suitable for electronics applications (basic of automation). Yes, Python is popular. But with it it is like with the Trabant car in DDR - a lot of people used it because it was cheap. It was mass-produced, because it had a primitive design, which made it easy and cheap to produce.
I can see that the YD-RP2040 board differs from the original RPi Pico...I like all the changes they made 8-)
Anyway, the actions of the RPi foundation are a mixture of good ideas about hardware solutions (e.g. RPi 1-4, RP2040 microcontroller) with stupid software ideas (OS for RPi based on Debian /root account locked in GUI/, choice of Visual Studio Code and CMake for RPi Pico, Python). Python is not suitable for electronics applications (basic of automation).- I like Debian and Manjaro, so I am fine with their default choice. Who doesn't has plenty of options. Changing whole distro, or just a desktop environment is not hard.
VSCode has a Trojan that I'm still characterising, don't use.If you can live without some extensions, then maybe VScodium could be the solution:
It must be said that the SDK etc. is intended for the RP2040 rather than for the Pico. The real "gotcha" is that the crosspoint switching between peripherals and pins is subdivided, so UART0 can appear on only a small number of pins, UART1 on a different group and so on. That's not too bad, until you have something like the Cytron board that I've got which has put an ESP8266 on pins which can only be connected to UART0... meaning that any serial output that would normally be on UART0 has to be moved to either UART1 or USB.
I presume that you're talking there about the "classic" RPi plus Raspbian or whatever they call it these days: you /are/ aware aren't you that you can set up other named accounts? I'm not sure that's any worse than the Ubuntu philosophy where the standard is (or at least was) to have a root account which can't be logged into directly.
VSCode has a Trojan that I'm still characterising, don't use.
Python... I loathe the language, but the last few years have demonstrated that it's serviceable for tacking stuff together. If you have to criticise anybody, I suggest directing your ire at the people who think that a good way to design a user interface is to embed Javascript and a browser engine into a program.
- I like Debian and Manjaro, so I am fine with their default choice. Who doesn't has plenty of options. Changing whole distro, or just a desktop environment is not hard.
- I like VScode editor, debugging and extensions. Without VScode, I would be stuck with Arduino IDE or have to learn a new IDE for each target I need (and yes, I worked with Eclipse).
- Python is fine for many use cases, even in electronics (CircuitPython). It is now what BASIC used to be in 20th century.
I've seen some extremely worrying background behaviour, and I'd point out that it's installed with root access and that even on Debian all VSCode updates come directly from MS servers and run MS-supplied installation scripts with root permissions.Portable version of VScode that does not update on it self can be used on Windows, and to avoid MS telemetry and scripts VScodium might be a solution. According to https://duckduckgo.com/?q=docker+usb+access&ia=web it seams that some kind of host USB access can be given to a container.
I've seen some extremely worrying background behaviour, and I'd point out that it's installed with root access and that even on Debian all VSCode updates come directly from MS servers and run MS-supplied installation scripts with root permissions.Portable version of VScode that does not update on it self can be used on Windows, and to avoid MS telemetry and scripts VScodium might be a solution. According to https://duckduckgo.com/?q=docker+usb+access&ia=web it seams that some kind of host USB access can be given to a container.
I've seen some extremely worrying background behaviour, and I'd point out that it's installed with root access and that even on Debian all VSCode updates come directly from MS servers and run MS-supplied installation scripts with root permissions.Portable version of VScode that does not update on it self can be used on Windows, and to avoid MS telemetry and scripts VScodium might be a solution. According to https://duckduckgo.com/?q=docker+usb+access&ia=web it seams that some kind of host USB access can be given to a container.
hello all,
has anyone try pi pico for reading sd card on pascal??
thank you.
hello all,
has anyone try pi pico for reading sd card on pascal??
thank you.
No. I'd remark though as general points that I've used it (soldered to a "project board" with various stuff including an SD-Card socket) for FUZIX, which highlighted (a) you need to check the (SPI) pin allocation carefully and (b) remember that certain pins are usable as one or the other SPI interfaces, certain pins for UARTs and so on: poor choice of /which/ UART is to be used will have implications later if SPI functionality is added.
MarkMLl
i'm new on this field, i used to create something by sample, seems to be hard for me :)
SD card is very important for stand alone logging device i think.
i'm new on this field, i used to create something by sample, seems to be hard for me :)
SD card is very important for stand alone logging device i think.
Storage is important for a logging device, but an SD-Card might not be a good choice- at least with a standard filesystem.
The issue is that if you're logging, every time you commit data you will be updating metadata (i.e. the directory and FATs in the case of a FAT-based filesystem) which are typically at the start of the storage device. Now my understanding is that an SD-Card /might/, depending on the vendor, go to some trouble to extend the longevity of the low blocks; however since there is no wear levelling they are likely to fail before the remainder of the device: and when that happens your data is lost.
I've got various thoughts on mitigation which I'd prefer not to discuss, but you might find something like https://hackaday.com/2019/01/24/cool-tools-a-little-filesystem-that-keeps-your-bits-on-lock useful.
MarkMLl
Thankyou for your advice, is there any litlefs sample on pascal?