Search found 36 matches

by apmorton
Thu Jul 18, 2019 12:47 am
Forum: Development and Feedback
Topic: VPATH Bites Again...
Replies: 4
Views: 267

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...
by apmorton
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: 801

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 ...
by apmorton
Tue Nov 27, 2018 10:48 pm
Forum: Bug Reports
Topic: strange behavior of the scheduler on STM32F070 Topic is solved
Replies: 40
Views: 2945

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...
by apmorton
Sun Oct 21, 2018 7:56 pm
Forum: Development and Feedback
Topic: Potential benefit of using stdatomic.h
Replies: 3
Views: 537

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...
by apmorton
Mon Oct 01, 2018 9:55 pm
Forum: Bug Reports
Topic: STM32 UART USARTv1 idle interrupt
Replies: 4
Views: 710

Re: STM32 UART USARTv1 idle interrupt

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
by apmorton
Wed Sep 05, 2018 11:37 am
Forum: ChibiOS/HAL
Topic: Issue developing a USB device with two config descriptors
Replies: 4
Views: 498

Re: Issue developing a USB device with two config descriptors

the configuration index should be in dindex - exactly how it works for string descriptors.
by apmorton
Wed Sep 05, 2018 11:33 am
Forum: Small Change Requests
Topic: Argument to PAL UART callbacks Topic is solved
Replies: 5
Views: 609

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...
by apmorton
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: 1369

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....
by apmorton
Wed Aug 15, 2018 7:08 pm
Forum: ChibiOS/RT
Topic: Maximum static array size
Replies: 5
Views: 791

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 ...
by apmorton
Wed Aug 15, 2018 6:38 pm
Forum: Bug Reports
Topic: STM32F070x6 hard faults while initializing GPIOD Topic is solved
Replies: 10
Views: 933

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

Go to advanced search