Search found 36 matches
- Thu Jul 18, 2019 12:47 am
- Forum: Development and Feedback
- Topic: VPATH Bites Again...
- Replies: 4
- Views: 2945
VPATH Bites Again...
Hi All, I really hate VPATH I have just been bitten by VPATH again. On the plus side it only took me 2 hours to figure out what was going on this time. VPATH is well known for causing problems, and in general I think once people are bitten by the most common case once they learn to work around it. T...
- Mon Apr 22, 2019 4:16 pm
- Forum: Development and Feedback
- Topic: [INFO] Results with GCC 8.2.1 vs GCC 7.3.1
- Replies: 8
- Views: 4193
Re: [INFO] Results with GCC 8.2.1 vs GCC 7.3.1
I know I am a few months late, but figured I would add my two cents anyway. I can't speak to any arm-specific work done on the arm-none-eabi branch of gcc (or the commercial arm clang compiler), but I can offer some observations about the changes and work going into gcc/clang as a whole in the last ...
- Tue Nov 27, 2018 10:48 pm
- Forum: Bug Reports
- Topic: strange behavior of the scheduler on STM32F070 Topic is solved
- Replies: 44
- Views: 33634
Re: strange behavior of the scheduler on STM32F070 Topic is solved
Obviously a compiler fix is the best solution, but having gone down this path before with regressions in gcc-arm-none-eabi I would not hold my breath. I am still waiting on some regressions reported and confirmed over a year ago. A less than great workaround might be to mark the IRQ handler as __att...
- Sun Oct 21, 2018 7:56 pm
- Forum: Development and Feedback
- Topic: Potential benefit of using stdatomic.h
- Replies: 3
- Views: 2897
Re: Potential benefit of using stdatomic.h
FWIW, this is what using ldrex/strex on arm looks like to write a boolean atomically. https://i.imgur.com/dZIOrNx.png As you can see it must be implemented as a loop. Purely hypothetically this *could* be an infinite loop if you somehow managed to have an interrupt fire precisely between the ldrex/s...
- Mon Oct 01, 2018 9:55 pm
- Forum: Bug Reports
- Topic: STM32 UART USARTv1 idle interrupt Topic is solved
- Replies: 7
- Views: 4959
Re: STM32 UART USARTv1 idle interrupt Topic is solved
I don't think this made it in.
At the very least it it isn't in master or the 18.2.x branch on github.
https://github.com/ChibiOS/ChibiOS/blob ... lld.c#L317
At the very least it it isn't in master or the 18.2.x branch on github.
https://github.com/ChibiOS/ChibiOS/blob ... lld.c#L317
- Wed Sep 05, 2018 11:37 am
- Forum: ChibiOS/HAL
- Topic: Issue developing a USB device with two config descriptors
- Replies: 4
- Views: 3050
Re: Issue developing a USB device with two config descriptors
the configuration index should be in dindex - exactly how it works for string descriptors.
- Wed Sep 05, 2018 11:33 am
- Forum: Small Change Requests
- Topic: Argument to PAL UART callbacks Topic is solved
- Replies: 5
- Views: 4824
Re: Argument to PAL UART callbacks Topic is solved
I haven't looked at all drivers, but it seems like a pretty common pattern in ChibiOS HAL. At least for the UART driver it exists. https://github.com/ChibiOS/ChibiOS/blob/f063c4d19339144df89d6bc060ee2017b0572c5c/os/hal/ports/STM32/LLD/USARTv1/hal_uart_lld.h#L550 If you add the following to your halc...
- Wed Aug 15, 2018 7:32 pm
- Forum: Bug Reports
- Topic: USB_USE_WAIT, TxFIFO Errata and STM32_USB_OTGFIFO_FILL_BASEPRI Topic is solved
- Replies: 6
- Views: 4567
Re: USB_USE_WAIT, TxFIFO Errata and STM32_USB_OTGFIFO_FILL_BASEPRI Topic is solved
Hi Giovanni, Sorry I never got back to you on this issue. We had already gotten a resolution to our stability issue with the STM32_USB_OTGFIFO_FILL_BASEPRI hack and moved on. We were on 16.x at the time and didn't have enough time to mess around getting the codebase working on trunk. I have used 17....
- Wed Aug 15, 2018 7:08 pm
- Forum: ChibiOS/RT
- Topic: Maximum static array size
- Replies: 5
- Views: 3526
Re: Maximum static array size
chances are you are simply out of memory and aren't aware of it. Remove the large array and recompile - then look at the line that looks like below: text data bss dec hex filename 60732 456 196604 257792 3ef00 build/TEST.elf If you add up the bss and data columns that will tell you roughly how much ...
- Wed Aug 15, 2018 6:38 pm
- Forum: Bug Reports
- Topic: STM32F070x6 hard faults while initializing GPIOD Topic is solved
- Replies: 10
- Views: 6725
Re: STM32F070x6 hard faults while initializing GPIOD Topic is solved
to the contrary, that table shows both the STM32F070C6 and STM32F070CB parts as having the same number of GPIO (37) and being available in the same package (LQFP48). Later in the datasheet they do show that PD2 (the only pin on PD in the entire series of chips) is only available on the LQFP64 packag...