Very tricked-out .ini file

PlatformIO IDE
#1

Over the past few months, I’ve been given several things to include in my .ini files.
I want to actually learn those things. It’s all stuff I’d delete when finalizing the program.

I want to debug. I haven’t debugged anything, and I want to use that feature.
I’m using ESP machines, so I want to be able to access whatever they want to communicate.

What else can go into that file, that one might use to build a better program?
What do you include?

I’ve posted too many items, so the collection of past responses isn’t really useful.

#2

Morning @Monsterthews – hope you are safe and well.

I’ve not yet started with ESP stuff, but I have a box of three “Blue Pills” (STM32F103C8T6), a couple of WEMOS D1 Mini boards and a Nucleo-F103RB develpment board to play with – none of which I’ve plugged in and tested yet I’m afraid. This is due to a family medical problem, Covid19 and my wife thinking that I should “get a life” :grin: I’m also writing my second Arduino book at the moment – when I’m “allowed” some free time by SWMBO. (She Who Must Be Obeyed! :rofl:)

My Uno and Duemilanove, on the other hand, I have used frequently in the Arduino IDE and in the PlatformIO IDE system in VSCode.

I’m puzzled here. Why would you want to delete stuff from the platformio.ini file when you are ready to finalise the program? Surely, only stuff that’s relevant to the final program would be in your ini file?

Moving on.

The INI file

The ini file is documented at “platformio.ini” (Project Configuration File) — PlatformIO latest documentation and covers basic stuff about the file. Project examples can be found at Examples — PlatformIO latest documentation where there appears to be a couple for the ESP platform.

Regarding your ESP boards, there is a list of boards at Boards — PlatformIO latest documentation and if you find your board in the list in the contents sidebar (left side) then click it to open that page. My D1 Mini board is covered at WeMos D1 R2 and mini — PlatformIO latest documentation.

On that page you will see lots of specific information regarding that one board:

  • Hardware which tells you about the hardware itself;
  • Configuration - shows you what you should be using to configure the board in the ini file;
  • Uploading - tells you which protocols etc are available to upload programs to this board;
  • Debugging - covers debugging, if available, for the board. The WEMOS D1 Mini has no debugging abilities;
  • [Frameworks] - Which frameworks can/will be used when you initialise a project for this board.(WeMos D1 R2 and mini — PlatformIO latest documentation)

Debugging

If debugging is available for your board, the debugging section will tell you how to use it. There are lots of docs at Debugging — PlatformIO latest documentation on basic debugging.

Be aware that some platforms allow proper hardware debugging, while others, like the Arduino, have simulated debugging which doesn’t work in all situations. The Uno, for example, has all it’s debugging information under the details of the board at Arduino Uno — PlatformIO latest documentation. You can see that there are two options for debugging. When I’ve needed it, I used simavr. So I had to add things to the ini file to cover that. What things? Click on the simavr link and you will find out at simavr — PlatformIO latest documentation

debug_tool = simavr

Easy peasy. If you want to use the default debugger, avr-stub then you need to go here instead avr-stub — PlatformIO latest documentation but this option requires a bit more setup.

Other Stuff

When you find something that helps you out, in a posting, bookmark it for later reference. Click the ... at the bottom of the particular post, then select the bookmark icon – which on my browser is between the "penciland thebin` (Trash can?).

How to find your bookmarks? Click your own avatar/image/icon at the top of the page, click “Activity” at the top, click “Bookmarks” on the left. The right side will be populated with your bookmarked posts.

Well, that depends. Mostly for my Uno/Duemilanove stuff I usually just add in the serial monitor stuff that I need to replicate the Arduino IDE’s Serial Monitor utility. For me, I’m usually at 9600 baud and I like to be able to type a string of characters before the Arduino board’s USART starts grabbing them! This is what I use:

monitor_speed = 9600
monitor_filters = send_on_enter
monitor_flags = 
    --echo 
    --eol 
    CRLF

These settings work perfectly for me in Putty (on Linux), Miniterm, in the PlatformIO Monitor utility – which I thing is also MiniTerm – and also, CoolTerm.

Sometimes I remove stuff from the ini file. While a lot of my Arduino code is written using the Arduino framework, I often write stuff in plain AVR C++ as it is invariable quicker, smaller and, ahem, better! (When my next book comes out you’ll find a lot of AVR C++ code in there!) To avoid having PlatformIO always compiling the unwanted Arduino core software. I comment out the framework line in the ini file:

; framework = arduino

That way, I can easily add it back in if necessary.

Hope this helps in a small way.

Cheers,
Norm.

#3

Deleting stuff from the final draft:
I placed my web pages wherever I wanted them. My Tecan Genesis page Googled ahead of Tecan’s Tecan Genesis page. I was lucky enough to be learning HTML while Google was learning how to Google, publishing white papers constantly.

Little things like going from ‘.html’ to ‘.htm’, ‘.jpeg’ to .jpg’ can significantly change your character count, word count and thus relevance. And it should work better- especially if you’re a minimalist from go.
This gives me a bias for lean. I want zero unnecessary characters. I hate fat, and tiny fascinates me. I want to be a molecule.

