libopencm3-devel — Development mailing list.

[libopencm3-devel] stm32f4 + USB HS ULPI

[Vladislav T. <vtc...@gm...>]

Hello!

I'm adding support for USB HS with external PHY to stm32f4. I use stm32f446
and usb3300. I'm basing my code on usb_f207.c but configuring registers to
use external PHY. It looks that PHY is inited, and after init I run loop
with usbd_poll() like in cdcacm example. During it I see:

OTG_GINTSTS = 0x54000020
OTG_GOTGCTL = 0x030d0000

, while config registers:
OTG_GAHBCFG = 0x00000001
OTG_GUSBCFG = 0x40103c10
OTG_GRSTCTL = 0x8000000
OTG_GINTMSK = 0x80042810

and the host doesn't see the device and doesn't even try to enumerate. Can
somebody who was implementing USB give any advice on what to do?

My branch is here: https://github.com/vladtcvs/libopencm3/tree/usb-ulpi
-- 
Best regards
Vladislav Tsendrovskii

Re: [libopencm3-devel] SD card with STM32F1

[Chuck G. <tub...@ya...>]

On 1/10/23 01:40, Amitesh Singh wrote:
> Hi Bob,

> I would be interested in your written code related to reading sd card.
> Please share if it's possible for you.
> I've had fun with libopencm3/bluepill while
> making https://github.com/amitesh-singh/FASTUSBasp
> <https://github.com/amitesh-singh/FASTUSBasp>
> 

One huge difference (among others) between the stm32f4 and stm32f1
devices is that the F4 have an integrated SDIO controller, where the F1
devices do not.   On the F1, you're pretty much restricted to using SPI
to access the SDcard.

(I've written code for both families; (the F4 code done properly using
DMA is actually quite a bit more involved).

If you want to see my F4 code see the module "sdiosubs.c" on Github at
https://github.com/Tubatstuff/Pertec-Interface-Tape-Controller

If you want to see some F1, code, I'll have to rummage around a bit.

Cheers,
--Chuck

Re: [libopencm3-devel] SD card with STM32F1

[Amitesh S. <sin...@gm...>]

Hi Bob,

On Tue, Jan 3, 2023 at 7:55 PM Bob Dunlop <bob...@xy...> wrote:

> Hi,
>
> On Mon, Jan 02 at 02:23, Damien Maguire wrote:
> ...
> > have been struggling to find a good example of using a uSD card with a
> > 32F1 using libopencm3. Perhaps someone could point me in the right
> > direction?
>
> Useful sources for information on interfacing and initialising SDcards:
>   http://elm-chan.org/docs/mmc/mmc_e.html
>   http://elm-chan.org/docs/mmc/m/sdinit.png
>   http://www.cl.cam.ac.uk/teaching/1011/P31/lib/diskio.c
> None of them reference/use libopencm3 but still useful reading.
>
> I have code for STM32F401 libopencm3 that will take you from initialising
> GPIOs to reading sectors from the card and determining it's size.
> A couple of Blackpill cards are what I had spare for a project but no
> reason the codes shouldn't be easily ported to STM32F1, that's kinda
> the point of libopencm3.  Read only operation as that's all I need for
> my project, but sector write would be an easy addition.
>
> Don't have any FAT filesytem code as planning to use a readonly EXT2
> filesystem.  Because...
>
>
> I can email you the relevant files if you want.  I have my own some
> would concider crankey style and it's not ready for public distribution,
> but it's well commented in my opinion, compiles and runs.
>
>
I would be interested in your written code related to reading sd card.
Please share if it's possible for you.
I've had fun with libopencm3/bluepill while making
https://github.com/amitesh-singh/FASTUSBasp

Thanks,
Amitesh


> --
>         Bob Dunlop
>
>
> _______________________________________________
> libopencm3-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>

Re: [libopencm3-devel] SD card with STM32F1

[Bob D. <bob...@xy...>]

Hi,

On Mon, Jan 02 at 02:23, Damien Maguire wrote:
...
> have been struggling to find a good example of using a uSD card with a 
> 32F1 using libopencm3. Perhaps someone could point me in the right 
> direction?

Useful sources for information on interfacing and initialising SDcards:
  http://elm-chan.org/docs/mmc/mmc_e.html
  http://elm-chan.org/docs/mmc/m/sdinit.png
  http://www.cl.cam.ac.uk/teaching/1011/P31/lib/diskio.c
None of them reference/use libopencm3 but still useful reading.

I have code for STM32F401 libopencm3 that will take you from initialising
GPIOs to reading sectors from the card and determining it's size.
A couple of Blackpill cards are what I had spare for a project but no
reason the codes shouldn't be easily ported to STM32F1, that's kinda
the point of libopencm3.  Read only operation as that's all I need for
my project, but sector write would be an easy addition.

Don't have any FAT filesytem code as planning to use a readonly EXT2
filesystem.  Because...


I can email you the relevant files if you want.  I have my own some
would concider crankey style and it's not ready for public distribution,
but it's well commented in my opinion, compiles and runs.

-- 
        Bob Dunlop

Re: [libopencm3-devel] SD card with STM32F1

[Amitesh S. <sin...@gm...>]

Hi,

You could refer to this project.
https://github.com/dilshan/sdfatlib

Regards,
Amitesh


On Mon, Jan 2, 2023 at 7:53 PM Damien Maguire <lis...@gm...> wrote:

> Hi,
>
> New to the list and apologies for asking for help with my first email. I
> have been struggling to find a good example of using a uSD card with a
> 32F1 using libopencm3. Perhaps someone could point me in the right
> direction?
>
> many thanks,
>
> Damien
>
>
>
>
> _______________________________________________
> libopencm3-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>

[libopencm3-devel] SD card with STM32F1

[Damien M. <lis...@gm...>]

Hi,

