Donate page created

I was asked a few times whether there’s a way to donate me some money for my work, especially after I implement change requests to my software as requested by its users. Historically I have dismissed the topic, but I’ve recently received multiple requests to take donations so I decided to provide receive addresses for Dash and Bitcoin.

Please feel free to use the receiving addresses under my new Donate page for donations. Thank you in advance 🙂

Posted in Donate | Leave a comment

Change request for DC2N5-LC implemented

The other day Nuno suggested showing some version information in DC2N5-LC, and I agree that’s something that would be beneficial.

Along with the version number I am now also displaying the system date and time, after a time synchronisation file has been read in, if available. Here’s an example of how DC2N5-LC looks like at startup time:

New DC2N5-LC startup info

New DC2N5-LC startup info

Posted in Retrocomputing, Technical | Tagged , , , , , , , | Leave a comment

Latest DC2N4-LC GUI clients tested successfully

After having worked out a simple way to expose additional dumping modes in DC2N4-LC GUI clients, as it was already occurring in CLI clients, I implemented the relevant changes. Over the weekend I finally managed to run a few tests. I am very happy with the results so it’s time to offer an update.

DC2N4-LC GUI users: feel free to get in touch for the update 🙂

Latest DC2N4-LC Windows native client

Latest DC2N4-LC Windows native client

Latest DC2N4-LC GUI client running in Xubuntu Linux 16.04

Latest DC2N4-LC GUI client running in Xubuntu Linux 16.04

Latest DC2N4-LC GUI client running in Xubuntu Linux 16.04

Latest DC2N4-LC GUI client running in Xubuntu Linux 16.04

Posted in Retrocomputing, Technical | Tagged , , , , , , , , , , , | Leave a comment

SysTick with STM32CubeMX

OK, so it appears that with projects generated through STM32CubeMX the place where to insert custom SysTick code is not within the HAL, but in one of the auto-generated “User” files, stm32f1xx_it.c. This file contains the definition of active IRQ handlers.

Here’s what the SysTick handler looks like once I modified it:

/**
* @brief This function handles System tick timer.
*/
void SysTick_Handler(void)
{
  /* USER CODE BEGIN SysTick_IRQn 0 */
  static uint32_t led_timer;
  /* USER CODE END SysTick_IRQn 0 */

  HAL_IncTick();
  HAL_SYSTICK_IRQHandler();

  /* USER CODE BEGIN SysTick_IRQn 1 */
  if (++led_timer >= 500) {
    led_timer = 0;
    /* Toggle LED state */
    HAL_GPIO_TogglePin(LED1_GPIO_Port, LED1_Pin);
  }
  /* USER CODE END SysTick_IRQn 1 */
}

Sadly, once again, the above code does not seem to have any effect for the board I am using despite most of the code and initialization is auto-generated by STM32CubeMX. The USB setup, however, works fine. Activating the USB CDC class implementation is proving to be far easier than flipping a LED with STM32CubeMX 😀

Posted in Technical | Tagged , , , , , | Leave a comment

Bonus content for STM32F10x standard peripheral library added to GitHub

UPDATE: I decided to delete the GitHub repository discussed below as the components therein are bound to different licensing agreements that I am not sure I can satisfy all at once.
As a matter of fact, I think ST Microelectronics are themselves in a questionable position for distributing the source version of certain third party components that are covered by non-disclosure agreements.

I decided to make my most recent efforts with STM32 microcontrollers available to the public on GitHub. It’s true that the STM32F10x is a somewhat old class of microcontrollers, but it’s also true that they are incredibly good value for money running at up to 72 MHz, and the software ecosystem for them is quite mature. Standard libraries also offer a hardware abstraction layer (HAL) that facilitates migration to newer microcontrollers.

Specifically, my “bonus” content refers to the board as per below:

ARM STM32 Minimum System Development Board

ARM STM32 Minimum System Development Board

This board is supported to some extent by the mbed community, as per start-up project at this location. However, there seems to be an issue with the 16-bit SPI software abstraction, and who knows what else.

There is also some unofficial Arduino support Roger Clark has been working at, as per link. If that’s what floats your boat, you might want to give it a go. I seem to recall the hardware control layer is based on STM’s standard peripheral library anyway.

My own contribution comes in two different approaches:

  • Makefile approach: download and install GNU for ARM embedded tools (I tested with 4.9 and 5.0), clone my GitHub repo STM32F10x_StdPeriph_Lib, open a GCC CLI, navigate to the SysTick example project, issue “make” to build it, upload to the board and enjoy the result;
  • TrueSTUDIO approach: clone my repo, open the workspace in TrueSTUDIO, replace template project files with the ones from the SysTick example, import the STM32F103C8T6-BLUE project and build it. If you get an error around strexb or strexh, refer to this previous post of mine.

Out of the two, I will be mainly using the Makefile route if I have to start new projects for this board.
The second approach actually extends STM’s standard peripheral library with a custom family of boards and a custom board so the extension has the look and feel of the official projects and templates. Further extensions can be done in pretty much the same way as I did.

Closing note. If you need USB, use STM’s USB device library: you can find it on their website by looking for “STM32F10x, STM32L1xx and STM32F3xx USB full speed device library (UM0424)”. I’ve successfully tested the Virtual COM Port example on the above mentioned board and I will be providing a similar extension to the USB library as I did for the standard peripheral one.

Posted in Technical | Tagged , , , , , , , , | Leave a comment

More on STM32Cube and the Standard Peripheral Library

This evening I decided to have a go at flipping the LED on my STM32 board using STM32CubeMX to generate a TrueSTUDIO project. Within the project I decided to use the SysTick timer to implement the “flipping” code. After appreciating that the SysTick is initialized for 1ms period and that the Pin where the LED is connected is correctly set to Output by the auto-generated code, and its port is correctly enabled, I had to figure out where to put the flipping code.

It turns out that the HAL documentation is pretty much auto-generated from code comments so after some digging I came to this function:

/**
  * @brief  SYSTICK callback.
  * @retval None
  */
__weak void HAL_SYSTICK_Callback(void)
{
  /* NOTE : This function should not be modified, when the callback is needed,
            the HAL_SYSTICK_Callback could be implemented in the user file
   */
}

So I decided to implement it in my user source as per below:

/**
  * @brief  SYSTICK callback implementation.
  * @param  None
  * @retval None
  */
void HAL_SYSTICK_Callback(void)
{
  static uint32_t led_timer;

  if (++led_timer >= 500) {
    led_timer = 0;
    /* Toggle LED state */
    HAL_GPIO_TogglePin(LED1_GPIO_Port, LED1_Pin);
  }
}

Result? No LED flipping.

OK, I have no motivation to troubleshoot this at the moment, but with everything auto-generated for me for initialization and configuration purposes, the chances I forgot something in the above implementation are quite slim.

Fine, I moved on to the Standard Peripheral Library, which apparently enjoys a better reputation in the STM32 user community. I tried the SysTick code example for TrueSTUDIO and it did not compile at all: 22 errors. Example:

selected processor does not support `ldrex r0,[r0]' in Thumb mode

Once I added the -mcpu=cortex-m3 compiler option, I was left with just two compiler errors, one of which was:

registers may not be the same --strexb r0,r0,[r1]'

At this point Google came to the rescue. I edited core_cm3.c within the CMSIS library as per this Gist:

-   __ASM volatile ("strexb %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
+   __ASM volatile ("strexb %0, %2, [%1]" : "=&r" (result) : "r" (addr), "r" (value) );
...
-   __ASM volatile ("strexh %0, %2, [%1]" : "=r" (result) : "r" (addr), "r" (value) );
+   __ASM volatile ("strexh %0, %2, [%1]" : "=&r" (result) : "r" (addr), "r" (value) );

After that, the project compiled fine for the MCU I use. After flashing the binary, I ended up with a flipping LED 🙂

I certainly had to write more code and fix compilation/configuration issues with the Standard Peripheral Library, but that might be related to the fact the TrueSTUDIO template project provided therein is not up-to-date and the build toolchain in TrueSTUDIO was certainly updated since STM developers last tested the SysTick example. With the free version of TrueSTUDIO one cannot cherry pick the toolchain version either… Hm, I wonder whether that’s on purpose…

Based on these two experiences I would say that I am more inclined on using the Standard Peripheral Library route but I would definitely want to give the STM32CubeMX -> TrueStudio+STM32Cube another go.

Many years ago I was already past this stage with my Atmel SAM7S256 ARM  MCU and their framework. I was at some point using DMA in conjunction with SPI in order to drive an LCD, as per image below:

ARM board and new display by Luigi Di Fraia

ARM board and new display

It feels like going back a life time when you have to evaluate a framework you are not familiar with and bugs might be lurking anywhere waiting for you to hit them 😦

Posted in Retrocomputing, Technical | Tagged , , , , , , , | 1 Comment

STM32Cube and Atollic TrueSTUDIO

This evening before bed time I decided to give STM32CubeMX and Atollic TrueSTUDIO (built on Eclipse) a go in order to generate a simple project to run on the STM32 board I use for development.
Whenever I try a new build tool-chain and libraries for such board, the first gain I am looking for is a simple setup of the USB port as Virtual COM port.
Honestly, this was rather easy to do with STM32CubeMX and TrueSTUDIO, although under Windows 10 it took a few connection attempts before the system correctly enumerated the USB device. I had a few errors with Windows 10 complaining about not being able to retrieve the descriptor from the USB device, but the error went away eventually and the peripheral started working fine.

The USB device (VCP) generated through STM32 Cube didn't enumerate properly in the beginning under Windows 10

The USB device (VCP) generated through STM32 Cube didn’t enumerate properly in the beginning under Windows 10

The USB device (VCP) eventually started working

The USB device (VCP) eventually started working

Indeed I can see that VID and PID match the ones configured within the CDC descriptor source code:

Default VID and PID of the USB device created by STM32 Cube when selecting the CDC VCP class

Default VID and PID of the USB device created by STM32Cube when selecting the CDC VCP class

As you can see, within the generated source code VID and PID occur as decimal numbers instead of hexadecimal. I was puzzled as to why the generated code uses decimal values, but I guess it’s STM32 developer’s preference to use decimal values. Pretty much the whole rest of the world uses hexadecimal values here…

I was also quite intimidated by a forum post about how broken the STM32Cube software ecosystem is that I decided not to go too far too quickly with this build tool-chain and set of libraries. I will definitely go through the following stages in order to build some confidence, but at the moment my expectations are quite low:

  1. toggle the onboard LED (yes, always start with that as it’s the Hello World of embedded systems when you try a new development framework!),
  2. get a loopback on the VCP,
  3. bridge one of the UART ports to the VCP,
  4. have a go at SPI, I2C, etc.

Should I find too many frustrated comments online about using STM32Cube for any of the above, I think I will save myself the frustration and move away from it. I’ve already had a disappointing experience with the mbed library for this MCU (bug with the SPI communication) that I ‘d be OK going on working with my own startup code, register definitions and Makefile as I’ve done so far.

I was looking for portability and a readily usable USB device stack without having to bang my head on somebody else’s bugs. Have I just found it? More to come…

Posted in Technical | Tagged , , , | Leave a comment