- Devel - lists.tockos.org

Re: Support tockloader for STM32L4

by Tyler Potyondy

I recently added tockloader support for the WL5xx board family. It is still a work in progress and has a few hacky fixes I need to cleanup, but here's my branch in case it helps you for adding L4 tockloader support: https://github.com/tyler-potyondy/tockloader/commits/ents-board-config/ <https://github.com/tyler-potyondy/tockloader/commits/ents-board-config/> -Tyler Potyondy On Mon, Jan 12, 2026 at 7:31 AM Branden Ghena via Devel < devel(a)lists.tockos.org> wrote: > Sure! Go ahead and make a PR to Tockloader whenever. > > And thanks for the contributions! We will get to reviewing them as soon as > we can. > > Thanks, > Branden Ghena > Northwestern University > > > On Mon, Jan 12, 2026 at 1:52 AM Kamil Duljas via Devel < > devel(a)lists.tockos.org> wrote: > >> Hi, >> My PR is waiting for review https://github.com/tock/tock/pull/4672 >> <https://urldefense.com/v3/__https://github.com/tock/tock/pull/4672__;!!Dq0X…> >> >> but I'm wondering if I can add support in tockloader parallelly. A code >> should be similar to F4 boards but it should be separated because OpenOCD >> defines his own cfg file for L4 boards. >> >> -- >> Best, >> Kamil Duljas >> > _______________________________________________ > Devel mailing list -- devel(a)lists.tockos.org > To unsubscribe send an email to devel-leave(a)lists.tockos.org >

Jan. 12, 2026

Re: Support tockloader for STM32L4

by Branden Ghena

Sure! Go ahead and make a PR to Tockloader whenever. And thanks for the contributions! We will get to reviewing them as soon as we can. Thanks, Branden Ghena Northwestern University On Mon, Jan 12, 2026 at 1:52 AM Kamil Duljas via Devel < devel(a)lists.tockos.org> wrote: > Hi, > My PR is waiting for review https://github.com/tock/tock/pull/4672 > <https://urldefense.com/v3/__https://github.com/tock/tock/pull/4672__;!!Dq0X…> > > but I'm wondering if I can add support in tockloader parallelly. A code > should be similar to F4 boards but it should be separated because OpenOCD > defines his own cfg file for L4 boards. > > -- > Best, > Kamil Duljas >

Jan. 12, 2026

Support tockloader for STM32L4

by Kamil Duljas

Hi, My PR is waiting for review https://github.com/tock/tock/pull/4672 but I'm wondering if I can add support in tockloader parallelly. A code should be similar to F4 boards but it should be separated because OpenOCD defines his own cfg file for L4 boards. -- Best, Kamil Duljas

Jan. 12, 2026

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

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

by Amit Levy

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

Oct. 26, 2025

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

by Kamil Duljas

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

Oct. 26, 2025