New to the list and apologies for asking for help with my first email. I 
have been struggling to find a good example of using a uSD card with a 
32F1 using libopencm3. Perhaps someone could point me in the right 
direction?

many thanks,

Damien

Re: [libopencm3-devel] Audio Function

[Eléaz v. d. T. <ele...@ho...>]

Hey Stephen,

Thanks, I was focussing too much on STM32 in my searches, therefore didn’t came across that one.

Kind Regards,
Eleaz


> Op 28 sep. 2022, om 02:43 heeft Stephen Holdaway <st...@st...> het volgende geschreven:
> 
> Hi Eleaz,
> 
> A search for "opencm3 usb audio" found this complete example pretty quickly:
> 
> https://github.com/im-tomu/tomu-quickstart/blob/master/usb-audiostream/usb_audio.c
> 
> Good luck!
> 
> Cheers,
> Stephen
> 
> On Wed, Sep 28, 2022 at 1:39 AM Eléaz van der Toorn <ele...@ho... <mailto:ele...@ho...>> wrote:
>> Dear Sir/Madame,
>> 
>> I started using libopencm3 a few moths ago, it really is great.
>> Created a Midi Keyboard Controller with it and a few other small boards.
>> 
>> Currently I am using it to create a driver board for a speaker.
>> I ran in some problems, with the device descriptor. It’s simply not working.
>> It does not allow me to create a zero-bandwidth interface with bAlternateSetting 0x00 and a second interface with an endpoint, and a format-type descriptor with bAlternateSetting 0x01.
>> 
>> I couldn’t find an example of an Audio Function. But if someone knows of one, or has one which can be shared, it would help me a lot.
>> 
>> If someone wants to see my code, to help me with that, I will upload it.
>> 
>> Kind Regards,
>> Eleaz
>> 
>> 
>> 
>> _______________________________________________
>> libopencm3-devel mailing list
>> lib...@li... <mailto:lib...@li...>
>> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel

Re: [libopencm3-devel] Audio Function

[Stephen H. <st...@st...>]

Hi Eleaz,

A search for "opencm3 usb audio" found this complete example pretty quickly:

https://github.com/im-tomu/tomu-quickstart/blob/master/usb-audiostream/usb_audio.c

Good luck!

Cheers,
Stephen

On Wed, Sep 28, 2022 at 1:39 AM Eléaz van der Toorn <
ele...@ho...> wrote:

> Dear Sir/Madame,
>
> I started using libopencm3 a few moths ago, it really is great.
> Created a Midi Keyboard Controller with it and a few other small boards.
>
> Currently I am using it to create a driver board for a speaker.
> I ran in some problems, with the device descriptor. It’s simply not
> working.
> It does not allow me to create a zero-bandwidth interface with
> bAlternateSetting 0x00 and a second interface with an endpoint, and a
> format-type descriptor with bAlternateSetting 0x01.
>
> I couldn’t find an example of an Audio Function. But if someone knows of
> one, or has one which can be shared, it would help me a lot.
>
> If someone wants to see my code, to help me with that, I will upload it.
>
> Kind Regards,
> Eleaz
>
>
>
> _______________________________________________
> libopencm3-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel
>

[libopencm3-devel] Audio Function

[Eléaz v. d. T. <ele...@ho...>]

Dear Sir/Madame,

I started using libopencm3 a few moths ago, it really is great.
Created a Midi Keyboard Controller with it and a few other small boards.

Currently I am using it to create a driver board for a speaker.
I ran in some problems, with the device descriptor. It’s simply not working.
It does not allow me to create a zero-bandwidth interface with bAlternateSetting 0x00 and a second interface with an endpoint, and a format-type descriptor with bAlternateSetting 0x01.

I couldn’t find an example of an Audio Function. But if someone knows of one, or has one which can be shared, it would help me a lot.

If someone wants to see my code, to help me with that, I will upload it.

Kind Regards,
Eleaz

[libopencm3-devel] SAMD support?

[Chris C. <chr...@gm...>]

Hello list,

What is the status of SAMD support? I am working with an ATSAMD09C13A, and I
got blinky working <https://github.com/InterstitialTech/seismobot-firmware>;
now I am interested in using the USART. There is a libopencm3/sam/usart.h
<https://github.com/libopencm3/libopencm3/blob/master/include/libopencm3/sam/usart.h>,
but no definitions for USART0_BASE, etc. I figured out that they're called
SERCOM0, etc in libopencm3/sam/d/memorymap.h
<https://github.com/libopencm3/libopencm3/blob/master/include/libopencm3/sam/d/memorymap.h>,
but even with this re-mapping I am running into errors.

Does anyone have an example of USART working on SAMD?

_chris

Re: [libopencm3-devel] GD32VF103 support (RISC-V) #1234

[Karl P. <ka...@tw...>]

I believe I've mentioned it on IRC, but if it needs it here too,
sure..

I, personally, won't be dealing with any extra architectures.
It's already far too much hassle (for me), and spending yet more
time on more architectures for an LGPL project isn't number one
on my personal list of things to do.

Specifically, gd32v is about the only one that has any overlap
with libopencm3 and only because of _its_ heritage with gd32.
~none of the other riscv parts would have anything in common to
even understand the appeal of trying to leverage into a cortex-m
project. From what I've seen, the gigadevices vendor sdk is
actualyl pretty nice anyway, and very "inspired" by libopencm3 as
it is. it seems like a lot of work to get some pretty thin apis
from libopencm3, that we then always have to carry.

However, that's just me, I'm only one committer. Feel free to
reach out to any others. Last I checked there were ~6, plus the
repo owner.

As for the list itself, it is _very_ low traffic, and not
generally a method of communication that anyone uses much.

Sincerely,
Karl Palsson


Lubomir Rintel <lku...@v3...> wrote:
> Hi,
> 
> Another month, another ping about the GD32VF103 support:
> https://github.com/libopencm3/libopencm3/pull/1234
> 
> The lack of response makes me a little worried; is this project
> and the mailing list still active? Am I using the right
> channels to submit my patch set?
> 
> I'd definitely appreciate a "fix this to get your patches
> merged" or "go away, we're not interested" response from
> whoever is in the position to accept or reject submissions.
> 
> I got a response from Filip indicating that there's some
> interest; strangely I can not see it in the archives on sf.net,
> despite it was Cc'd to the list. Actually, there's worryingly
> little content in the archives. Is this the correct list?
> 
> Thanks,
> Lubo

[libopencm3-devel] GD32VF103 support (RISC-V) #1234

[Lubomir R. <lku...@v3...>]

Hi,

Another month, another ping about the GD32VF103 support:
https://github.com/libopencm3/libopencm3/pull/1234

The lack of response makes me a little worried; is this project and the
mailing list still active? Am I using the right channels to submit my
patch set?

I'd definitely appreciate a "fix this to get your patches merged" or "go
away, we're not interested" response from whoever is in the position
to accept or reject submissions.

I got a response from Filip indicating that there's some interest;
strangely I can not see it in the archives on sf.net, despite it was Cc'd
to the list. Actually, there's worryingly little content in the archives.
Is this the correct list?

Thanks,
Lubo

Re: [libopencm3-devel] STM32 F1 -> F3 development

[Karl P. <ka...@tw...>]

Rico <bo...@cr...> wrote:
> Hi List.
> 
> I started developing for the STM32F103C8T6 based on the
> "Beginning STM32" book
> https://www.apress.com/gp/book/9781484236239 Using the regular
> "blue pill", as well as the RobotDyn "black pill" as hadware
> basis and all was well.

I'd personally be wary of a book whos code repo has had ~zero
changes, but I've not looked at this book itself. There was an
earlier book that I didn't think much of, but hopefully this one
is better :)

I'd also like to make clear up front that "regular blue pill" is
a horrible name, as these are made by various companies, with
various parts, and various hardware errors. It's "cheap" but only
if you don't value your time. (nor the time of anyone else
helping you) You can get Nucleo 64 boards with reputable hardware
for very little more, and if you need the form factor, Nucleo32
boards are available as well. You'll get actual documentation,
schematics and reliable assembly.

> 
> Then I got the idea to carefully step up my game by using a
> STM32F303CCT6. Hardware migration promised (and proved) to be
> very seamless, using also a F303 "black pill" with even pin
> compatible layout and the only difference there being basically
> BOOT1/PB2 - see:
> 
> https://www.st.com/resource/en/application_note/dm00073522-migrating-from-stm32f1-series-to-stm32f3-series-microcontrollers-stmicroelectronics.pdf


Please do note page 11 in that document, the number of
peripherals that say "partial compatibility" or even "new
peripheral"

> 
> I thought I could start writing somewhat device independent
> code. Well
> ... code that should run on both the STM32F103 and STM32F303.
> However, I'm hitting quite a few walls with libopencm3 there.
> It seems there are particular inconsistencies for libopencm3
> for these two families where I had actually hoped they would be
> "almost the same".
> 
> I still haven't the amount of insight I'd like to have in the
> libopencm3 code base, but to my defense I have to say it
> doesn't make it easy.
> 
> https://github.com/libopencm3/libopencm3/commit/ebb058825f356474aa5cefa3b3e71b5f18cc670c
> ("[STM32F3] Removed all specific F3 stuff out of common
> files.")
> 
> And there you see the code being moved to e.g.
> ...common_f0124.h 

I'm impressed? that you picked out an 8 year old commit, but
you've missed all it's context. That was part of work designed to
_increase_ the portability of code, to handle the two different
SPI peripherals. The "f3" code is actually "SPI peripheral
version 2" code and eventually landed into
https://github.com/libopencm3/libopencm3/blob/master/lib/stm32/common/spi_common_v2.c
but anyway...

> So why exactly is "3" omitted from the common
> stuff, when it is supposed to be THE migration path for F1
> devices? 
> Maybe they are so similar I could simply continue use
> the F1 files? Nope
> - that messes up way more one is willing to fix.
> 
> Why are there such inconsistencies even in the register naming?
> 
> e.g.
> 
> F1/NVIC
> 
> #define NVIC_USART1_IRQ 37
> #define NVIC_USART2_IRQ 38
> #define NVIC_USART3_IRQ 39


We chose to use the naming as provided in the reference manuals.
Unfortunately these are not always consistent. ST's CMSIS packs
simply _ignore_ this, and do provide "compatible" headers...

f1:
USART1_IRQn = 37, /*!< USART1 global Interrupt */ f3: USART1_IRQn
= 37, /*!< USART1 global Interrupt & EXTI Line25 Interrupt
(USART1 wakeup) */ (From
https://github.com/STMicroelectronics/STM32CubeF1/blob/master/Drivers/CMSIS/Device/ST/STM32F1xx/Include/stm32f103xb.h
and
https://github.com/STMicroelectronics/STM32CubeF3/blob/master/Drivers/CMSIS/Device/ST/STM32F3xx/Include/stm32f303xc.h)


> 
> then you try to compile your code for F3 and after this gets
> thrown at you
> 
> 
> src/uartlib.c:42:24: error: 'NVIC_USART1_IRQ' undeclared here
> (not in a function); did you mean 'NVIC_USB_HP_IRQ'?
>     42 |  { USART1, RCC_USART1, NVIC_USART1_IRQ, uart1_getc, uart1_putc 
> },
>        |                        ^~~~~~~~~~~~~~~
>        |                        NVIC_USB_HP_IRQ
> src/uartlib.c:43:24: error: 'NVIC_USART2_IRQ' undeclared here
> (not in a function); did you mean 'NVIC_SPI2_IRQ'?
>     43 |  { USART2, RCC_USART2, NVIC_USART2_IRQ, uart2_getc, uart2_putc 
> },
>        |                        ^~~~~~~~~~~~~~~
>        |                        NVIC_SPI2_IRQ
> src/uartlib.c:44:24: error: 'NVIC_USART3_IRQ' undeclared here
> (not in a function); did you mean 'NVIC_USB_HP_IRQ'?
>     44 |  { USART3, RCC_USART3, NVIC_USART3_IRQ, uart3_getc, uart3_putc }
>        |                        ^~~~~~~~~~~~~~~
> 
> 
> you find out that for F3 it is (observe the "did you mean")
> 
> #define NVIC_USART1_EXTI25_IRQ 37
> #define NVIC_USART2_EXTI26_IRQ 38
> #define NVIC_USART3_EXTI28_IRQ 39
> 
> :-P Uh.
> 
> So - what am I doing wrong in using libopencm3 or does it
> really need some streamlining between F1 and F3 family?

Yes and no. libopencm3 isn't, wasn't, and doesn't really plan on
offering a single HAL. It certainly does try to use the same APIs
where reasonable and possible, and work does get done unifying
things where obvious pain points exist. Other places are simply
not reasonable or feasible. It's extremely tedious work,
reviewing cross family datasheets and reference manuals to clean
up unified code without omitting features added. Especially
within the STM32 targets, we try and use the same APIs as much as
possible. (Do note that there are other targets than STM32 in the
project)

In the specific case of F3, the code style of the original
submission proved rather awkward, with a lot more copying and
editing and less adherence to existing styles than would have
been desirable. It was brought in before most of the ideas of
"peripheral vN" existed, as there were only a couple of ST parts
available, and they were all different. This peripheral
versioning became much more obvious and intuitive later, as more
parts came out, but not all code has been cleaned or de-duped.

In general, within the STM32 environment, these are the places
where you _will_ need to make target specific code:

## clock setup
Most targets use a clock structure, but even the clock structure
will be different, as there are many different clock trees. F1
uses a slew of copy/pasted static routines, and should eventually
be replaced with similar structure routines for consistency, but
it's the "original" so it stays for now.

## GPIO setup
really, this is just "F1" style, vs "every one else" style. The
peripherals are completely different, and it's definitely the
biggest pain point, as it's something you hit so _easily_. On the
bright side, it's also a very simple peripheral, so it's normally
straightforward to fix. Making a layer above this might be
viable, but it's only for the pin setup, not the pin operations,
so it's normally just been put in people's target specific code
anyway, and if anything, has driven people to "do the right
thing" a little earlier in their process than they might have
done otherwise.... I don't dispute that this isn't a sharp edge
of course :)

## IRQs
ST does a _pretty_ good job of these, but they do change names.
We chose to stick quite hard to the names of the vectors in the
reference manual. [1] For instance, in your specific case:

F1 RM extract: https://bin.jvnv.net/file/UMxdb.png
F3 RM extract: https://bin.jvnv.net/file/ciFWw.png

To ease porting from CMSIS sw, it may have been easier to use the CMSIS names, but also note that when this project was started, the CMSIS headers weren't licensed in a way that allowed free re-use.  

Beyond these portions, you mostly only need to consider the
peripheral version you are targetting. Basic stuff should be the
same. ST's "Migrating from X to Y" docs are pretty good at
explaining the differences.

Hope this helps give you some context at least, though it does
nothing to make your code compile I'm afraid :)

Sincerely,
Karl Palsson

[1] I'm cheating a little bit, but, it's relevant. The F1 extract
is from RM0008 rev 15, but the F3 extract is from RM0316 rev 1.
(Which is when the f3 vector names were written) In RM0316 rev 5,
(or somewhere in between) the vector names have been changed
again. Providing aliases would be a "good thing" here, but the
current code generation doesn't support that. I've filed a ticket
to track this if anyone's bored and wants to work on it:
https://github.com/libopencm3/libopencm3/issues/1342

Re: [libopencm3-devel] STM32 F1 -> F3 development

[Uwe B. <bo...@el...>]

Rico writes:
> Hi List.
> 
> I started developing for the STM32F103C8T6 based on the "Beginning 
> STM32" book https://www.apress.com/gp/book/9781484236239
> Using the regular "blue pill", as well as the RobotDyn "black pill" as 
> hadware basis and all was well.
> 
Hello,

the blckmgaic probe firmware can be compiled for different chips,
e.g. STM32 F1 and
F4. https://github.com/UweBonnes/blackmagic/tree/f3_if adds
F3. Perhaps have a look at what is different and what is similar.

Bye
-- 
Uwe Bonnes                bo...@el...

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
(Phone also available during "mobile work")

[libopencm3-devel] STM32 F1 -> F3 development

[Rico <bo...@cr...>]

Hi List.

I started developing for the STM32F103C8T6 based on the "Beginning 
STM32" book https://www.apress.com/gp/book/9781484236239
Using the regular "blue pill", as well as the RobotDyn "black pill" as 
hadware basis and all was well.

Then I got the idea to carefully step up my game by using a 
STM32F303CCT6.
Hardware migration promised (and proved) to be very seamless, using also 
a F303 "black pill" with even pin compatible layout
and the only difference there being basically BOOT1/PB2 - see:

https://www.st.com/resource/en/application_note/dm00073522-migrating-from-stm32f1-series-to-stm32f3-series-microcontrollers-stmicroelectronics.pdf

I thought I could start writing somewhat device independent code. Well 
... code that should run on both the STM32F103 and STM32F303.
However, I'm hitting quite a few walls with libopencm3 there. It seems 
there are particular inconsistencies for libopencm3 for these
two families where I had actually hoped they would be "almost the same".

I still haven't the amount of insight I'd like to have in the libopencm3 
code base, but to my defense I have to say it doesn't make it easy.

https://github.com/libopencm3/libopencm3/commit/ebb058825f356474aa5cefa3b3e71b5f18cc670c
("[STM32F3] Removed all specific F3 stuff out of common files.")

And there you see the code being moved to e.g. ...common_f0124.h
So why exactly is "3" omitted from the common stuff, when it is supposed 
to be THE migration path for F1 devices?
Maybe they are so similar I could simply continue use the F1 files? Nope 
- that messes up way more one is willing to fix.

Why are there such inconsistencies even in the register naming?

e.g.

F1/NVIC

#define NVIC_USART1_IRQ 37
#define NVIC_USART2_IRQ 38
#define NVIC_USART3_IRQ 39

then you try to compile your code for F3 and after this gets thrown at 
you


src/uartlib.c:42:24: error: 'NVIC_USART1_IRQ' undeclared here (not in a 
function); did you mean 'NVIC_USB_HP_IRQ'?
    42 |  { USART1, RCC_USART1, NVIC_USART1_IRQ, uart1_getc, uart1_putc 
},
       |                        ^~~~~~~~~~~~~~~
       |                        NVIC_USB_HP_IRQ
src/uartlib.c:43:24: error: 'NVIC_USART2_IRQ' undeclared here (not in a 
function); did you mean 'NVIC_SPI2_IRQ'?
    43 |  { USART2, RCC_USART2, NVIC_USART2_IRQ, uart2_getc, uart2_putc 
},
       |                        ^~~~~~~~~~~~~~~
       |                        NVIC_SPI2_IRQ
src/uartlib.c:44:24: error: 'NVIC_USART3_IRQ' undeclared here (not in a 
function); did you mean 'NVIC_USB_HP_IRQ'?
    44 |  { USART3, RCC_USART3, NVIC_USART3_IRQ, uart3_getc, uart3_putc }
       |                        ^~~~~~~~~~~~~~~


you find out that for F3 it is (observe the "did you mean")

#define NVIC_USART1_EXTI25_IRQ 37
#define NVIC_USART2_EXTI26_IRQ 38
#define NVIC_USART3_EXTI28_IRQ 39

:-P Uh.

So - what am I doing wrong in using libopencm3 or does it really need 
some streamlining between F1 and F3 family?



regards,
-- 
Rico

Re: [libopencm3-devel] Exampels for STM32F401RE

[<ka...@as...>]

Göran Hasse:
> I have a STM32F401RE nucleo board. Is there any examples for this board?

Not exactly what you are looking for, but try:
 https://github.com/libopencm3/libopencm3-examples

Perhaps you can ask the author of this mail:
 https://sourceforge.net/p/libopencm3/mailman/message/32566954/

Regards,
/Karl Hammar

[libopencm3-devel] Exampels for STM32F401RE

[G H. <go...@ra...>]

I have a STM32F401RE nucleo board. Is there any examples for this board?

// GH

-- 
Göran Hasse
Raditex Control AB
Boo 229, 715 91 ODENSBACKEN
tel: 070 5530148
mail: go...@ra...

[libopencm3-devel] i2c v2 omission and possible fix

[Valentijn S. <val...@se...>]

Hi list,

While working on an stm32f030 i²C application, it took some time to get 
slave mode to work.

As far as I can see from the reference manual from a V1 part 
(stm32f101XX et al), the i2c-v1 immediately starts receiving as soon as 
its' OAR1 address is matched; however, it may refrain from sending an 
ACK if the i2C_CR1 "ACK" bit is not set. Hence, a "i2c_enable_ack()" 
function starts slave reception and i2c_disable_ack() stops it.

The i2c-v2 chips have an "OA1EN: Own Address 1 enable" bit to enable or 
disable ACKing the slave address. This bit does have a definition in 
i2c_common_v2.h (I2C_OAR1_OA1EN_DISABLE and ..._ENABLE), but there is no 
"I2C_OAR1(I2C1) |= I2C_OAR1_OA1EN_ENABLE" in the v2 code. This 
effectively makes the slave in v2 inoperable.

Judging from the v1 code, a proper way to set this up would be to just 
add the "i2c_enable_ack()" and "i2c_disable_ack()" calls to the v2 code, 
changing these calls to implement I2C_OAR1(I2C1) |= 
I2C_OAR1_OA1EN_ENABLE. Additionally, the documentation states that 
several bits "can be written only when OA1EN=0"; I think this should be 
reflected in the functions' documentation? (Another way of doing this 
would be to add calls to disable OA1EN and re-enable it afterwards, 
which sounds like too much overhead to me, but I could be wrong).

