You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(8) |
Feb
(15) |
Mar
(18) |
Apr
(13) |
May
(9) |
Jun
(14) |
Jul
(12) |
Aug
(58) |
Sep
(26) |
Oct
(58) |
Nov
(18) |
Dec
(1) |
2013 |
Jan
(10) |
Feb
(13) |
Mar
(51) |
Apr
(15) |
May
(1) |
Jun
(2) |
Jul
(9) |
Aug
(6) |
Sep
(4) |
Oct
(25) |
Nov
(7) |
Dec
(8) |
2014 |
Jan
(64) |
Feb
(27) |
Mar
(15) |
Apr
(4) |
May
(22) |
Jun
|
Jul
(13) |
Aug
(7) |
Sep
|
Oct
(3) |
Nov
(16) |
Dec
(14) |
2015 |
Jan
(2) |
Feb
(7) |
Mar
(6) |
Apr
|
May
(3) |
Jun
|
Jul
(20) |
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
(17) |
Dec
|
2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
(13) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(8) |
Feb
(15) |
Mar
(33) |
Apr
(5) |
May
(3) |
Jun
(6) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(5) |
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(6) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2021 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2023 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Vladislav T. <vtc...@gm...> - 2025-06-26 12:53:56
|
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 |
From: Chuck G. <tub...@ya...> - 2023-01-10 22:48:44
|
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 |
From: Amitesh S. <sin...@gm...> - 2023-01-10 09:41:31
|
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 > |
From: Bob D. <bob...@xy...> - 2023-01-03 14:24:58
|
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 |
From: Amitesh S. <sin...@gm...> - 2023-01-03 07:27:22
|
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 > |
From: Damien M. <lis...@gm...> - 2023-01-02 14:23:28
|
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 |
From: Eléaz v. d. T. <ele...@ho...> - 2022-09-30 09:28:11
|
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 |
From: Stephen H. <st...@st...> - 2022-09-28 01:00:30
|
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 > |
From: Eléaz v. d. T. <ele...@ho...> - 2022-09-27 12:40:03
|
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 |
From: Chris C. <chr...@gm...> - 2021-10-22 00:54:56
|
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 |
From: Karl P. <ka...@tw...> - 2021-09-22 18:44:46
|
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 |
From: Lubomir R. <lku...@v3...> - 2021-09-22 16:56:43
|
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 |
From: Karl P. <ka...@tw...> - 2021-05-26 10:14:21
|
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 |
From: Uwe B. <bo...@el...> - 2021-05-26 08:43:26
|
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") |
From: Rico <bo...@cr...> - 2021-05-26 07:32:18
|
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 |
From: <ka...@as...> - 2021-01-16 18:54:16
|
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 |
From: G H. <go...@ra...> - 2021-01-16 17:50:22
|
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... |
From: Valentijn S. <val...@se...> - 2020-09-25 11:06:53
|
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 |
From: Karl P. <ka...@tw...> - 2020-08-18 16:05:55
|
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. |
From: Chuck G. <tub...@ya...> - 2020-08-18 14:46:50
|
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 |
From: Karl P. <ka...@tw...> - 2020-08-18 13:58:33
|
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 |
From: Chuck G. <tub...@ya...> - 2020-08-17 17:46:14
|
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. |
From: Karl P. <ka...@tw...> - 2020-08-13 09:58:30
|
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 |
From: <xuy...@sy...> - 2020-08-10 01:25:25
|
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: "Chris Chronopoulos"<chr...@gm...>; Date: Mon, Aug 3, 2020 10:00 AM To: "Karl Palsson"<ka...@tw...>; Cc: "libopencm3-devel"<lib...@li...>; Subject: Re: [libopencm3-devel] I2C on STM32L1? 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? _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() 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 |
From: Chris C. <chr...@gm...> - 2020-08-03 01:59:31
|
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 |