Adding USB Serial

The official STMicroelectronics Arduino core
User avatar
RogerClark
Posts: 6130
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Adding USB Serial

Post by RogerClark » Wed Sep 28, 2016 9:47 pm

Hi Julie

I deleted my local repo containing Vassilis's code and copied in clean code from the cube ( albeit expoted using version 1.4.0 to be compatible with the HAL files originally added by Wi6Labs)

The code in the WIP branch compiles now, but the resultant binary does not run.

I dont like the way the USB code generates loads of warnings about casts from unit8 * to char *
As far as I could tell the warnings were harmless, but I wonder if this has been fixed in later versions of the F1 "firmware" packages that the Cube could use.


Re: Defines

I dont know whats normal for the HAL, so I had not noticed that wi6Labs seem to have done a bit of a mashup with defines from libmaple.

Those defines for MEDIUM DENSITY etc actually are a better construct than what the HAL uses, as it groups together a load of individual MCU model number, which conatain the same internal hardware.


I guess the thing we really need to do, is diff all the HAL files etc in the system folder, against a clean set generated from the Cube ( firmware 1.4.0)

So we know what modifications Wi6Labs did, as I suspect we will need to update to later versions of the Cube files sooner or later, as they already seem several revisions old ( I think some MCUs in the Cube are at 1.5.x)

User avatar
ddrown
Posts: 128
Joined: Sat Jan 09, 2016 4:49 am

Re: Adding USB Serial

Post by ddrown » Thu Sep 29, 2016 3:19 am

RogerClark wrote: I dont like the way the USB code generates loads of warnings about casts from unit8 * to char *
As far as I could tell the warnings were harmless, but I wonder if this has been fixed in later versions of the F1 "firmware" packages that the Cube could use.
Yeah, I ran into those warnings too when dealing with the HAL USB stack. My workaround was to force the castings. Not pretty but meh.

I also have a USB reset like how stm32duino does it for the HAL USB stack, so a MCU reboot causes the USB host to re-enumerate it. Would that code be useful?

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

Re: Adding USB Serial

Post by RogerClark » Thu Sep 29, 2016 4:14 am

Dan

Yes.

Can you post your code, or perhaps zip and upload

I looked at Vassilis's code, which he added to the HAL, but I was hoping that perhaps we could do this without modifying the files generated by the Cube, but I suspect thats not possible.

If possible could you take a look at the code in the WIP branch, as all I did was add the Middleware folder and the usb_xxx .c and .h files and it looks like this broke the stm32f103c library, as my blink test sketch no longer works on the BluePill after I added those files.

I think I'm going to need to run it in GDB and see if it gets and exception, so I can work out why adding unused source code causes it to crash (or at least not work)

User avatar
sheepdoll
Posts: 232
Joined: Fri May 22, 2015 12:58 am
Location: Silicon Valley Vortex
Contact:

Re: Adding USB Serial

Post by sheepdoll » Thu Sep 29, 2016 5:25 am

Hi Julie

I deleted my local repo containing Vassilis's code and copied in clean code from the cube ( albeit expoted using version 1.4.0 to be compatible with the HAL files originally added by Wi6Labs)

The code in the WIP branch compiles now, but the resultant binary does not run.

I dont like the way the USB code generates loads of warnings about casts from unit8 * to char *
As far as I could tell the warnings were harmless, but I wonder if this has been fixed in later versions of the F1 "firmware" packages that the Cube could use.
I have not seen the typecast warnings yet. May be the warn level I have the compiler set at.
Re: Defines

I dont know whats normal for the HAL, so I had not noticed that wi6Labs seem to have done a bit of a mashup with defines from libmaple.
ST seems to promote the Kiel tools. This is what you have to use in the seminar. The defines are created by the Cube tool for the given project builder and are specific to the IDE.
The defines come from the .ioc. There must be some sort of rule based exporter that creates them. The openSTM32 (AC6) does not seem to put them in an easy place for the makefile. They must be somewhere in the eclipse project.
I suspect any ST libraries would be generated using Kiel then linked to from the outside. I see that there is a makefile in the STM source branch this is a good place to look for the project setting used to build the lib. I think the two critical keys for HAL are -DSTM32F103RBTx and -DSTM32F1 both of which are in the .ioc.
Those defines for MEDIUM DENSITY etc actually are a better construct than what the HAL uses, as it groups together a load of individual MCU model number, which conatain the same internal hardware.
HAL handles this differently. I am not sure that the two are all that compatible. The way HAL works is to use #ifdef trees to include the needed headers. These in turn are processor specific. I have not looked much into the CMSIS sections. The due seems to call the ATMEL CMSIS directly from the core. Then they have the advantage as did the AVR of using a single chip package.
I guess the thing we really need to do, is diff all the HAL files etc in the system folder, against a clean set generated from the Cube ( firmware 1.4.0)