Apart from that, a subtle difference between v1 and v2 is then (as far 
as I understand from the reference manual), that v2 distinguishes 
between call address and bytes received, i.e. there is a separate "NACK 
generation" bit in I2C_CR2 to be able to NACK individual bytes received 
- but as the I2C API doesn't implement this sort of subtle ACK/NACK 
meddling, I think we could leave this out.

Should I write a patch?

Best regards,

Valentijn

Re: [libopencm3-devel] Suitability of libopencm3 for Cortex-M7 MCUs?

[Karl P. <ka...@tw...>]

Chuck Guzis <tub...@ya...> wrote:
> 
> 
> On 8/18/20 6:52 AM, Karl Palsson wrote:
> > 
> > A lot of it is waiting in pull requests, and largely just needs
> > time to review and merge. The bulk of the peripherals are the
> > same, and just need to be added to the makefiles. Given that
> > there have been pull requests from multiple sources for f7, I
> > think it's as used as anything else, but there's ~zero usage data
> > in general.
> > 
> > Right this instant, yes, it's less complete than f4 though.
> 
> Would anyone mind if I completed some of the omissions for F7
> from the F4 library and submitted them?
> 
No, go for it.

Re: [libopencm3-devel] Suitability of libopencm3 for Cortex-M7 MCUs?

[Chuck G. <tub...@ya...>]

On 8/18/20 6:52 AM, Karl Palsson wrote:
> 
> A lot of it is waiting in pull requests, and largely just needs
> time to review and merge. The bulk of the peripherals are the
> same, and just need to be added to the makefiles. Given that
> there have been pull requests from multiple sources for f7, I
> think it's as used as anything else, but there's ~zero usage data
> in general.
> 
> Right this instant, yes, it's less complete than f4 though.

Would anyone mind if I completed some of the omissions for F7 from the
F4 library and submitted them?

This might be the best way to go for me, at least.

--Chuck

Re: [libopencm3-devel] Suitability of libopencm3 for Cortex-M7 MCUs?

[Karl P. <ka...@tw...>]

A lot of it is waiting in pull requests, and largely just needs
time to review and merge. The bulk of the peripherals are the
same, and just need to be added to the makefiles. Given that
there have been pull requests from multiple sources for f7, I
think it's as used as anything else, but there's ~zero usage data
in general.

Right this instant, yes, it's less complete than f4 though.

Sincerely,
Karl P


Chuck Guzis via libopencm3-devel
<lib...@li...> wrote:
> I've been doing some projects on the STM32F4 using both SPL and
> Libopencm3 suites. I'm currently working on migrating my F4
> projects to STM32F7 platforms.
> 
> My initial attempt was somewhat disappointing. For example, I
> note that rtc (.h and library routines) are completely absent.
> Were it for just this one aspect, I'd have no problem adapting
> the F4 versions to F7. However, the obvious lack has me
> wondering if anyone is using libopencm3 for F7 development--and
> particularly the reliability of the F7 code base.
> 
> Given that STM has stated that it has no plans to extend the
> old SPL to F7 devices, that pretty much leaves CubeMX as the
> only open-source development library. (HAL on F7 would be a
> mess to maintain).
> 
> Is my thinking correct--or am I overlooking something?
> 
> Thanks for any suggestions/input.
> 
> Chuck
> Sydex, Inc.
> 
> 
> _______________________________________________
> libopencm3-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel

[libopencm3-devel] Suitability of libopencm3 for Cortex-M7 MCUs?

[Chuck G. <tub...@ya...>]

I've been doing some projects on the STM32F4 using both SPL and
Libopencm3 suites.  I'm currently working on migrating my F4 projects to
STM32F7 platforms.

My initial attempt was somewhat disappointing.  For example, I note that
rtc (.h and library routines) are completely absent.   Were it for just
this one aspect, I'd have no problem adapting the F4 versions to F7.
However, the obvious lack has me wondering if anyone is using libopencm3
for F7 development--and particularly the reliability of the F7 code base.

Given that STM has stated that it has no plans to extend the old SPL to
F7 devices, that pretty much leaves CubeMX as the only open-source
development library.  (HAL on F7 would be a mess to maintain).

Is my thinking correct--or am I overlooking something?

Thanks for any suggestions/input.

Chuck
Sydex, Inc.

Re: [libopencm3-devel] Question of STM32 F1 DFU example code

[Karl P. <ka...@tw...>]

Sure, seems redundant. It might not have been redundant when it
was written, that demo is..... very old. You can also register
all sorts of filters and list the same callback, so you _may_
wish to be checking things there, perhaps consider it an example
of how you can still access those fields? ;)

Writing nice doxygen for the usb sections would be awesome yes.

Sincerely,
Karl Palsson


Mats Webjörn/WIKAB  <ko...@we...> wrote:
> Hi,
> 
> I have a question on
> libopencm3-examples\examples\stm32\f1\lisa-m-1\usb_hid\usbhid.c
> .
> 
> It defines
> 
> static enum usbd_request_return_codes dfu_control_request(
> usbd_device *dev, struct usb_setup_data *req, uint8_t **buf,
> uint16_t *len,
>           void (**complete)(usbd_device *dev, struct usb_setup_data *req))
> {
>           (void)buf;
>           (void)len;
>           (void)dev;
> 
>           if ((req->bmRequestType != 0x21) || (req->bRequest != DFU_DETACH))
>                     return USBD_REQ_NOTSUPP; /* Only accept class request. */
> 
>           *complete = dfu_detach_complete;
> 
>           return USBD_REQ_HANDLED;
> }
> 
> Which is registered in USBD using
> 
> usbd_register_control_callback(
> dev,
> USB_REQ_TYPE_CLASS | USB_REQ_TYPE_INTERFACE,
>           USB_REQ_TYPE_TYPE | USB_REQ_TYPE_RECIPIENT,
>           dfu_control_request);
> 
> My question is, why does dfu_control_request() check
> bmRequestType with
> 
> "if ((req->bmRequestType != 0x21)" ?
> 
> 
> usb_control_request_dispatch() filters requests on the
> registered request-type using
> 
>           "if ((req->bmRequestType & cb[i].type_mask) == cb[i].type)"
> 
> So the check in dfu_control_request() is redundant and just
> confusing for the reader.
> 
> It would be nice if the callback typedefs in
> libopencm3/include/libopencm3/usb/usbd.h Had the same kind of
> doxygen declaration as the other functions. This would most
> Likely eliminate these kind of misunderstandings of what the
> presumptions of the callback was.
> 
> Kind regards
> 
> Mats Webjörn
> 
> Tel +46 8 584 238 80 Webjörn IngenjörsKonsult AB Mobil +46 70
> 639 16 99 Solhemsbackarna 75A
>                               SE-163 56 SPÅNGA
>                               Sweden
> 
> _______________________________________________
> libopencm3-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libopencm3-devel

Re: [libopencm3-devel] I2C on STM32L1?

[<xuy...@sy...>]

Hi everyone，


  I usually have got your e-mail, why?
  

  I don't want to got your e-mail any more, how should I do?


  Tell me how to do please! Thank you very much, I would very please for that.

 
 
------------------ Original ------------------
From: &nbsp;"Chris Chronopoulos"<chr...@gm...&gt;;
Date: &nbsp;Mon, Aug 3, 2020 10:00 AM
To: &nbsp;"Karl Palsson"<ka...@tw...&gt;; 
Cc: &nbsp;"libopencm3-devel"<lib...@li...&gt;; 
Subject: &nbsp;Re: [libopencm3-devel] I2C on STM32L1?

&nbsp;

Thank you! That helped me get up and running. There were two things I was missing. First, the call to&nbsp;gpio_set_output_options() with GPIO_OTYPE_OD appears to be critical; it's not sufficient to put this in gpio_mode_setup(). Second, with GPIO_OTYPE_OD, apparently I need to use&nbsp;i2c_set_speed(), instead of i2c_set_clock_frequency() and/or i2c_set_fast/standard_mode().

After that, my address write received ACK. But I still was not able to use i2c_send_data(); this apparently did nothing. However, using i2c_transfer7() as you suggested, worked fine. So I am good for now (albeit a little confused about the old/low-level interface versus the new one..).


Would it be helpful for me to submit a working L1 I2C example for&nbsp;libopencm3-examples?


_chris






On Sun, Aug 2, 2020 at 10:24 AM Karl Palsson <ka...@tw...&gt; wrote:


 https://github.com/karlp/libopencm3-tests/tree/master/tests/i2c-master
 is the code I wrote while developing the "standard" api. (You
 shouldn't really have to know about the v1/v2 differences, for
 the most part...) Those "set_fast_mode" and "set_standard_mode"
 are part of the original very low level apis. you (probably) want
 something more like:
 
 https://github.com/karlp/libopencm3-tests/blob/master/tests/i2c-master/i2c-master.c#L29-L38
 (i2c_set_speed() and then just i2c_transfer7()
 
 The main-<hardware&gt; have the onnly board specfic setup required,
 normally setting up clocks and gpio modes.
 
 There's a couple of issues reported with i2c as well:
 https://github.com/libopencm3/libopencm3/pulls?q=is%3Apr+is%3Aopen+i2c
 that _may_ be relevant to you, or at least to bear in mind.
 
 
 Chris Chronopoulos <chr...@gm...&gt; wrote:
 &gt; Hmm, well update - I figured out that I was missing the
 &gt; following line:
 &gt; 
 &gt;&nbsp; &nbsp; &nbsp;rcc_periph_clock_enable(RCC_GPIOB);
 &gt; 
 &gt; before my GPIO setup calls. Makes sense. The thing I'm confused
 &gt; about now is the clock speed. With i2c_set_fast_mode(), I get a
 &gt; clock speed of 178 kHz. With i2c_set_standard_mode(), it's 266
 &gt; kHz. Weird, shouldn't fast mode be.. faster?
 &gt; 
 &gt; Also, one more thing: if I try and wait for "address
 &gt; transferred" by doing:
 &gt; 
 &gt;&nbsp; &nbsp; &nbsp;while (!(I2C_SR1(I2C1) &amp; I2C_SR1_ADDR));
 &gt; 
 &gt; after the i2c_send_7bit_address() call, then it gets stuck
 &gt; here. So I think I am still doing something wrong with the
 &gt; setup.
 &gt; 
 &gt; 
 &gt; On Sat, Aug 1, 2020 at 6:00 PM Chris Chronopoulos <
 &gt; chr...@gm...&gt; wrote:
 &gt; 
 &gt; &gt; I've also noticed that if I put in the while-loops to check for status
 &gt; &gt; register updates, e.g.
 &gt; &gt;
 &gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;while (!((I2C_SR1(I2C1) &amp; I2C_SR1_SB)
 &gt; &gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&amp; (I2C_SR2(I2C1) &amp; (I2C_SR2_MSL | I2C_SR2_BUSY))));
 &gt; &gt;
 &gt; &gt; Then this just gets stuck, confirming that the start condition is not
 &gt; &gt; being sent.
 &gt; &gt;
 &gt; &gt; On Sat, Aug 1, 2020 at 5:52 PM Chris Chronopoulos <
 &gt; &gt; chr...@gm...&gt; wrote:
 &gt; &gt;
 &gt; &gt;&gt; Hi, just joined this list, not sure what the protocol is.. but I have a
 &gt; &gt;&gt; question about getting I2C working on the STM32L1(52RE).
 &gt; &gt;&gt;
 &gt; &gt;&gt; First of all, I see that there are two versions of the I2C API: v1 and
 &gt; &gt;&gt; v2. Can someone explain what the difference is between these? From digging
 &gt; &gt;&gt; through the library, I can see that different device families use different
 &gt; &gt;&gt; versions, e.g.:
 &gt; &gt;&gt;
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;F0: v2
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;F1: v1
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;F2: v1
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;F3: v2
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;F4: v1
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;F7: v2
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;L0: v2
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;L1: v1
 &gt; &gt;&gt;&nbsp; &nbsp; &nbsp;L4: v2
 &gt; &gt;&gt;
 &gt; &gt;&gt; So when following code examples, I guess I need to find examples that use
 &gt; &gt;&gt; the v1 API. In libopencm3-examples, the only STM32 I2C v1 example I could
 &gt; &gt;&gt; find is this one for F1
 &gt; &gt;&gt; <https://github.com/libopencm3/libopencm3-examples/tree/master/examples/stm32/f1/other/i2c_stts75_sensor&gt;.
 &gt; &gt;&gt; Unfortunately, the i2c_setup() function in this code doesn't compile for
 &gt; &gt;&gt; L1, because of some differences between the RCC and GPIO API's (namely,
 &gt; &gt;&gt; RCC_AFIO and gpio_set_mode() are not defined for L1). So I made some
 &gt; &gt;&gt; adjustments based on my best guesses, and ended up with this code
 &gt; &gt;&gt; <https://gist.github.com/chronopoulos/d34de9b6119d4ec052451d6afaa99e79&gt;,
 &gt; &gt;&gt; which compiles. But, when I monitor the I2C lines with a logic analyzer, I
 &gt; &gt;&gt; see nothing. Dead silence.
 &gt; &gt;&gt;
 &gt; &gt;&gt; Am I missing something? Can anyone provide an example of I2C being used
 &gt; &gt;&gt; on STM32L1?
 &gt; &gt;&gt;
 &gt; &gt;&gt;
 &gt; _______________________________________________
 &gt; libopencm3-devel mailing list
 &gt; lib...@li...
 &gt; https://lists.sourceforge.net/lists/listinfo/libopencm3-devel

Re: [libopencm3-devel] I2C on STM32L1?

[Chris C. <chr...@gm...>]

Thank you! That helped me get up and running. There were two things I was
missing. First, the call to gpio_set_output_options() with GPIO_OTYPE_OD
appears to be critical; it's not sufficient to put this in
gpio_mode_setup(). Second, with GPIO_OTYPE_OD, apparently I need to
use i2c_set_speed(), instead of i2c_set_clock_frequency() and/or
i2c_set_fast/standard_mode().

After that, my address write received ACK. But I still was not able to use
i2c_send_data(); this apparently did nothing. However, using
i2c_transfer7() as you suggested, worked fine. So I am good for now (albeit
a little confused about the old/low-level interface versus the new one..).

Would it be helpful for me to submit a working L1 I2C example for
libopencm3-examples <https://github.com/libopencm3/libopencm3-examples>?

_chris



On Sun, Aug 2, 2020 at 10:24 AM Karl Palsson <ka...@tw...> wrote:

>
> https://github.com/karlp/libopencm3-tests/tree/master/tests/i2c-master
> is the code I wrote while developing the "standard" api. (You
> shouldn't really have to know about the v1/v2 differences, for
> the most part...) Those "set_fast_mode" and "set_standard_mode"
> are part of the original very low level apis. you (probably) want
> something more like:
>
>
> https://github.com/karlp/libopencm3-tests/blob/master/tests/i2c-master/i2c-master.c#L29-L38
> (i2c_set_speed(
> <https://github.com/karlp/libopencm3-tests/blob/master/tests/i2c-master/i2c-master.c#L29-L38(i2c_set_speed(>)
> and then just i2c_transfer7()
>
> The main-<hardware> have the onnly board specfic setup required,
> normally setting up clocks and gpio modes.
>
> There's a couple of issues reported with i2c as well:
> https://github.com/libopencm3/libopencm3/pulls?q=is%3Apr+is%3Aopen+i2c
> that _may_ be relevant to you, or at least to bear in mind.
>
>
> Chris Chronopoulos <chr...@gm...> wrote:
> > Hmm, well update - I figured out that I was missing the
> > following line:
> >
> >     rcc_periph_clock_enable(RCC_GPIOB);
> >
> > before my GPIO setup calls. Makes sense. The thing I'm confused
> > about now is the clock speed. With i2c_set_fast_mode(), I get a
> > clock speed of 178 kHz. With i2c_set_standard_mode(), it's 266
> > kHz. Weird, shouldn't fast mode be.. faster?
> >
> > Also, one more thing: if I try and wait for "address
> > transferred" by doing:
> >
> >     while (!(I2C_SR1(I2C1) & I2C_SR1_ADDR));
> >
> > after the i2c_send_7bit_address() call, then it gets stuck
> > here. So I think I am still doing something wrong with the
> > setup.
> >
> >
> > On Sat, Aug 1, 2020 at 6:00 PM Chris Chronopoulos <
> > chr...@gm...> wrote:
> >
> > > I've also noticed that if I put in the while-loops to check for status
> > > register updates, e.g.
> > >
> > >         while (!((I2C_SR1(I2C1) & I2C_SR1_SB)
> > >                 & (I2C_SR2(I2C1) & (I2C_SR2_MSL | I2C_SR2_BUSY))));
> > >
> > > Then this just gets stuck, confirming that the start condition is not
> > > being sent.
> > >
> > > On Sat, Aug 1, 2020 at 5:52 PM Chris Chronopoulos <
> > > chr...@gm...> wrote:
> > >
> > >> Hi, just joined this list, not sure what the protocol is.. but I have
> a
> > >> question about getting I2C working on the STM32L1(52RE).
> > >>
> > >> First of all, I see that there are two versions of the I2C API: v1 and
> > >> v2. Can someone explain what the difference is between these? From
> digging
> > >> through the library, I can see that different device families use
> different
> > >> versions, e.g.:
> > >>
> > >>     F0: v2
> > >>     F1: v1
> > >>     F2: v1
> > >>     F3: v2
> > >>     F4: v1
> > >>     F7: v2
> > >>     L0: v2
> > >>     L1: v1
> > >>     L4: v2
> > >>
> > >> So when following code examples, I guess I need to find examples that
> use
> > >> the v1 API. In libopencm3-examples, the only STM32 I2C v1 example I
> could
> > >> find is this one for F1
> > >> <
> https://github.com/libopencm3/libopencm3-examples/tree/master/examples/stm32/f1/other/i2c_stts75_sensor
> >.
> > >> Unfortunately, the i2c_setup() function in this code doesn't compile
> for
> > >> L1, because of some differences between the RCC and GPIO API's
> (namely,
> > >> RCC_AFIO and gpio_set_mode() are not defined for L1). So I made some
> > >> adjustments based on my best guesses, and ended up with this code
> > >> <
> https://gist.github.com/chronopoulos/d34de9b6119d4ec052451d6afaa99e79>,
> > >> which compiles. But, when I monitor the I2C lines with a logic
> analyzer, I
> > >> see nothing. Dead silence.
> > >>
> > >> Am I missing something? Can anyone provide an example of I2C being
> used
> > >> on STM32L1?
> > >>
> > >>
> > _______________________________________________
> > libopencm3-devel mailing list
> > lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libopencm3-devel