So, when I commit to burning a chip (This has been moved very far into the future. Six months ago, I thought I’d be ready tomorrow.), I want the code to have the smallest footprint possible without harming traffic flow.
I guess all the non-coding crap in most library folders doesn’t get compiled at all.
So now we’re overlapping DNA conceptually, which is a kick.

#4

monitor_flags- ??
monitor_filters- ??

These lines will cause things to happen in the serial monitor, yes?
The machine is seeing things and commenting on them, and these cause those comments to be shared via serial?

There was a special message for ESP chips.

I’m going to read the .ini documentation now.

#5

I can understand minimalist, sometimes.

You are aware, I hope, that even though you compile a C++ source file into an object file (*.o) that it’s not included in the final executable unless something within is called or used? The linker does a pretty good job of minimising things already.

You are running Windows! :rofl:

Tiny is good, I use an ATtiny85 for a few of my projects. My “Lime Tree watering device” whihc looks after my citrus tree when I’m on hjoliday, is using an ATtiny85 to monitor water content and to water the tree if necessary.

You can get smaller than a molecule you know – atoms are smaller, and they are made up of quarks. Very tiny! (And they have weird names!)

Seriously though, there’s probably no need to remove stuff – but it’s your decision.

Cheers,
Norm.

#6

I really started this Arduino thing in March, after some dabbling and twenty+ years of automating applications in the laboratory. My ideas have become very sophisticated, and the rest of my brain is struggling to catch up. I wonder if memory size will still matter to me in six more months.

I’ve been doing molecular biology since the 90s, and lab automation since 2000. I wrote my first function a few weeks ago, and it works. Still don’t know what a class is. Wouldn’t recognize one, unless it always says ‘class’.

Wow. It looks like .ini can be very involved.
Does all of that involvement make it work better?
Or is it just for nerds?

On a related note, I’m struck by this thought: If I understood libraries, I’d be able to write one very lean cover-all library for an entire application, like ‘environmental telemetry’. I’m always going to try to push memory size down, so I want to compile as little as possible. These libraries can be mountainous.

I want to debug, right? So I want to build stuff in during development and drop it when it’s production-ready. Mind you- I have no idea what ‘debug’ is going to look like. I can’t understand it yet. Naïve.

Since I’m using .ini files with nothing added to the virgin auto-generated file, I assume these added lines are all only really useful in higher, analytical environments.

None of this stuff should matter if you’re just reading a sensor and blinking a light or switching a relay. I wonder if any of it can help with frequencies and broadcast stability.

lib_deps_builtin =
SPI
Wire
–>Should I be doing this? Is this more better?

[platformio]
default_envs = nodemcuv2
–>Isn’t this redundant?

I am a snob. I have opinions on code writing style now, and I can’t write. I’m interested in the topic of your book. I am saturated with the reading now, because the resources all look the same to me at this point.

#7

If you are as old as me, memory size will be fine. The ability to recall stuff might be a problem!

You are correct in that it can get very complicated, but if you think about it, you are telling the system how to compile, what tools to use, where to find libraries, what compiler options to use, how to configure the monior etc etc – this is effectively, the entire project’s “control” file.

You only need enough “stuff” to make it work. Think minimal – as you indicated, you prefer.

Nerds, and anyone else, can use it.

You wrote a function, and it worked. A library is either:

  • A number of functions, gathered together into one place; or;
  • Some code to define a class (aka object, aka thing etc), and to implement it.

The class declaration starts with:

class whatever ... {
    ...
};

You’ve been using them in the Arduino world, like this:

Serial.begin(9600);
Serial.print("Hello World!");
Byte ch = Serial.read();

Serial is a class to implement the serial communications using the microcontroller’s USART. begin(), print() and read() etc, are class members

Nothing to remove, you build and test with the debug environment and go to production with the release environment. Release is the default.
See Build Configurations — PlatformIO latest documentation for more details.

Unlikely. Those are features of the device/microcontroller and would be set by choosing appropriate values for a “class” – think Serial.begin(9600), or doing it by setting various registers as per the data sheet.

The book covers more than you’ll ever need to know about how the Arduino software works, how it talks to the hardware to make it do, pinMode(LED_BUILTIN, OUTPUT) for example. Go to Apress.com and search for my name. Amazon might have a sample chapter, maybe.

Cheers,
Norm.

#8

Serial is a class…

“Debugging” means watching how the hardware and software interact?
You don’t ‘debug’ static text that isn’t actually doing anything?

#9

Yes indeed, Serial is a class. As is EEPROM, wire etc.

You debug code when it’s not doing what you think you asked it to do. Static text does nothing – except perhaps being spelt or formatted incorrectly, so there’s nothing to do there but fix it.

Fixing static text does come slightly under the degugging umbrella though – the application is not correct until it’s fixed.

Cheers,
Norm.

1 Like