HALMX :: MXBluePillF103C8 Roadmap

ekawahyu wrote:I have both implementations of buffered TX and RX using the generated code by STM32CubeMX. I just increased the size of APP_TX_DATA_SIZE and APP_RX_DATA_SIZE from 4 to 128. Then I added the __io_putchar() and __io_getchar() to make it work with printf() and getchar(). I can try to point rx_buffer to use UserRxBufferFS and see if we can make it work the same way with tx_buffer. What do you think?

Not so clean implementation but it works!

https://github.com/ekawahyu/HALMX_Ardui … 3d850ba75d

Tested with fast auto-typing through AppleScript, everything seems fine. I also put a periodic CDC_Transmit for every 20 ms through SysTick callback.

ekawahyu wrote:As of magic word detection, we can read from the buffer instead. I chose to use ‘@boot’ instead of ‘1EAF’ for the magic word. You know, the chance of getting ‘1EAF’ as data is higher than ‘@boot” sequence.

I forgot to mention that the “1EAF” magic word it’s not just a plain 4-byte package. It is combined with the DTR signal that is sent from the IDE (maple_upload file).
So, it’s not important if the magic word is simple or not
Well, I have concern about ‘1EAF’ on STM32F072 Discovery because I am using the built-in system DFU and I wanted it to jump to system DFU by software instead of by pressing any button. No intervention whatsoever. So, it continuously listens to those USB Serial data stream for magic word. No DTR or any other reset mechanism available. The USB D+ even has built-in pull up resistor.

I am imagining that ‘1EAF’ would likely get captured from data stream than ‘@boot’. Maybe I am wrong, but it is at least 5 letters against 4, there is double characters in sequence, etc. I might probably need a magic sentence like “@aladin open sesame” instead of one word, just to be sure that is not part of data stream.

At least, it works for now. Look ma, no hands!

The 1EAF is a historical legacy thing from LeafLabs e.g because LEAF looks a bit like 1EAF

But I don’t see any way around getting the Serial code to listen for this sequence plus the DRT line

To change this code we’d need to rebuild all the upload tools. The main problem with this is the Windows “maple_upload” java, as we don’t have the original source for this utility, we only have a decompilation – and I’m not sure it recompiles

Considering no one has reported any issues with the existing 2 byte sequence, I don’t see a big problem with staying with it, and it pays homage to Leaflabs who kicked this all off in the first place

Ok, I can put 1EAF for STM32F072 Discovery until there is the need to replace it. For the moment, I am fine with it as well. Somebody has to come up with an open source solution for that java upload tool though.

@RogerClark: could explain a bit how this maple_loader.jar works on Windows? I am having a hard time to understand what those %1 %2 … parameters I need to pass to. I can see that it uses jSSC. I might be able to rewrite the code for it.

I think you’re referring to the params passed by the Arduino IDE to the “tools”

Look in bottom of platform.txt as I think those values are just passed by the commands in the tools section of platform.txt
(note some params are probably redundant e.g. possibly the USB VID PID stuff )

Supporting Maple mini (and similar) USB reset hardware needs a change to USBSerial.cpp which is in the common code of the core i.e HALMX/cores/mapleMX/USBSerial.cpp

I’m not sure the best way to do this and make it generic, but until someone can come up with a better idea

I’m going to define

USB_DISC_PORT

and

USB_DISC_PIN

Something like this

void USBSerial::init(void){

/* Re-enumerate the USB */
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

#if defined(USB_DISC_PORT)
GPIO_InitStruct.Pin = USB_DISC_PIN;

HAL_GPIO_Init(USB_DISC_PORT, &GPIO_InitStruct);

HAL_GPIO_WritePin(USB_DISC_PORT, USB_DISC_PIN, GPIO_PIN_RESET);
#else
GPIO_InitStruct.Pin = GPIO_PIN_12;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_RESET);
for(volatile unsigned int i=0;i<512;i++);
HAL_GPIO_WritePin(GPIOA, GPIO_PIN_12, GPIO_PIN_SET);
#endif

MX_USB_DEVICE_Init();
}

Yet another post about this core

I ran the Cube and it had updates, so I applied the updates, and the USB no longer compiles

HALMX_Arduino_STM32\HALMX\variants\MXBluePillF103C8\Src\usbd_cdc_if.c:143:24: error: 'hUsbDevice_0' undeclared (first use in this function)

@Roger

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

USBSerial.cppvoid 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();
}

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

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

The first code
#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

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 ;-(

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:

/* 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?

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

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.

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

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

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

stephen

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

stephen