HALMX :: MXBluePillF103C8 Roadmap

Development of new Cores using the STMCubeMX and HAL
User avatar
Vassilis
Posts: 304
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Thu Jun 02, 2016 2:27 pm

@Roger

For using the DISC pin on maple mini replace the init code into the USBSerial.cpp file

USBSerial.cpp

Code: Select all

void USBSerial::init(void){
/* Re-enumerate the USB */
  volatile unsigned int i;
  
#ifdef USB_DISC_PIN
  pinMode(USB_DISC_PIN, OUTPUT);
  digitalWrite(USB_DISC_PIN, HIGH);
	for(i=0;i<512;i++);
  digitalWrite(USB_DISC_PIN, LOW);
#else
  pinMode(USBDP_PIN, OUTPUT);
  digitalWrite(USBDP_PIN, LOW);
	for(i=0;i<512;i++);
  digitalWrite(USBDP_PIN, HIGH);
#endif

  MX_USB_DEVICE_Init();
}
chip.h

Code: Select all

//USB Plus (+) pin number. That pin is normally pulled-up to 3.3v by a 1.5k resistor on bluePill boards
#define USBDP_PIN PA12

//Include this line if the disconnect pin is used (The maple mini uses the DISC pin PB9).
#define USB_DISC_PIN PB9
It works on my maple mini

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by RogerClark » Thu Jun 02, 2016 10:33 pm

vassilis

Thanks
I didnt realise that the pin was defined elsewhere as well as in USBSerial.cpp

Perhaps we can get USBserial.cpp to use the same #define , so it only needs to be changed in one place


I think I miss understood your posting.

I thought you were saying that it was already defined in chip.h, but I now realised this is new code.

I looked at the code in Libmaple, and it just seems to drive the USB DISC line LOW and holds it low.

But I see your code drives it LOW then back to HIGH. I'm not sure why there is a difference, but I suppose as long as it works (at the moment) it is better than it not working at all, as it will allow people with the Maple mini to use the core.

The only slight problem is that I need to completely duplicate all the Cube file for the MXBluePill to make make the Maple mini, but there are in reality very few differences. (just the flash size and the USB reset)



Thanks

Roger

User avatar
Vassilis
Posts: 304
Joined: Thu May 21, 2015 6:42 am
Location: Thessaloniki, Greece
Contact:

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Vassilis » Fri Jun 03, 2016 5:27 am

Well, the code I wrote covers both maple mini and bluepill cases.

The first code

Code: Select all

#ifdef USB_DISC_PIN
  pinMode(USB_DISC_PIN, OUTPUT);
  digitalWrite(USB_DISC_PIN, HIGH);
   for(i=0;i<512;i++);
  digitalWrite(USB_DISC_PIN, LOW);
#else
is executed in case the USB_DISC_PIN is defined in chip.h file. In this case the maple mini DISC pin is used to re-enumerate (reset) the USB.

The second code

Code: Select all

#else
  pinMode(USBDP_PIN, OUTPUT);
  digitalWrite(USBDP_PIN, LOW);
   for(i=0;i<512;i++);
  digitalWrite(USBDP_PIN, HIGH);
#endif
is executed in case the USB_DISC_PIN is not defined in chip.h file. In this case the bluepill PA12 (USBDP) is used to re-enumerate (reset) the USB.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by RogerClark » Fri Jun 03, 2016 7:16 am

I think I have some other problem

I thought the sketch was being run by the bootloader after upload, but it looks like the bootloader has a problem with the sketch binary and it does not contain the correct code signature (or some problem like this)

