Updated STM F1 core to support BluePill including USB Serial

Information on the latest releases
User avatar
RogerClark
Posts: 5330
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Postby RogerClark » Wed Nov 16, 2016 10:11 pm

Rick

Both Danieleff and I have looked at this

I think there is a possible solution for the analog config struct, because it seems that pwm_start and pwm_stop use it (for the timHandle) but as far as I can tell timHandle does not really need to be stored as a global

In anlog.c pwm_start sets up the the TIM_HandleTypeDef struct, before calling HAL_TIM_PWM_Init and in pwm_stop it calls HAL_TIMEx_PWMN_Stop etc

But if we are lucky HAL_TIMEx_PWMN_Stop() , HAL_TIM_PWM_Stop() and HAL_TIM_PWM_DeInit() don't really need the "init" part of the struct, i.e.

this is how its setup

Code: Select all

 
  timHandle.Init.Prescaler         = (uint32_t)(SystemCoreClock / clock_freq) - 1;
  timHandle.Init.Period            = period;
  timHandle.Init.ClockDivision     = 0;
  timHandle.Init.CounterMode       = TIM_COUNTERMODE_UP;
  timHandle.Init.RepetitionCounter = 0;
 


But if we are shutting it down, I can't see why the HAL should need the period or the prescaler. (after all, the other values are hard coded), so we could just put some defaults into the period and prescaler before calling the deinit funcs

See

https://github.com/stm32duino/Arduino_C ... /issues/23

If I have time I may try this later and see if its possible to not retain the whole timHandle in the analog struct and just create a local var in pwm_start and pwm_stop, and in pwm_stop, populate it with the minimum needed data

Edit.

I don't that idea will quite work, I think timerChannel may also be a problem

Edit 2

Umm.
Looks like quite a lot of things need to be declared as const, in both the analog config struct and the functions that use that struct

This reminds me a not of the pin map problem we had / still have with libmaple ;-)

User avatar
Rick Kimball
Posts: 711
Joined: Tue Apr 28, 2015 1:26 am
Location: Eastern NC, US
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Postby Rick Kimball » Thu Nov 17, 2016 3:01 am

I was just making an observation, I didn't expect anyone to fix it. The stm32 vl board is ancient and these HAL ports by ST are focused on the nucleo boards and chips that have more memory. Don' t flog yourself looking for a solution.

My comment is more geared to what I think about the HAL code in general. Lots of code layers and structures that seem to be designed by someone used to doing desktop development instead of embedded code. Which in the end don't actually make it any more flexible or extensible as we quickly found out when we wanted to add our boards

-rick
-rick

User avatar
RogerClark
Posts: 5330
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Postby RogerClark » Thu Nov 17, 2016 3:33 am

Hi Rick

No worries

I just bugs me when code is unnecessarily wasteful.

From what @danieleff has notice, the whole analog config stuct array (all 2k of it) is only used by 2 function calls to do with PWM.

So this smacks of lazy programming.

Yes. The HAL is wasteful, but in this case I don't think the HAL is to blame

User avatar
RogerClark
Posts: 5330
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Postby RogerClark » Fri Nov 18, 2016 10:26 am

The WIP branch has slightly reduced the RAM usage (well nearly 1k less) by refactoring one of the structures into const and non const parts.

Looking at some of the other global arrays, they are quite wasteful, in particular the pinDescription structure is used for a number of different things, and needs to be split into separate const and non const arrays, (most of it can be const).

I don't know how much RAM it will save, perhaps another 1K if I modify all the places that use that struct.

konczakp
Posts: 108
Joined: Thu Jul 14, 2016 4:17 pm

Re: Updated STM F1 core to support BluePill including USB Serial

Postby konczakp » Fri Dec 09, 2016 9:51 am

When choosing Maple Mini there is only STM32duino bootloader in upload method available while in Roger's maple mini hardware there is an option to choose original or v2.0. Does this mean that I have to update bootloader in my mapple to get this working or there is some kind of trick to add Original bootloader do the upload methods. Can I copy paste some settings ?

danieleff
Posts: 103
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Postby danieleff » Fri Dec 09, 2016 10:12 am

konczakp wrote:When choosing Maple Mini there is only STM32duino bootloader in upload method available while in Roger's maple mini hardware there is an option to choose original or v2.0. Does this mean that I have to update bootloader in my mapple to get this working or there is some kind of trick to add Original bootloader do the upload methods. Can I copy paste some settings ?

There is a "Maple bootloader (original version)" upload method in boards.txt, it is just commented out (as it was not working).
You might get it to work by uncommenting the lines, and changing `...upload.altID=2` to `...upload.altID=1`
I have not tried it as I do not have a board with the original bootloader.

User avatar
RogerClark
Posts: 5330
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Postby RogerClark » Fri Dec 09, 2016 10:34 am

I think I added that to boards.txt in the WIP branch as I had an unmodified Maple mini and it didnt initially work

konczakp
Posts: 108
Joined: Thu Jul 14, 2016 4:17 pm

Re: Updated STM F1 core to support BluePill including USB Serial

Postby konczakp » Fri Dec 09, 2016 12:42 pm

Ok! it is uploading now and simple programs are running fine with original bootloader. As for the I2C communication, unfortunately when trying to Wire.begin(0x2); It freezes the serial (cdc USB) and I'm unable to check if it is working. By freezing I mean it is not even showing as cdc driver on my Ubuntu. I could try to blink led but I need serial to be working. Serial alone is working fine. Can someone with bootloader 2.0 and maple mini try to upload this sketch below and check if serial is working?

Code: Select all

#include <Wire.h>
 
#define I2C_ADDRESS_OTHER 0x2
#define I2C_ADDRESS_ME 0x1
 
void setup() {
 Serial.begin(115200);
 Wire.begin(I2C_ADDRESS_ME);
 Wire.onReceive(receiveI2C);
}
 
void loop() {
 delay(5000);
 Serial.println("OK");
 Wire.beginTransmission(I2C_ADDRESS_OTHER);
 Wire.write("hello world from 0x1 to 0x2");
 Wire.endTransmission();
}
 
void receiveI2C(int howMany) {
 while (Wire.available() > 0) {
  char c = Wire.read();
  Serial.print(c);
 }
 Serial.println();
}

danieleff
Posts: 103
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

Re: Updated STM F1 core to support BluePill including USB Serial

Postby danieleff » Fri Dec 09, 2016 1:08 pm

I2C is currently hardcoded to the alternate pins PB8/BP9. On maple mini, PB9 is connected to USB as a reenumeration pin, so using I2C will accidentally disconnect USB.

You can set the default pins if you change `.sda_pin = GPIO_PIN_9` to `GPIO_PIN_7`, `.scl_pin = GPIO_PIN_8` to `GPIO_PIN_6`, and __HAL_AFIO_REMAP_I2C1_ENABLE() to __HAL_AFIO_REMAP_I2C1_DISABLE(). This also corresponds to pin 15/16 written on the board.

This part of the code will need to be changed so pins can be set in variants. This will be a bit of work...

konczakp
Posts: 108
Joined: Thu Jul 14, 2016 4:17 pm

Re: Updated STM F1 core to support BluePill including USB Serial

Postby konczakp » Fri Dec 09, 2016 2:16 pm

After those changes Serial is working again! Thanks for that. But how I can set which I2C (I2C1 / I2C2) port to use?


Return to “Builds and Announcements”

Who is online

Users browsing this forum: No registered users and 1 guest