C2NEmu GUI client progress

I finally had some time and inclination to progress the C2NEmu GUI client and add most playback related features, including Play/Resume, Pause, and Stop button callbacks.

C2NEmu GUI playback client by Luigi Di Fraia

C2NEmu GUI playback client

In the above image “Real Stunt Expert” was fully played back in under 2 minutes as indicated by the buffer time tracker above the Stop button.

The IDX editor was already completed some time ago, so I envisage making the updated software available soon. I will work at minor changes over the next few days to make sure user experience is fine and that the GUI is fool-proof 😀

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

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