I will need to revert the code in the repo, as I think something has gone badly wrong ;-(

User avatar
ekawahyu
Posts: 92
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by ekawahyu » Mon Jun 06, 2016 12:31 am

Guys, I got confused with the HAL between UART and USART. The STM32F103C8 clearly has USART1, 2, 3, but some function calls and callbacks are explicitly written separately as UART and USART. I configured USART1 as async and USART3 as sync. The generated code by the Cube:

Code: Select all

/* USART1 init function */
static void MX_USART1_UART_Init(void)
{

  huart1.Instance = USART1;
  huart1.Init.BaudRate = 38400;
  huart1.Init.WordLength = UART_WORDLENGTH_7B;
  huart1.Init.StopBits = UART_STOPBITS_1;
  huart1.Init.Parity = UART_PARITY_NONE;
  huart1.Init.Mode = UART_MODE_TX_RX;
  huart1.Init.HwFlowCtl = UART_HWCONTROL_NONE;
  huart1.Init.OverSampling = UART_OVERSAMPLING_16;
  huart1.Init.OneBitSampling = UART_ONE_BIT_SAMPLE_DISABLE;
  huart1.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;
  if (HAL_UART_Init(&huart1) != HAL_OK)
  {
    Error_Handler();
  }

}

/* USART3 init function */
static void MX_USART3_Init(void)
{

  husart3.Instance = USART3;
  husart3.Init.BaudRate = 38400;
  husart3.Init.WordLength = USART_WORDLENGTH_7B;
  husart3.Init.StopBits = USART_STOPBITS_1;
  husart3.Init.Parity = USART_PARITY_NONE;
  husart3.Init.Mode = USART_MODE_TX_RX;
  husart3.Init.CLKPolarity = USART_POLARITY_LOW;
  husart3.Init.CLKPhase = USART_PHASE_1EDGE;
  husart3.Init.CLKLastBit = USART_LASTBIT_DISABLE;
  if (HAL_USART_Init(&husart3) != HAL_OK)
  {
    Error_Handler();
  }

}
The init function in the main() always calls MX_USARTx_Init() no matter it is UART or USART. But the HAL, it calls HAL_UART_Init() for USART1 and HAL_USART_Init() for USART3. This is confusing to me, especially when it comes to separating the mapleX core. I can see that UARTClass.cpp is being used right now for all UART/USART, but what is the plan with the USARTClass.cpp in the core?

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by RogerClark » Mon Jun 06, 2016 12:39 am

The init function in the main() always calls MX_USARTx_Init() no matter it is UART or USART. But the HAL, it calls HAL_UART_Init() for USART1 and HAL_USART_Init() for USART3. This is confusing to me, especially when it comes to separating the mapleX core. I can see that UARTClass.cpp is being used right now for all UART/USART, but what is the plan with the USARTClass.cpp in the core?
I think this is the other way around, isnt it?

I thought the first 3 were USARTS and 4 and 5 are UARTS

Anyway...

In libmaple, they were all initially called the same name even though some were USARTs and some UARTs

For basic functionality it doesn't matter, as USARTs have UART functionality, but it is a problem for advanced functions.

In libmaple I think it just uses #ifdef's to call the appropriate setup code, depending on the device number.

So perhaps we can do the same.

This may not be the ideal or final solution, but this is such a small detail in the overall scale of the core, that perhaps we can do it with #ifdef's until we have a better picture potential problems on the other processor variants e.g the L versions and the F7 and F0 etc - which may be more different even than just USART vs UART

Ollie
Posts: 183
Joined: Thu Feb 25, 2016 7:27 pm

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by Ollie » Mon Jun 06, 2016 2:31 am

In some distributed systems, where dedicated serial lines are used between the central controller and the peripheral controllers, it would allow more robust design, when RTS/CTS wires are used to support the synchronization between the controllers.

In ideal case, the F103 library would have support for RTS/CTS and related interrupts. Even when they are available only with the first three serial devices.

User avatar
ekawahyu
Posts: 92
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by ekawahyu » Mon Jun 06, 2016 3:05 am

RogerClark wrote:I think this is the other way around, isnt it?

I thought the first 3 were USARTS and 4 and 5 are UARTS
Yeah, I thought the HAL_USART is only for USART peripherals, and HAL_UART only works for UART peripherals (like 4 & 5 in F072).

Anyway, I don't see any implementation in core USARTClass.cpp. So, we stick with UARTClass.cpp for now? I downloaded all HALs from F0-7, L0-4, they all have HAL_UART and HAL_USART, so I guess ST did a great job on portability (planning) among their chip.

User avatar
GrumpyOldPizza
Posts: 181
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by GrumpyOldPizza » Thu Jun 09, 2016 2:27 pm

ekawahyu wrote:
RogerClark wrote:I think this is the other way around, isnt it?

I thought the first 3 were USARTS and 4 and 5 are UARTS
Yeah, I thought the HAL_USART is only for USART peripherals, and HAL_UART only works for UART peripherals (like 4 & 5 in F072).

Anyway, I don't see any implementation in core USARTClass.cpp. So, we stick with UARTClass.cpp for now? I downloaded all HALs from F0-7, L0-4, they all have HAL_UART and HAL_USART, so I guess ST did a great job on portability (planning) among their chip.
USART is a superset of UART (and LPUART more or less). The difference between USART and UART is that the former can do something like SPI (TX == MOSI, RX == MISO, CK = SCK). So unless you intend to use the specific mode I suppose using the HAL_UART functions for all of them may be good enough.

zmemw16
Posts: 1369
Joined: Wed Jul 08, 2015 2:09 pm
Location: St Annes, Lancs,UK

Re: HALMX :: MXBluePillF103C8 Roadmap

Post by zmemw16 » Thu Jun 09, 2016 4:28 pm

istr reading that using a usart in a spi mode allows strange numbers of bits to be sent; e.g. 9 ?

stephen

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest