November 2025 - Devel - lists.tockos.org

Re: Porting Tock OS to STM32 (L476 / F756)

by Kamil Duljas

Hi, finally I created a draft pull request for stm32l476. I'm aware that there are still many things to do. Kamil pon., 10 lis 2025 o 16:00 Branden Ghena <branden(a)northwestern.edu> napisał(a): > HI Kamil, > > While you're welcome to use DMA, it's not required for an initial port of > a board. Often DMA is a later addition once the proof of concept works and > a more-performant system is desired. Using interrupts for the UART would be > totally fine. > > Thanks, > Branden Ghena > Northwestern University > > > On Mon, Nov 10, 2025 at 6:06 AM Kamil Duljas via Devel < > devel(a)lists.tockos.org> wrote: > >> Hi, regarding the port to the STM32L476RG — work in progress :) >> I’m wondering about UART transmission. I noticed that some boards (e.g. >> Nucleo, Discovery) use interrupts, >> while others use DMA as well. Should I use UART with DMA, or is DMA >> optional at this stage? >> >> Kamil >> >> pon., 3 lis 2025 o 16:10 Leon Schuermann <leon(a)is.currently.online> >> napisał(a): >> >>> I'm excited seeing the progress made on this port! >>> >>> Kamil Duljas via Devel <devel(a)lists.tockos.org> writes: >>> > I noticed that GPIO code for F3 F4 and L4 is 80-90% the same. maybe we >>> > could extract it as a common part like stm32x ? I guess it could be >>> > done for many pheripherials. >>> >>> Yes! In general, avoiding such code duplication is desirable, and there >>> should be plenty of existing examples in the `chips/` folder, like >>> `nrf5x` or `stmf4xx`. >>> >>> However, Tock has some particular (and somewhat implicit) conventions >>> when it comes to code-sharing for multiple targets. For instance, we >>> generally discourage conditional compilation by means of Cargo features >>> (`#[cfg(...)]`) in our code, as that makes code harder to test. >>> >>> For a new target, I think it could be good to first get a chip and board >>> crate merged (which perhaps duplicates some code that is not completely >>> identical and thus trivially sharable between chips), and then split out >>> that common infrastructure in a follow-up PR. This way you won't risk >>> de-railing the PR to add the board over discussions on how to organize >>> that shared infrastructure. >>> >>> -Leon >>> >> >> >> -- >> Pozdrawiam, >> Kamil Duljas >> > -- Pozdrawiam, Kamil Duljas

Nov. 24, 2025

Re: Porting Tock OS to STM32 (L476 / F756)

by Branden Ghena

HI Kamil, While you're welcome to use DMA, it's not required for an initial port of a board. Often DMA is a later addition once the proof of concept works and a more-performant system is desired. Using interrupts for the UART would be totally fine. Thanks, Branden Ghena Northwestern University On Mon, Nov 10, 2025 at 6:06 AM Kamil Duljas via Devel < devel(a)lists.tockos.org> wrote: > Hi, regarding the port to the STM32L476RG — work in progress :) > I’m wondering about UART transmission. I noticed that some boards (e.g. > Nucleo, Discovery) use interrupts, > while others use DMA as well. Should I use UART with DMA, or is DMA > optional at this stage? > > Kamil > > pon., 3 lis 2025 o 16:10 Leon Schuermann <leon(a)is.currently.online> > napisał(a): > >> I'm excited seeing the progress made on this port! >> >> Kamil Duljas via Devel <devel(a)lists.tockos.org> writes: >> > I noticed that GPIO code for F3 F4 and L4 is 80-90% the same. maybe we >> > could extract it as a common part like stm32x ? I guess it could be >> > done for many pheripherials. >> >> Yes! In general, avoiding such code duplication is desirable, and there >> should be plenty of existing examples in the `chips/` folder, like >> `nrf5x` or `stmf4xx`. >> >> However, Tock has some particular (and somewhat implicit) conventions >> when it comes to code-sharing for multiple targets. For instance, we >> generally discourage conditional compilation by means of Cargo features >> (`#[cfg(...)]`) in our code, as that makes code harder to test. >> >> For a new target, I think it could be good to first get a chip and board >> crate merged (which perhaps duplicates some code that is not completely >> identical and thus trivially sharable between chips), and then split out >> that common infrastructure in a follow-up PR. This way you won't risk >> de-railing the PR to add the board over discussions on how to organize >> that shared infrastructure. >> >> -Leon >> > > > -- > Pozdrawiam, > Kamil Duljas >

Nov. 10, 2025

Re: Porting Tock OS to STM32 (L476 / F756)

by Kamil Duljas

Hi, regarding the port to the STM32L476RG — work in progress :) I’m wondering about UART transmission. I noticed that some boards (e.g. Nucleo, Discovery) use interrupts, while others use DMA as well. Should I use UART with DMA, or is DMA optional at this stage? Kamil pon., 3 lis 2025 o 16:10 Leon Schuermann <leon(a)is.currently.online> napisał(a): > I'm excited seeing the progress made on this port! > > Kamil Duljas via Devel <devel(a)lists.tockos.org> writes: > > I noticed that GPIO code for F3 F4 and L4 is 80-90% the same. maybe we > > could extract it as a common part like stm32x ? I guess it could be > > done for many pheripherials. > > Yes! In general, avoiding such code duplication is desirable, and there > should be plenty of existing examples in the `chips/` folder, like > `nrf5x` or `stmf4xx`. > > However, Tock has some particular (and somewhat implicit) conventions > when it comes to code-sharing for multiple targets. For instance, we > generally discourage conditional compilation by means of Cargo features > (`#[cfg(...)]`) in our code, as that makes code harder to test. > > For a new target, I think it could be good to first get a chip and board > crate merged (which perhaps duplicates some code that is not completely > identical and thus trivially sharable between chips), and then split out > that common infrastructure in a follow-up PR. This way you won't risk > de-railing the PR to add the board over discussions on how to organize > that shared infrastructure. > > -Leon > -- Pozdrawiam, Kamil Duljas

Nov. 10, 2025

Re: Porting Tock OS to STM32 (L476 / F756)

by Leon Schuermann

I'm excited seeing the progress made on this port! Kamil Duljas via Devel <devel(a)lists.tockos.org> writes: > I noticed that GPIO code for F3 F4 and L4 is 80-90% the same. maybe we > could extract it as a common part like stm32x ? I guess it could be > done for many pheripherials. Yes! In general, avoiding such code duplication is desirable, and there should be plenty of existing examples in the `chips/` folder, like `nrf5x` or `stmf4xx`. However, Tock has some particular (and somewhat implicit) conventions when it comes to code-sharing for multiple targets. For instance, we generally discourage conditional compilation by means of Cargo features (`#[cfg(...)]`) in our code, as that makes code harder to test. For a new target, I think it could be good to first get a chip and board crate merged (which perhaps duplicates some code that is not completely identical and thus trivially sharable between chips), and then split out that common infrastructure in a follow-up PR. This way you won't risk de-railing the PR to add the board over discussions on how to organize that shared infrastructure. -Leon

Nov. 3, 2025

Re: Porting Tock OS to STM32 (L476 / F756)

by Kamil Duljas

Hi, while porting stm32L476 I noticed that GPIO code for F3 F4 and L4 is 80-90% the same. maybe we could extract it as a common part like stm32x ? I guess it could be done for many pheripherials. niedz., 26 paź 2025 o 18:56 Kamil Duljas <dudo1990(a)gmail.com> napisał(a): > Thank's! I guess STM32L4 series are widely available :) It's newer than > F4. It would be a pleasure to maintain the board :). I will be back with > basic support :) > > niedz., 26 paź 2025 o 17:43 Amit Levy <amit(a)amitlevy.com> napisał(a): > >> That's great! >> >> It's unfortunately a bit buried, but there the porting guide suggests >> what a minimal upstream board should support: < >> https://book.tockos.org/development/porting#adding-a-platform-to-tock-repos… >> > >> >> >> 1. The hardware must be widely available. Generally that means the >> hardware platform can be purchased online. >> 2. The port of Tock to the platform must include at least: >> - Console support so that debug!() and printf() work. >> - Timer support. >> - GPIO support with interrupt functionality. >> 3. The contributor must be willing to maintain the platform, at least >> initially, and help test the platform for future releases. >> >> >> In other words, the blink and hello world apps should work. >> >> GPIO, RCC and UART should be sufficient for this. >> >> Having said that, there is no harm to initiating a draft pull request >> _or_ sharing an external repo with the port at whatever stage you have if >> it would be useful to get a gut check that the style and/or implementation >> details are on the right path. >> >> >> On October 26, 2025 8:46:05 AM PDT, Kamil Duljas <dudo1990(a)gmail.com> >> wrote: >> >>> Thank you for all replies. I ran Tock os on L476 :D but only minimal >>> stuff to blinking Led. I'm wondering what should be done before first >>> official pull request? Full gpio, RCC, UART? >>> >>> Greetings >>> Kamil Duljas >>> >>> pon., 20 paź 2025, 19:30 użytkownik Patrick Pannuto <ppannuto(a)ucsd.edu> >>> napisał: >>> >>>> +Tyler Potyondy <tpotyondy(a)ucsd.edu> and a few other folks are most of >>>> the way through a port to the STM32WLE5xx family, which may share some more >>>> with the STM32L than the existing STM32F upstream as well >>>> >>>> On Sat, Oct 18, 2025 at 5:51 AM Amit Levy via Devel < >>>> devel(a)lists.tockos.org> wrote: >>>> >>>>> Hi and welcome! >>>>> >>>>> I don't see any obstacles. The STM32L476 is a Cortex-M4, of which there >>>>> are many examples upstream, and the STM32F756 is a Cortex-M7 for which >>>>> there is support (albeit only one example upstream, so there is of >>>>> course a slightly higher likelihood of kinds to iron out). >>>>> >>>>> Since both are STM chips, I'd expect much of their peripherals to be >>>>> shared with or at least very similar to some of the STM32 chips for >>>>> which there are upstream ports. >>>>> >>>>> Keep posted and please feel free to ask questions or for help or if you >>>>> run into issues! >>>>> >>>>> -Amit >>>>> >>>>> Kamil Duljas via Devel <devel(a)lists.tockos.org> writes: >>>>> >>>>> > Hi, >>>>> > >>>>> > I'd like to port Tock OS to an STM32 microcontroller - either the >>>>> STM32L476 >>>>> > or STM32F756. >>>>> > >>>>> > Are there any known technical obstacles or limitations that would >>>>> make this >>>>> > difficult? >>>>> > >>>>> > Best regards, >>>>> > Pozdrawiam, >>>>> > Kamil Duljas >>>>> > _______________________________________________ >>>>> > Devel mailing list -- devel(a)lists.tockos.org >>>>> > To unsubscribe send an email to devel-leave(a)lists.tockos.org >>>>> _______________________________________________ >>>>> Devel mailing list -- devel(a)lists.tockos.org >>>>> To unsubscribe send an email to devel-leave(a)lists.tockos.org >>>>> >>>> > > -- > Pozdrawiam, > Kamil Duljas > -- Pozdrawiam, Kamil Duljas

Nov. 2, 2025