HALMX :: MXBluePillF103C8 Roadmap

Development of new Cores using the STMCubeMX and HAL
User avatar
ekawahyu
Posts: 87
Joined: Wed Apr 13, 2016 6:17 am

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby ekawahyu » Fri May 27, 2016 5:11 pm

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?

The new ring_buffer structure should look like this:

Code: Select all

struct ring_buffer{
      //uint8_t buffer[CDC_SERIAL_BUFFER_SIZE];
      uint8_t *buffer;
      volatile uint16_t iHead;
      volatile uint16_t iTail;
};


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.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby Vassilis » Fri May 27, 2016 5:23 pm

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?

Do your tests freely and we discuss your results later.


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.

The magic word "1EAF" is currently used by the stm32duino bootloader.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby ekawahyu » Sat May 28, 2016 7:34 am

Not so clean implementation but it works!

https://github.com/ekawahyu/HALMX_Arduino_STM32/commit/6ce7a0e98f19839135c3149c00fc6c3d850ba75d

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

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby Vassilis » Sat May 28, 2016 9:49 am

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


ekawahyu wrote:Not so clean implementation but it works!

https://github.com/ekawahyu/HALMX_Arduino_STM32/commit/6ce7a0e98f19839135c3149c00fc6c3d850ba75d

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

I need to read the changes you made.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby ekawahyu » Sat May 28, 2016 4:24 pm

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. :D

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

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby RogerClark » Sat May 28, 2016 4:42 pm

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

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby ekawahyu » Sat May 28, 2016 5:05 pm

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.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby RogerClark » Sat May 28, 2016 5:28 pm

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 )

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

Supporting Maple mini (and similar) USB reset hardware

Postby RogerClark » Thu Jun 02, 2016 1:49 am

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

Code: Select all

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



Note. Although I copied the Maple reset code from libmaple, it doesnt seem to be working with the HAL MAX core

RESETTING the disconnect pin, is supposed to cause transistor Q1 to stop conducting, which causes transistor Q2 to conduct and pull USB_DM to VCC

However this doesnt seem to be happening.

If I SET the pin instead, the USB bus is getting reset. So I wonder if this is something to do with the initial GPIO setup in the HAL MX, i.e are all GPIO outputs floating by default

umm.

Needs more work than I'd imagined to get this to work on the Maple mini.

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

Re: HALMX :: MXBluePillF103C8 Roadmap

Postby RogerClark » Thu Jun 02, 2016 6:35 am

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

Code: Select all

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


It looks like the Cube has generated code that won't compile, as although there are usages of hUsbDevice_0 in the auto generated files, It doesnt look like this variable is declared anywhere.

So, either the Cube has not correctly "migrated" the project file, or perhaps even a new project would not work (i.e some major bug in the Cube)


I've also noticed the latest version has added 3 new files into the MXBluePillF103C8 (i.e the variant I was looking at)

Drivers/STM32F1xx_Drivers/Src/stm32f1xx_hal_gpio_ex.c
Inc/spi.h
Src/spi.c


I think the problem overall is that, its going to be hard to update the core based on files from the cube, because it looks like its not capable of migrating existing projects correctly :-(

Unfortunately I don't have time, at the moment, to investigate whether re-creating a project from scratch would fix this issue. So I will revert my local files using Git


Return to “CubeMX and HAL”

Who is online

Users browsing this forum: No registered users and 1 guest