So we know what modifications Wi6Labs did, as I suspect we will need to update to later versions of the Cube files sooner or later, as they already seem several revisions old ( I think some MCUs in the Cube are at 1.5.x)
In my own experimental work I often regenerate the code using the Cube tool. I see that The F0 is up to 1.6. Looks like there is also an incremental upgrade to MX4.16.0 to MX4.16.1. I have not personally noticed much difference in the libs. At least as far as expanding the examples.

Cube is pretty good in respecting the user code comments. So if the file is modified, like main.c and the project regenerated, all the code in the user sections remain. I would hesitate to modify outside the user areas.

I keep meaning to use the old graphical windows windiff on the core directories. As noted elsewhere the pinmap global array is searched in the new ST stuff rather than indexed. I still want to automate the generation of this table. So far I have not found a good way to do so. The .ioc maps the set values. There are some places where there are multiple choices such as if a pin is configured pull-up pull-down etc.

In the case of maple and the mods Vasillis made fo my code, there is an attempt to attach the hardware timers and stuff for PWM pins. I have not looked at the new ST code to see how PWM is created. Same for the ADC.

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

Re: Adding USB Serial

Post by danieleff » Thu Sep 29, 2016 6:17 am

RogerClark wrote: ...
The code in the WIP branch compiles now, but the resultant binary does not run.
...
Might be because in platform.txt the compiler.libstm.c.flags references libstm32f1 headers, not libstm32f103c during arduino compilation. Just a guess.

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

Re: Adding USB Serial

Post by RogerClark » Thu Sep 29, 2016 9:20 am

Thanks Daniel

I'll try changing platform.txt and see if that fixes is it

User avatar
ddrown
Posts: 128
Joined: Sat Jan 09, 2016 4:49 am

Re: Adding USB Serial

Post by ddrown » Fri Sep 30, 2016 4:35 pm

RogerClark wrote:Dan

Yes.

Can you post your code, or perhaps zip and upload

I looked at Vassilis's code, which he added to the HAL, but I was hoping that perhaps we could do this without modifying the files generated by the Cube, but I suspect thats not possible.

If possible could you take a look at the code in the WIP branch, as all I did was add the Middleware folder and the usb_xxx .c and .h files and it looks like this broke the stm32f103c library, as my blink test sketch no longer works on the BluePill after I added those files.

I think I'm going to need to run it in GDB and see if it gets and exception, so I can work out why adding unused source code causes it to crash (or at least not work)
Yeah, I don't like changing these autogenerated files either, but I don't have a good solution for it.

usb-cast.patch - force the descriptor strings to be uint8_t pointers
usb-reset.patch - set PA12 to logic low to force a USB disconnect
Attachments
usb-reset.patch.txt
(1.21 KiB) Downloaded 15 times
usb-cast.patch.txt
(2.5 KiB) Downloaded 14 times

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

Re: Adding USB Serial

Post by RogerClark » Sat Oct 01, 2016 1:17 am

Thank Dan

I'll try patching those files some time over the weekend.

PS. I think Vassilis said he may have got the USB working; possibly he changed the include path stuff in platform.txt

But I know that he definitely recompiled with a new VECT TAB OFFSET of 0x2000 and was able to get the bootloader to jump to the STM Core code and for it to flash an LED on the BluePill

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

Re: Adding USB Serial

Post by Vassilis » Tue Oct 04, 2016 1:07 pm

I have been working on USBSerial in the last 2-3 days. So far, I have managed to make the F103C recognized as CDC from my PC.
Next step is to add the USBSerial library to the new core.

Stay tuned!

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

Re: Adding USB Serial

Post by RogerClark » Tue Oct 04, 2016 8:30 pm

Thanks Vassilis.

Appologies for not investigating this myself, but I have been looking at problems on the L476 core.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest