Saturday, August 3, 2019

VPC for Nucleo-F411RE ?

You can read the article here.

Friday, July 12, 2019

Wednesday, July 10, 2019

VPC version 3 released!

Finally! VPC looks decent now. 

- It comes with a full featured "Clock Setup" window of which settings are reflected in the generated code;

- Also provided some blink examples, using various clock sources at various frequencies - all blink examples should toggle the LED at 500ms interval. More examples to come - the old projects are not compatible as now you need version 3 of the project file;

- Fixed some "hard to detect" bugs.

Code committed in repository!

Thursday, June 27, 2019

Final version of "Clock setup" window mockup

This is the final version and I think it contains all the elements required to set the frequencies of the STM32L1 clocks regarding to the Nucleo board hardware. I'll work hard to make it functional, but it will depend on my health and time.

But now something is obvious: if I want to keep the resolution compatible with a modern laptop LCD screen (and I want to keep it), then there is no space for all the features a clock window setup has for an STM32F4 microcontroller - a micro that I want to target in the future for the same Nucleo 64pin board format.

Update July 1, 2019: It seems that the final version wasn't quite final... below is the most recent one, but that means even more work regarding the generated code and error solver...

UPDATE July 7, 2019: the clock configuration window is now 100% functional. Next, to work on the generation of the code according with the settings made in the clock configuration window and to modify the new/load/save project file (as we have new data to save) procedures accordingly. Soon...

Monday, June 17, 2019

Big bug fixed: pll settings

The PLL settings were way off. And that may be the reason why my onewire library didn't worked (is my next test to be done after this fix). Code was committed to the repository.


In the future (version 3?), the clock window configuration will allow much more flexibility - at least, at the CubeMX level. But not so soon. The mockup is ready...

Sunday, May 26, 2019

VPC version 2 released

Version 2

I pretty much believe that the version 2 of the VPC is a mature version. Even if it still says "Beta" and even if it comes with just a basic set of features. The code is simplified, modular and clearer, with some new features in regards to the version 1. And this being said, I will stop the development for now. All I'll do is bug fixing if necessary. I did this project to remain true to my words when I said on the ST Community forums that I'll make my own visual configurator than use CubeMX anymore and thank God I did it. So it stops here. I don't do much these days with STM32 micros and I toy with the idea of trying dsPIC33 micros for their DIP28 case and because they are working at 5Vcc. More than great for home automation projects. Anyway, it was a fun journey and I am proud of the result.

Elements of version 2 of VPC

What this project represents

Well, probably nothing for  you, but for me VPC is:
 - an open source tool that provides the best alternative to the CubeMX;
 - a tool that does not step on your intellectual property;
 - a tool that do not spies on your project or computer and do not call home;
 - a nice programming exercise in procedural pascal;
 - the only tool that provides a visual configuration for the SPL library;
 - an effort to learn the SPL library along with the development of VPC.

From where you can get it

From it's repository hosted at Gitlab. Look for the address in the right panel. I'll update another time the l152 projects already published that were created with version 1 of VPC.


Right now, the existing l152_* projects in the repository are not compatible with the version 2 of VPC.

Thank you for following this project!

Tuesday, May 14, 2019

VPC2 - update

Well, almost ready. Both Nucleo and LQFP64 pin configuration windows (both of them have functional, click-able pads) will use common code to set the pins. This results in clearer and cleaner code.

The GUI functionality will be a little different than in the first version of VPC regarding setting the parameters of the peripherals, but not in a bad way, I think. You'll see.

The project file has a new version. The VPC2 will be able to load projects created with the version one, but it will save the opened project as version two. Now those (three) pins that have fixed, permanent functions because how the Nucleo hardware is set (USART2 and user button B1), will also be saved in the project file, allowing further modification of the application's code.

I2C1 will be able to use any of the two pairs of pins (PB8-PB9, PB6-PB7). Currently, it uses only PB8-PB9 pair.

I had to do this, as the initial code was kind of an experiment and hard to manage (I wanted to see if I am able to free myself from the ST.M. tools). The restructured code will easily allow the add of new pin layouts as an 144pin Nucleo board or any custom layout without much hassle. 

As for progress, I am at conflict mitigation and at the I2C1 code generation according with the new changes. These are the last two things to get done before publishing the code.

Monday, April 29, 2019

VPC mock-up - Morpho and Arduino connectors

As I said, I started working to the new changes: in the image below you have the new pin configurator for Morpho and Arduino connectors. If you liked the previous more, is time to fork the project.

- the pin labels won't be permanently visible, you have to hover with the mouse pointer over the pin, and if there is a defined label, it will appear as a hint (tooltip). This is because I design for a Laptop limited screen resolution and because I'm using standard Lazarus components for the simplicity and portability of the code across languages and GUI interfaces.

- the window will share code with lqfp64 window so less code;
- hopefully, the code will be more readable and easy to follow, encouraging user changes and additions.

UPDATE: Well, I had to balance the image so added some more info...

Ha! I said in a recent post that I am not mentally prepared to start working on lqfp64 window and meantime I doubled the work to be done. Nice :P

UPDATE2: And this is the final version of the mock-up:

VPC - secured the "Generate Code" button

Because is destructive, I had to add a layer of confirmation. No more unwanted accidents.

What else? Cleaned up the UI and a little bit of code. The lqfp64 functionality is planned for 2.x.x version. Then, once is done, the "Nucleo Pinout config" window will be redesigned to use the logic from the lqfp64 window - so, if you want to keep the actual code, you have to fork it now. I mean it, as I already started changing the code.

Code committed in repository.

Sunday, April 28, 2019

VPC - new icon set

Just a cosmetic change, hopefully a tad prettier. Resized some messages but not all - next time.

Tuesday, April 23, 2019

New target in Makefile

Because the stlink software of @texane from github can be compiled under all major operating systems, I decided to make a new target in Makefile file, named upload. And of course, the tasks.json file is generated accordingly.

So, if you do not need debugging functionality, you can use just a simple text to edit your project and use make/gmake to generate de code and upload it in your Nucleo board. Code committed in repository.

BTW! If you want to update the json files and the Makefile of your projects, just open them again in VPC and hit the "Regenerate the VSCode files" button.

ATTENTION! Don't hit the "Generate the code" button, as your code will be lost - the VPC will generate the basic code conform to your selection, and the user code you added won't be preserved. YOU HAVE BEEN WARNED! That is, the "Generate the code" function is destructive.

Monday, April 22, 2019

No more Arduino dependencies

As I said before, the only reason of installing the Arduino extension in Visual Studio Code (and having VPC to generate the required configuration) was to benefit from the integrated serial communication terminal, which was (and I think it still is) the only decent solution for Visual Studio Code. This is not working in FreeBSD and I want a crossplatfrom solution. And I found one.

It is a terminal named Minicom that runs on Linux, Windows, FreeBSD and probably also Mac OS X, as it shares common things with FreeBSD. Citing the Wikipedia:

Minicom is a text-based modem control and terminal emulation program for Unix-like operating systems, originally written by Miquel van Smoorenburg, and modeled after the popular MS-DOS program Telix. Minicom includes a dialing directory, ANSI and VT100 emulation, an (external) scripting language, and other features. Minicom is a menu-driven communications program. It also has an auto ZMODEM download.

Once installed on your operating system, you open a console in Visual Studio Code and launch the minicom as in images bellow:

And if you get bored watching the data scrolling on your monitor, you stop the minicom with [ctrl+a] then [x] keys and a message appears as in image bellow:

That is all. A good solution watching your Nucleo board directly from inside Visual Studio Code sending serial data on USB.

So. the VPC will no more generate the configuration json files required by the Arduino extension made by Microsoft. The changes will be published soon in repository.

Saturday, April 20, 2019

FreeBSD - replacement for Project Manager

The Visual Studio Code extension Project Manager that I successfully used under Linux does not work in FreeBSD. Instead, you can install the Projects+ extension made by Fabio Spampinato which offers you similar behavior,

VPC - bugfix and additions

Solved a bug where PB2 pin set as ADC_IN0b had no effect.
Added a way to specify if the generated code targets Linux or FreeBSD OS.
Resized some windows to accommodate some text labels under FreeBSD - this may look funny under Linux. Code committed to repository.

And I just saw that the l152_tim6_systick project was generated with an old version of VPC that had no way to save the project so, you cannot upload it in the last version of VPC. But this problem remains to be solved another time.

Thursday, April 18, 2019

FreeBSD - bad news, good news

Bad news

1. gcc-arm toolchain: turns out my manually (and unscientifically) prepared toolchain based on an old FreeBSD package produces bad (non-working) code. I will destroy the download link from a previous article and post accurate info.

2. VSCode extensions: the "Arduino" and "Project Manager" extensions are not working under FreeBSD. The whole idea of using the Arduino extension was to have access to the serial terminal from inside VSCode - that does not work :(. I can live without "Project Manager" extension.

3. Arduino IDE: the FreeBSD "arduino" package has to be uninstalled as it is of an older version: 1.0.6 I think... but do not destroy the symlink you created in the previous article as is still useful (read below).

Good news

1. gcc-arm toolchain: after the failure, I kinda disarmed... but I searched deeper and there is a package that has to be installed, named gcc-arm-embedded - it happens to be the most recent version of the toolchain. And of course, after creating the required symlimk in the HOME folder (as in the image below), the projects are compiling and correct code is generated.

2. VSCode extensions: fortunately, Tasks are working so I am able to clean, compile and upload the project unto the Nucleo board. As for serial terminal, I launch the Arduino IDE and use the serial terminal from there:

3. Arduino IDE: the correct package you have to install is named "arduino18". That is all, you don't need to edit the symlink you created as in previous article because the package uses the same folders - it will remove the old package.


I don't know what to say, obviously you can develop STM32 applications under FreeBSD but here is less functionality compared with Linux environment regarding VSCode as IDE (and I did not even tested the Cortex-Debug extension). But this does not affect the VPC and the projects generated with it. I will add an option that will generate tasks for gmake in FreeBSD, but I will not touch the Arduino options that remains Linux specific. At least for now.

Anyway, I am committed to development under FreeBSD as now is my main OS and working desktop. Maybe until Lazarus+FreePascal will have a version for DragonFlyBSD - hopefully, my final station.