hippy
Posts: 10538
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: is the arduino support for RPI2040 better then CMAKE ????

Fri Jul 30, 2021 7:38 pm

emma1997 wrote:
Fri Jul 30, 2021 6:17 pm
So little interest in another bloated IDE ...
Nor me which is why I don't intend for it to be bloated. It's basically a NotePad style editor with a click to build button. It's Arduino-style but there's nothing much to it, just a few dozen lines of Python with TkInter providing the GUI, 'cmake' called to do the building.

It's really just a ready-to-go shim for those who want or prefer to edit and compile from the desktop rather than the command line, who don't want to configure some other editor or VS Code to do that.

Of course it's bound to grow as more than basic editing and formatting options get added, as I better make it do what it has to, but I am aiming to keep the bloat down to adding lines of source code rather than doing anything fancy which increases execution time or memory hogging. I'll also be having an option so the user can select how simple or comprehensive they want things to be.

hippy
Posts: 10538
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: is the arduino support for RPI2040 better then CMAKE ????

Fri Jul 30, 2021 8:10 pm

emma1997 wrote:
Fri Jul 30, 2021 6:17 pm
definitely interested in 'picocc main.c'. I downloaded your zip file but w/o kindergarden setup instructions and being no fan of py files backed out for now. I'll wait to see if anybody else gives it a go and what feedback.
I guess I should have added some sort of instructions :oops:

First step is to create a directory to play in and get the picocc.py.

Code: Select all

mkdir ~/picocc_test
cd ~/picocc_test/
cp <somewhere>/picocc.zip .
unzip picocc.zip
rm picocc.zip
rm xyzzy.c
At this point we have a directory with only 'picocc.py' in it. Now to get a real Pico SDK C project. We'll borrow "hello_usb" from 'pico-examples' ...

Code: Select all

cp ~/pico/pico-examples/hello_world/usb/hello_usb.c .
So now we have just a C file and picocc.py ...

Code: Select all

pi@Pi3B:~/picocc_test $ ls
hello_usb.c  picocc.py
Then the magic ...

Code: Select all

python3 picocc.py
That finds and scans the 'hello_usb.c' file, creates a 'CMakeLists.txt', invokes a 'cmake .', then runs 'make', and you should end up with a 'hello_usb.uf2' you can flash to your Pico ...

Code: Select all

pi@Pi3B:~/picocc_test $ ls
CMakeCache.txt       elf2uf2        hello_usb.dis      hello_usb.uf2 
CMakeFiles           generated      hello_usb.elf      Makefile
cmake_install.cmake  hello_usb.bin  hello_usb.elf.map  picocc.py
CMakeLists.txt       hello_usb.c    hello_usb.hex      pico-sdk

User avatar
nick.mccloud
Posts: 1280
Joined: Sat Feb 04, 2012 4:18 pm

Re: is the arduino support for RPI2040 better then CMAKE ????

Sun Aug 01, 2021 8:18 pm

hippy wrote:
Fri Jul 30, 2021 4:26 pm
There is an argument that one shouldn't even need to include header files when the compiler and/or build system can figure out what header files need to be included and which libraries need to be linked. That's just imposing an unnecessary burden on the user by forcing them to include them, having to figure out exactly what to include, having to discover and specify which libraries need to be linked.
The Arduino method requires you at least give the build system a hint of what you want access to via the #include which is made rather easy via the menu option. Otherwise it has to scan all the installed libraries to find the function names if there are two or more functions of the same name, bad things could happen. It doesn't seem unreasonable for a developer to say "I want to use these extra facilities" if only because they are making a deliberate choice to use something. Otherwise you could include every library available and hope the compiler manages to not include the whole shebang in to the binary.

The 'nice' bit of the Arduino method is that the user code doesn't have to have lots of header files created as you go to get a successful build. This works nicely with co-development projects where we may end up with a dozen .ino files to provide separation of concerns / development / quasi-object-encapsulation.

Perhaps if the include bit was disguised a bit more with some selection system that refers to the functionality they want to use more than the sometimes cryptic header name that would be a nice balance.

For more robust / critical systems, explicit includes of a version is the only real way to go.
Pico/RP2040 ≠ Arduino
Pico = hot rod kit car, Arduino = hot rod kit car wrapped in cotton wool with buoyancy aids & parachute

hippy
Posts: 10538
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: is the arduino support for RPI2040 better then CMAKE ????

Mon Aug 02, 2021 1:33 pm

nick.mccloud wrote:
Sun Aug 01, 2021 8:18 pm
The Arduino method requires you at least give the build system a hint of what you want access to via the #include which is made rather easy via the menu option. Otherwise it has to scan all the installed libraries to find the function names if there are two or more functions of the same name, bad things could happen.
It wouldn't be too onerous if that scanning was only done as part of the installation, the first ever compilation, or only when the libraries changed.

Libraries with same name functions can be problematic but it wouldn't seem unreasonable to disallow those, require all names to be unique to comply with the development environment, not accept libraries which do not conform to the requirements. But it would be better to allow anything and everything, allow a default to be set where conflicts occur which can be altered as needs be.

That a development environment could sort everything out without #include doesn't mean that #include has to be disallowed. I would allow them to cater for cases where that might be needed, or to override defaults.

As defaulting system would allow advanced users to override a default or disable it. Professional programmers could disable all defaults which would force them back to always using #include if they want that.

I think "give the build system a hint of what you want" is in fact the key here. An inexperienced programmer wouldn't and shouldn't have to because they wouldn't be doing anything the build system couldn't guess correctly. The hinting would become "not what you would, but what I want", only needed when a problem arises, and only needed by advanced programmers.

Return to “SDK”