distortos-development Mailing List for distortos
object-oriented C++ RTOS for microcontrollers
Brought to you by:
distortec
Menu
▾
▴
distortos-development — Mailing list about development of distortos
You can subscribe to this list here.
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(12) |
Oct
(35) |
Nov
(16) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 |
Jan
(7) |
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: Kamil S. <dis...@di...> - 2018-09-01 08:58:11
|
Hi! I've created a group for distortos in Google Groups, with a plan to shut down the mailing list hosted on Sourceforge. The move is caused by the fact that Sourceforge is a dying service, which basically just waits for someone to pull the plug... Additionally Google Groups offers some nice features, most important one is that it is a mix of a regular mailing list and a forum - you can use it with your e-mail client only as well as solely via web browser. It may be important to note, that you do NOT need a Gmail account to use this group - you can subscribe with any e-mail address you like. https://groups.google.com/forum/#!forum/distortos I plan to keep the Sourceforge mailing list around for a while, but eventually it will be closed. Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2018-07-08 07:30:23
|
Hi! On Sun, 2018-07-08 at 15:06 +0800, Winston Rodrigues wrote: > I went through some of the scripts. And I observed it is parsing > the csv file. And for the first glance it looked bit complex to me. > I was thinking I had to write the chip yaml file myself. Bit > relieved after you said it's generated by python scripts. Hopefully the usage will be easy, even if the scripts may be a bit complex internally. We'll see... > > If possible please send me the commits link which would be helpful > for me to try to do the porting. The last chip family I added was STM32L4 and here's the merge commit which added _BASIC_ support: https://github.com/DISTORTEC/distortos/commit/140e21c90a241e4bcf5236f031c6792f074d89b3 I emphasized "basic", as a bit later there's another merge which adds more extended support, which includes peripherals, clock configuration and all the stuff which is actually not strictly required. https://github.com/DISTORTEC/distortos/commit/82df4fc9fca9502d11655c7d8356df03d2023ddc >From both these merge commits you can see the individual commits by following the right parent. For example if you see "2 parents 385ea0d + 9a6742e" in the second link, then click on "9a6742e". The commits may also be listed like this: https://github.com/DISTORTEC/distortos/commits/master?after=140e21c90a241e4bcf5236f031c6792f074d89b3+0 (branch starts with "Add CMSIS-STM32L4 v.1.10.0") and: https://github.com/DISTORTEC/distortos/commits/master?after=82df4fc9fca9502d11655c7d8356df03d2023ddc+0 (branch starts with "Add STM32L4.dtsi.jinja template") Regards, Kamil Szczygieł |
|
From: Winston R. <win...@gm...> - 2018-07-08 07:07:07
|
Hi Kamil, First of all thank you so much for taking time to reply with such a great detail. I went through some of the scripts. And I observed it is parsing the csv file. And for the first glance it looked bit complex to me. I was thinking I had to write the chip yaml file myself. Bit relieved after you said it's generated by python scripts. My project is going to be run on STM32F405RG. But the board is not arrived yet from china. So I had LPC1768 board handy with me I was thinking may be I could evaluate it on this LPC board. I actually started to hard code some of the the stuff in the architecture / chips folder and found it's getting more complicated. So after reading your mail I felt it's a good idea to wait for the STM32 board to arrive than actually wasting my time on porting this way. And I am very happy that you are working on Cmake + Python to make the porting easier. I will definitely contribute by adding new chips from NXP. I want to see this RTOS going ahead. This is only possible if we can introduce it in other chip vendors ( NXP, Atmel, TI). If possible please send me the commits link which would be helpful for me to try to do the porting. And No I did not lose interest in Distortos. :) On Sat, Jul 7, 2018 at 3:29 AM Kamil Szczygieł <dis...@di...> wrote: > Hello again Winston! > > Sorry for the late reply, but this week I was pretty busy and the > answer to your question will probably be a bit longer. > > On Tue, 2018-07-03 at 14:52 +0800, Winston Rodrigues wrote: > > I am trying to play around with distortos since a week. And I > > am really happy about it suporting C++11 standard. > > Glad to hear that. I think there's a niche in the offerings of RTOSes > for microcontrollers, as most of them are C-only. On the other hand C++ > is known for its bad reputation and stupid myths, so... (; > > I you have any remarks, opinions, suggestions, ideas, issues, etc. > about distortos, don't hesitate to share them! > > > Can some one point me in a right direction to support new > > microcontroller ? Preferably LPC1768 ( Cortex - M3). > > I'm a little afraid that you may not like the answer to your question. > As you probably already noticed, currently distortos is configured with > kconfig-frontends, with "mconf" tool which you invoke with "make > menuconfig". This generally works fine as long as you are a Linux > kernel (; In case of a more complex configuration than "enable/disable > this feature which has almost none dependencies" the amount of kconfig > code starts to increase exponentially, up to a point where I think it > is extremely hard to maintain. For example, clock configuration for > STM32F7 - which consists of more or less a dozen of options - is > described by ~400 lines of Kconfig code. This of course includes blank > lines and help messages, but even if you cut that in half, the number > is still enormous (at least by my standards). > > Generally I was happy with kconfig until I started adding some bits of > HAL to distortos. When you need to describe ~100 chips, where each one > has almost unique combination of available peripherals (this one has 3 > UARTs and 5 SPIs, the next one has just 2 UARTs but 7 SPIs, ...) the > problems start to be visible. As an example I guess it's enough to say > that it took ~1500 lines of Kconfig code (also including some blank > lines) to describe _only_ GPIOs, UARTs and SPIs in ~140 STM32F4 chips. > Imagine how much would it be if it would describe all other > peripherals. I guess that the number of lines in this file would have 5 > digits and the first digit would not be "1". This is unmaintainable in > the long run. > > The reason (IMHO) is that kconfig language is very simple and has > almost zero features which could make this simpler and reduce amount of > boilerplate and repetitions. To make this argument even stronger, let's > mention that kconfig in distortos is "enhanced" by some shell scripts > too. So at the end of 2017 I finally decided to ditch kconfig and move > on to CMake + Python. > > Initial support for this combination is already in the repository, but > it is far from being finalized. My plan is to use Python to generate > "boards" (complete folders with board support files) and then use CMake > to configure the project. The first part (Python-based board generator) > is mostly ready and uses YAML files describing boards and chips. The > huge difference between this approach and kconfig is that I generate > YAML description of chips from an extremely compact and flexible data > source - a spreadsheet in the form of a CSV file. Editing data in the > spreadsheet is much faster than hand-editing kconfig files, so I have > really high hopes here. So even if there are hundreds of YAML files for > chips, generating them all takes a few seconds. Python is an extremely > powerful language, so if you have data (CSV files) you can easily > manipulate them any way you like. > > CMake - despite its horrible syntax and its peculiarities - is also > pretty powerful scripting language. As long as you don't have to deal > with binary data, you can do orders of magnitude more than in kconfig. > > But to the point. You asked about adding support for LPC17xx chip > family. At this moment I would say that this would be pretty hard and > mostly a waste of time :( . This is because currently kconfig is still > obligatory, so you would have to deal with that, but my plan is to > delete all of its traces as soon as possible, which makes any kconfig- > related effort a waste of time. I'm not happy giving you such answer, > but there's no point in avoiding the facts. Kconfig is a dead-end for > distortos. In my opinion configuration of the project is the single > biggest problem/flaw/issue of distortos. > > This of course is the answer about adding PROPER support for LPC17xx > chip family. However in April this year I was contacted by a person > from Norway which wanted to share some opinions about distortos. This > guy told me that he ported distortos to LPC1756 and LPC1758 for some > commercial projects in his work and that it worked fine. Of course this > port is far from being "proper" - he just hardcoded necessary stuff > where appropriate, changed what was needed and that's it. This probably > is also not simple, but in my opinion still much simpler than doing it > properly in kconfig... > > With all that in mind, my proposal goes like this - if you really have > to use LPC17xx now, I would prefer to do the port myself. This will be > much easier, as there's no written documentation about the porting > process and creating such documentation now would also be a waste of > time, given the plan to drop kconfig support. If this would suit you, > just let me know what board are you using, so maybe I would buy one > myself so we would have the same hardware to test. If you want to do it > yourself, I can point to you some commits which added such support for > some STM32 chip families, which is basically as close to a complete > guide as possible. Another option is to do a manual and "brutal" port, > with no support for the whole chip family in kconfig. This would > basically mean copying folder of some chip family (preferably the one > closest to LPC17xx, so STM32F1) and changing what's necessary. > > > Also I see there is no support for I2C drivers yet. I would > > like to learn how to do that too. > > I am quite experienced in writing low level code. Some hints on > > the direction would be really great. > > I think I2C driver should be very similar to the SPI driver. The logic > is similar, as both I2C and SPI are buses which can be shared among > many devices connected to the same signals. My hint would therefore be > to first study the SPI master driver. If you have any questions about > that, just ask here or on github, we can also move the communication > somewhere else where it would be most convenient for you (like the ARM > forum or maybe a subreddit). > > Sorry that my answer about porting to another chip family is not more > positive... Believe me that I'm very sad saying that something so > crucial to the project as porting is so hard to do and this particular > problem was bothering me for a very very long time (almost from the > start of the project to be honest). The issue here is that there's no > clear alternative, which would beat kconfig hands-down, while also > being easy to integrate in distortos. The Python + CMake combination > that I mentioned earlier will hopefully be better, but it will probably > be a lot of work to implement it in a satisfying way, so that it would > simplify the porting process. So I hope you did not loose interest in > distortos - either because my far-from-being-positive answer or because > it took me 4 days to reply (; > > Regards, > Kamil Szczygieł > > > |
|
From: Kamil S. <dis...@di...> - 2018-07-06 19:29:29
|
Hello again Winston! Sorry for the late reply, but this week I was pretty busy and the answer to your question will probably be a bit longer. On Tue, 2018-07-03 at 14:52 +0800, Winston Rodrigues wrote: > I am trying to play around with distortos since a week. And I > am really happy about it suporting C++11 standard. Glad to hear that. I think there's a niche in the offerings of RTOSes for microcontrollers, as most of them are C-only. On the other hand C++ is known for its bad reputation and stupid myths, so... (; I you have any remarks, opinions, suggestions, ideas, issues, etc. about distortos, don't hesitate to share them! > Can some one point me in a right direction to support new > microcontroller ? Preferably LPC1768 ( Cortex - M3). I'm a little afraid that you may not like the answer to your question. As you probably already noticed, currently distortos is configured with kconfig-frontends, with "mconf" tool which you invoke with "make menuconfig". This generally works fine as long as you are a Linux kernel (; In case of a more complex configuration than "enable/disable this feature which has almost none dependencies" the amount of kconfig code starts to increase exponentially, up to a point where I think it is extremely hard to maintain. For example, clock configuration for STM32F7 - which consists of more or less a dozen of options - is described by ~400 lines of Kconfig code. This of course includes blank lines and help messages, but even if you cut that in half, the number is still enormous (at least by my standards). Generally I was happy with kconfig until I started adding some bits of HAL to distortos. When you need to describe ~100 chips, where each one has almost unique combination of available peripherals (this one has 3 UARTs and 5 SPIs, the next one has just 2 UARTs but 7 SPIs, ...) the problems start to be visible. As an example I guess it's enough to say that it took ~1500 lines of Kconfig code (also including some blank lines) to describe _only_ GPIOs, UARTs and SPIs in ~140 STM32F4 chips. Imagine how much would it be if it would describe all other peripherals. I guess that the number of lines in this file would have 5 digits and the first digit would not be "1". This is unmaintainable in the long run. The reason (IMHO) is that kconfig language is very simple and has almost zero features which could make this simpler and reduce amount of boilerplate and repetitions. To make this argument even stronger, let's mention that kconfig in distortos is "enhanced" by some shell scripts too. So at the end of 2017 I finally decided to ditch kconfig and move on to CMake + Python. Initial support for this combination is already in the repository, but it is far from being finalized. My plan is to use Python to generate "boards" (complete folders with board support files) and then use CMake to configure the project. The first part (Python-based board generator) is mostly ready and uses YAML files describing boards and chips. The huge difference between this approach and kconfig is that I generate YAML description of chips from an extremely compact and flexible data source - a spreadsheet in the form of a CSV file. Editing data in the spreadsheet is much faster than hand-editing kconfig files, so I have really high hopes here. So even if there are hundreds of YAML files for chips, generating them all takes a few seconds. Python is an extremely powerful language, so if you have data (CSV files) you can easily manipulate them any way you like. CMake - despite its horrible syntax and its peculiarities - is also pretty powerful scripting language. As long as you don't have to deal with binary data, you can do orders of magnitude more than in kconfig. But to the point. You asked about adding support for LPC17xx chip family. At this moment I would say that this would be pretty hard and mostly a waste of time :( . This is because currently kconfig is still obligatory, so you would have to deal with that, but my plan is to delete all of its traces as soon as possible, which makes any kconfig- related effort a waste of time. I'm not happy giving you such answer, but there's no point in avoiding the facts. Kconfig is a dead-end for distortos. In my opinion configuration of the project is the single biggest problem/flaw/issue of distortos. This of course is the answer about adding PROPER support for LPC17xx chip family. However in April this year I was contacted by a person from Norway which wanted to share some opinions about distortos. This guy told me that he ported distortos to LPC1756 and LPC1758 for some commercial projects in his work and that it worked fine. Of course this port is far from being "proper" - he just hardcoded necessary stuff where appropriate, changed what was needed and that's it. This probably is also not simple, but in my opinion still much simpler than doing it properly in kconfig... With all that in mind, my proposal goes like this - if you really have to use LPC17xx now, I would prefer to do the port myself. This will be much easier, as there's no written documentation about the porting process and creating such documentation now would also be a waste of time, given the plan to drop kconfig support. If this would suit you, just let me know what board are you using, so maybe I would buy one myself so we would have the same hardware to test. If you want to do it yourself, I can point to you some commits which added such support for some STM32 chip families, which is basically as close to a complete guide as possible. Another option is to do a manual and "brutal" port, with no support for the whole chip family in kconfig. This would basically mean copying folder of some chip family (preferably the one closest to LPC17xx, so STM32F1) and changing what's necessary. > Also I see there is no support for I2C drivers yet. I would > like to learn how to do that too. > I am quite experienced in writing low level code. Some hints on > the direction would be really great. I think I2C driver should be very similar to the SPI driver. The logic is similar, as both I2C and SPI are buses which can be shared among many devices connected to the same signals. My hint would therefore be to first study the SPI master driver. If you have any questions about that, just ask here or on github, we can also move the communication somewhere else where it would be most convenient for you (like the ARM forum or maybe a subreddit). Sorry that my answer about porting to another chip family is not more positive... Believe me that I'm very sad saying that something so crucial to the project as porting is so hard to do and this particular problem was bothering me for a very very long time (almost from the start of the project to be honest). The issue here is that there's no clear alternative, which would beat kconfig hands-down, while also being easy to integrate in distortos. The Python + CMake combination that I mentioned earlier will hopefully be better, but it will probably be a lot of work to implement it in a satisfying way, so that it would simplify the porting process. So I hope you did not loose interest in distortos - either because my far-from-being-positive answer or because it took me 4 days to reply (; Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2018-07-03 07:02:04
|
Hi!
On Tue, 2018-07-03 at 14:36 +0800, Winston Rodrigues wrote:
> Yes you are right.
> But in my windows 7 system eclipse did not recognize my PATH
> variables which I set in Windows Environment variables (which is in
> Advanced System settings).
>
> Only after I set those PATH variables inside Eclipse I could build
> the project. Before that I kept getting error saying "make.exe not
> found in PATH bla bla"
I think the issue here may be that Eclipse allows you to modify
environment variables in several ways:
- you can set them "per project" (in properties for project) of "per
workspace" (Window > Preferences > C/C++ > Build > Environment)
- you can "append variables to native environment" or "replace native
environment with specified one" (separately for project and workspace
settings).
By default in each project's properties you should see PATH variable
with some value and "BUILD SYSTEM" in "Origin" column. This means that
Eclipse is using the value you set in the system. However if you modify
it somehow (it will have "USER: PREFS" or "USER: CONFIG" in "Origin"
column) and choose "Replace active environment with specified one" then
the PATH you set via Eclipse overrides the system variable. So if you
have 10 folders in system's PATH and just 3 in Eclipse's, the build
process will see just these three...
>From your screenshot I suspect that you have set PATH and chosen
"append variables to native environment", which should work fine but...
Maybe in your system you have configured Eclipse to start with
different environment variables? This is possible by editing
preferences of the Eclipse shortcut - if you have such shortcut
somewhere. Or maybe the problem is that you edited system's PATH and
started Eclipse right away in a way that caused it to see the "old
value" (for example from terminal opened before saving environment
variables)? Or maybe you set one user's PATH variable in system, but
Eclipse is started by another user (or administrator)? There are quite
a few ways in which something may go wrong here... However - when you
edit project's environment variables, select PATH and click on
"Delete", this should get back to the PATH from the system ("BUILD
SYSTEM" in "Origin") it should be identical the the variable in your
system (maybe with java added at the beginning, but everything else
should be the same). If that's not the case, then something is wrong
here (;
(disclaimer - all the statements above are based on what I see in my
system, which is not Windows, so in Windows this can be slightly
different - if that would be the case, just let me know and I'll try in
VirtualBox)
Regards,
KSz
|
|
From: Winston R. <win...@gm...> - 2018-07-03 06:52:48
|
Hi Devs,
I am trying to play around with distortos since a week. And I am
really happy about it suporting C++11 standard.
Can some one point me in a right direction to support new
microcontroller ? Preferably LPC1768 ( Cortex - M3).
Also I see there is no support for I2C drivers yet. I would like to
learn how to do that too.
I am quite experienced in writing low level code. Some hints on the
direction would be really great.
Regards,
Winston
|
|
From: Winston R. <win...@gm...> - 2018-07-03 06:36:44
|
Hi Kamil Szczygieł, Yes you are right. But in my windows 7 system eclipse did not recognize my PATH variables which I set in Windows Environment variables (which is in Advanced System settings). Only after I set those PATH variables inside Eclipse I could build the project. Before that I kept getting error saying "make.exe not found in PATH bla bla" Regards, Winston. On Tue, Jul 3, 2018 at 2:30 PM Kamil Szczygieł <dis...@di...> wrote: > On Mon, 2018-07-02 at 20:10 +0800, Winston Rodrigues wrote: > > There is one step missing in Eclipse configuration guide. > > > > Please add this one. > > Hello Winston! > > The article you mentioned is the second part of a series: > 1. "ARM toolchain for Windows" > http://distortos.org/documentation/arm-toolchain-windows/ > 2. "Creating and configuring a project in Eclipse" > http://distortos.org/documentation/creating-configuring-project-eclipse/ > 3. "Eclipse debugging setup for ARM microcontrollers" > > http://distortos.org/documentation/eclipse-debugging-setup-arm-microcontrollers/ > > (I should also provide an alternate version of first article for Linux) > > In the first article there's a chapter called "Add tools to PATH > environment variable" and in there I recommend to add all tools (gcc > toolchain, kconfig-frontends, MSYS2) to system's PATH variable. This is > definitely not the only possible solution. Your method of setting that > via Eclipse's project settings is also a possibility. However using > Eclipse for environment variables has a serious flaw (at least in my > opinion, when using my "workflow"), that it affects only the tools you > run via Eclipse. For 99% of cases this is not a big issue, as you build > and debug the project in Eclipse anyway, but `make menuconfig` is > something you should be starting from the terminal (like `cmd.exe` in > Windows), not from Eclipse (I think it won't work anyway when started > from Eclipse, but I may be wrong here). For `make menuconfig` to work > you need at least MSYS2 and kconfig-frontends in system's PATH > variable, so no use in setting that again in Eclipse... > > One of my goals for these 3 articles was to show the easiest way that I > know. This is definitely not "the only way" and neither it is "the best > way" - just a way which can be described in a small number of steps. > > Unless your suggestion is about something completely different and > without the modification you mentioned the project does not build? > Please let me know if that's the case! > > BTW - if you have suggestions for improving the articles just let me > know. Or maybe there's some specific topic that you think should be > covered on the website? > > Regards, > Kamil Szczygieł > |
|
From: Kamil S. <dis...@di...> - 2018-07-03 06:31:00
|
On Mon, 2018-07-02 at 20:10 +0800, Winston Rodrigues wrote: > There is one step missing in Eclipse configuration guide. > > Please add this one. Hello Winston! The article you mentioned is the second part of a series: 1. "ARM toolchain for Windows" http://distortos.org/documentation/arm-toolchain-windows/ 2. "Creating and configuring a project in Eclipse" http://distortos.org/documentation/creating-configuring-project-eclipse/ 3. "Eclipse debugging setup for ARM microcontrollers" http://distortos.org/documentation/eclipse-debugging-setup-arm-microcontrollers/ (I should also provide an alternate version of first article for Linux) In the first article there's a chapter called "Add tools to PATH environment variable" and in there I recommend to add all tools (gcc toolchain, kconfig-frontends, MSYS2) to system's PATH variable. This is definitely not the only possible solution. Your method of setting that via Eclipse's project settings is also a possibility. However using Eclipse for environment variables has a serious flaw (at least in my opinion, when using my "workflow"), that it affects only the tools you run via Eclipse. For 99% of cases this is not a big issue, as you build and debug the project in Eclipse anyway, but `make menuconfig` is something you should be starting from the terminal (like `cmd.exe` in Windows), not from Eclipse (I think it won't work anyway when started from Eclipse, but I may be wrong here). For `make menuconfig` to work you need at least MSYS2 and kconfig-frontends in system's PATH variable, so no use in setting that again in Eclipse... One of my goals for these 3 articles was to show the easiest way that I know. This is definitely not "the only way" and neither it is "the best way" - just a way which can be described in a small number of steps. Unless your suggestion is about something completely different and without the modification you mentioned the project does not build? Please let me know if that's the case! BTW - if you have suggestions for improving the articles just let me know. Or maybe there's some specific topic that you think should be covered on the website? Regards, Kamil Szczygieł |
|
From: Winston R. <win...@gm...> - 2018-07-02 12:10:24
|
Hi Kamil Szczygieł, There is one step missing in Eclipse configuration guide. Please add this one. [image: image.png] Regards, Winston On Mon, Jul 2, 2018 at 5:50 AM Kamil Szczygieł <dis...@di...> wrote: > Hello all! > > Development leading to release of distortos 0.6.0 took a bit longer > than planned, but after almost 10 months and over 500 commits – here it > is! Just as usual, main release is accompanied with snapshots of > distortosExamples and distortosTemplateSubfolder with 20180701 > timestamps. > > Highlights: > - support for STM32L4 family; > - YAML-based board generator; > - support for NUCLEO-L432KC board with STM32L4 chip; > - support for NUCLEO-L476RG board with STM32L4 chip; > - support for NUCLEO-F446RE board with STM32F4 chip; > - removal of support for using tup to build the project; > - initial support for using CMake to build the project; > - initial version of C-API for condition variables, mutexes and > semaphores; > > News article about the 0.6.0 release > http://distortos.org/news/distortos-0-6-0-released/ > > Downloads > http://distortos.org/files/distortos-0.6.0.7z > http://distortos.org/files/distortos-0.6.0.tar.xz > http://distortos.org/files/distortosExamples-20180701.7z > http://distortos.org/files/distortosExamples-20180701.tar.xz > http://distortos.org/files/distortosTemplateSubfolder-20180701.7z > http://distortos.org/files/distortosTemplateSubfolder-20180701.tar.xz > > Changelogs > http://distortos.org/distortos-change-log/#0.6.0 > http://distortos.org/distortosexamples-change-log/#20180701 > http://distortos.org/distortostemplatesubfolder-change-log/#20180701 > > Regards, > Kamil Szczygieł > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > distortos-development mailing list > dis...@li... > https://lists.sourceforge.net/lists/listinfo/distortos-development > |
|
From: Kamil S. <dis...@di...> - 2018-07-01 21:50:13
|
Hello all! Development leading to release of distortos 0.6.0 took a bit longer than planned, but after almost 10 months and over 500 commits – here it is! Just as usual, main release is accompanied with snapshots of distortosExamples and distortosTemplateSubfolder with 20180701 timestamps. Highlights: - support for STM32L4 family; - YAML-based board generator; - support for NUCLEO-L432KC board with STM32L4 chip; - support for NUCLEO-L476RG board with STM32L4 chip; - support for NUCLEO-F446RE board with STM32F4 chip; - removal of support for using tup to build the project; - initial support for using CMake to build the project; - initial version of C-API for condition variables, mutexes and semaphores; News article about the 0.6.0 release http://distortos.org/news/distortos-0-6-0-released/ Downloads http://distortos.org/files/distortos-0.6.0.7z http://distortos.org/files/distortos-0.6.0.tar.xz http://distortos.org/files/distortosExamples-20180701.7z http://distortos.org/files/distortosExamples-20180701.tar.xz http://distortos.org/files/distortosTemplateSubfolder-20180701.7z http://distortos.org/files/distortosTemplateSubfolder-20180701.tar.xz Changelogs http://distortos.org/distortos-change-log/#0.6.0 http://distortos.org/distortosexamples-change-log/#20180701 http://distortos.org/distortostemplatesubfolder-change-log/#20180701 Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2018-02-03 21:17:05
|
On Sat, 2018-02-03 at 15:09 -0500, Trampas Stern wrote: > I was looking through some FreeRTOS documentation on how the Cortex M > processors work with RTOSs. I personally like the ground up approach > to learning new things... I was hoping that maybe you had a blog > going through the ground up on DISTOREC? > > I will go through and see if I can figure it out either way... Generally all RTOSes work (more or less) the same. The "mechanics" is mostly identical - PendSV is used for context switching and SysTick is used as periodic timer. If anything wants to force a context switch, it has to trigger PendSV interrupt. There may be some minor differences in this particular aspect, but the general concept of context switching is pretty much identical in any RTOS. It is not even very specific to ARM Cortex-M - obviously the tiny details (assembly instructions, interrupts used, registers that need to be saved, ...) will be different, but the approach (push registers to stack, save stack pointer of thread "A", load stack pointer of thread "B", pop registers from stack) is still identical. Unless you are interested in something other than context switching? This definitely is one of a very few architecture-specific things in an RTOS. Huge majority of code is architecture-agnostic - it can be seen by how little code is in the architecture folder (at least I think there's "little" (; ). https://github.com/DISTORTEC/distortos/tree/master/source/architecture/ARM/ARMv6-M-ARMv7-M If you ignore the stuff which is required for implementation of POSIX signals (which would be SVC interrupt, supervisorCall and requestFunctionExecution), all that is left is: - code for context switching (PendSV), - code to request context switching, - code related to periodic tick interrupt (SysTick and startScheduling), - code to initialize thread's stack, - various low-level initializers (including reset handler), - code to enable, disable and restore interrupt masking (used for critical sections), - function which tells whether you are in interrupt context (used in various integrity checks). Please let me know if you have some specific questions, as the topic you mention would nicely fill a small book, so the scope is a bit too large for an e-mail (; Regards, KSz |
|
From: Trampas S. <tr...@gm...> - 2018-02-03 20:09:50
|
I was looking through some FreeRTOS documentation on how the Cortex M processors work with RTOSs. I personally like the ground up approach to learning new things... I was hoping that maybe you had a blog going through the ground up on DISTOREC? I will go through and see if I can figure it out either way... Thanks Trampas On Sat, Feb 3, 2018 at 12:01 PM, Kamil Szczygieł <dis...@di...> wrote: > On Sat, 2018-02-03 at 11:46 -0500, Trampas Stern wrote: > > I am new to RTOS and distortos, does someone have some good > > documentation on how distortos works and how to get started? > > Hello Trampas! > > You can find some documentation on project's website > http://distortos.org/ > > Of special interest are following articles: > http://distortos.org/documentation/arm-toolchain-windows/ > http://distortos.org/documentation/creating-configuring-project-eclipse/ > > There's also API reference generated with doxygen > http://distortos.org/api-reference/ > > Some info can also be obtained from the changelog in the repository > https://github.com/DISTORTEC/distortos/blob/master/CHANGELOG.md > > Generally I'm afraid that documentation and guides are not very good at > this moment... However if you need some guidance or if you have > specific questions I will be more than happy to help you and answer > your questions. > > As to "how distortos works" - it basically works in the same way as any > other RTOS. When a context switch is required it is performed in > interrrupt (PendSV in case of ARMv6-M and ARMv7-M) - registers of first > thread are "pushed" on its stack (1), then its stack pointer is saved > in its thread control block (2), next thread control block is marked as > active (3), its stack pointer register is restored (4), then the > registers of this thread are "popped" from stack (5). This is one of > very few pieces of code in distortos which is (partially) written in > assembly language, thus not very friendly for a beginner. > > (1) - https://github.com/DISTORTEC/distortos/blob/ > 7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/architecture/ARM/ARMv6-M- > ARMv7-M/ARMv6-M-ARMv7-M-PendSV_Handler.cpp#L149 > > (2) - https://github.com/DISTORTEC/distortos/blob/ > 7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/scheduler/ > Scheduler.cpp#L254 > > (3) - https://github.com/DISTORTEC/distortos/blob/ > 7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/scheduler/ > Scheduler.cpp#L255 > > (4) - https://github.com/DISTORTEC/distortos/blob/ > 7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/scheduler/ > Scheduler.cpp#L257 > > (5) - https://github.com/DISTORTEC/distortos/blob/ > 7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/architecture/ARM/ARMv6-M- > ARMv7-M/ARMv6-M-ARMv7-M-PendSV_Handler.cpp#L162 > > Regards, > Kamil Szczygiel > |
|
From: Kamil S. <dis...@di...> - 2018-02-03 17:59:36
|
On Sat, 2018-02-03 at 11:46 -0500, Trampas Stern wrote: > I am new to RTOS and distortos, does someone have some good > documentation on how distortos works and how to get started? Hello Trampas! You can find some documentation on project's website http://distortos.org/ Of special interest are following articles: http://distortos.org/documentation/arm-toolchain-windows/ http://distortos.org/documentation/creating-configuring-project-eclipse/ There's also API reference generated with doxygen http://distortos.org/api-reference/ Some info can also be obtained from the changelog in the repository https://github.com/DISTORTEC/distortos/blob/master/CHANGELOG.md Generally I'm afraid that documentation and guides are not very good at this moment... However if you need some guidance or if you have specific questions I will be more than happy to help you and answer your questions. As to "how distortos works" - it basically works in the same way as any other RTOS. When a context switch is required it is performed in interrrupt (PendSV in case of ARMv6-M and ARMv7-M) - registers of first thread are "pushed" on its stack (1), then its stack pointer is saved in its thread control block (2), next thread control block is marked as active (3), its stack pointer register is restored (4), then the registers of this thread are "popped" from stack (5). This is one of very few pieces of code in distortos which is (partially) written in assembly language, thus not very friendly for a beginner. (1) - https://github.com/DISTORTEC/distortos/blob/7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M-PendSV_Handler.cpp#L149 (2) - https://github.com/DISTORTEC/distortos/blob/7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/scheduler/Scheduler.cpp#L254 (3) - https://github.com/DISTORTEC/distortos/blob/7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/scheduler/Scheduler.cpp#L255 (4) - https://github.com/DISTORTEC/distortos/blob/7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/scheduler/Scheduler.cpp#L257 (5) - https://github.com/DISTORTEC/distortos/blob/7d58c175f4fd4e2150033fbddf662f69ff1dd910/source/architecture/ARM/ARMv6-M-ARMv7-M/ARMv6-M-ARMv7-M-PendSV_Handler.cpp#L162 Regards, Kamil Szczygiel |
|
From: Trampas S. <tr...@gm...> - 2018-02-03 16:46:39
|
I am new to RTOS and distortos, does someone have some good documentation on how distortos works and how to get started? Thanks Trampas |
|
From: Kamil S. <dis...@di...> - 2017-09-14 20:50:41
|
Hello! Half a year of intensive development, represented by over 600 commits, led to the fifth release of distortos – 0.5.0. As previously, snapshots of distortosExamples and distortosTemplateSubfolder were also created with a 20170914 timestamp. Quick highlight of the most important changes: - support for STM32L0 family of microcontrollers, - support for NUCLEO-L073RZ board with STM32L0 chip, - support for 32F769IDISCOVERY board with STM32F7 chip, - board generator using devicetree files (*.dts), written as Python scripts using ply (for lexing and parsing) and Jinja2 template engine (for rendering output files), - GDB pretty-printers for all lists and queues used in distortos. News article about the 0.5.0 release http://distortos.org/news/distortos-0-5-0-released/ Downloads http://distortos.org/files/distortos-0.5.0.7z http://distortos.org/files/distortos-0.5.0.tar.xz http://distortos.org/files/distortosExamples-20170914.7z http://distortos.org/files/distortosExamples-20170914.tar.xz http://distortos.org/files/distortosTemplateSubfolder-20170914.7z http://distortos.org/files/distortosTemplateSubfolder-20170914.tar.xz Changelogs http://distortos.org/distortos-change-log/#0.5.0 http://distortos.org/distortosexamples-change-log/#20170914 http://distortos.org/distortostemplatesubfolder-change-log/#20170914 Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2017-04-08 18:04:08
|
Hi! Today I have made some commits to make distortos ready for upcoming GCC 7 (full 7.1.0 release is expected this month). If you want to try this experimental GCC version yourself, just download the script and build it (; https://github.com/FreddieChopin/bleeding-edge-toolchain/tree/gcc-7-experimental --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- $ arm-none-eabi-gcc --version arm-none-eabi-gcc (bleeding-edge-toolchain) 7.0.1 20170402 (experimental) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- >8 --- The script is able to produce a working toolchain for Linux. It is also possible to cross-compile a toolchain for Windows (32-bit or 64-bit) - either in Linux or in "Bash on Ubuntu on Windows" (I've heard it can be done, but the process is painfully slow - who would expect that? (; ). I've done some quick tesking of the toolchain with all chip types (in a few optimization levels) and I believe it is working fine (; Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2017-04-06 17:05:38
|
Hi! The most recent gperf release – 3.1, released on 5th January 2017 - breaks the “standard” kconfig-frontends build procedure. Read more about the problem and the solution in the news article: http://distortos.org/news/updated-build-instructions-kconfig-frontends/ Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2017-03-11 17:13:13
|
Hello! Fifteen weeks and 431 commits after the previous one, fourth release of distortos – 0.4.0 – was published. Usual snapshots of distortosExamples and distortosTemplateSubfolder – timestamped as 20170311 – were uploaded simultaneously. Most important features of the new release (at least in my opinion) are: - complete support for STM32F7 chips, - various options related to stack overflow detection, - option to enable context check of functions which cannot be used from interrupts. You can download source packages in 7z and tar.xz formats from Downloads section of the website ( http://distortos.org/ ) or using the links below: http://distortos.org/files/distortos-0.4.0.7z http://distortos.org/files/distortos-0.4.0.tar.xz http://distortos.org/files/distortosExamples-20170311.7z http://distortos.org/files/distortosExamples-20170311.tar.xz http://distortos.org/files/distortosTemplateSubfolder-20170311.7z http://distortos.org/files/distortosTemplateSubfolder-20170311.tar.xz Change log for distortos 0.4.0: http://distortos.org/distortos-change-log/#0.4.0 Change log for distortosExamples 20170311: http://distortos.org/distortosexamples-change-log/#20170311 Change log for distortosTemplateSubfolder 20170311: http://distortos.org/distortostemplatesubfolder-change-log/#20170311 Link to news article on the website: http://distortos.org/news/distortos-0-3-0-released/ Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2016-11-25 05:11:20
|
Hello! It took almost 500 commits and half a year of effort to publish third release of distortos – 0.3.0. As previously, snapshots of distortosExamples and distortosTemplateSubfolder – both with 20161124 timestamp – accompany the main release. You can download source packages in 7z and tar.xz formats from Downloads section of the website ( http://distortos.org/ ) or using the links below: http://distortos.org/files/distortos-0.3.0.7z http://distortos.org/files/distortos-0.3.0.tar.xz http://distortos.org/files/distortosExamples-20161124.7z http://distortos.org/files/distortosExamples-20161124.tar.xz http://distortos.org/files/distortosTemplateSubfolder-20161124.7z http://distortos.org/files/distortosTemplateSubfolder-20161124.tar.xz Change log for distortos 0.3.0: http://distortos.org/distortos-change-log/#0.3.0 Change log for distortosExamples 20161124: http://distortos.org/distortosexamples-change-log/#20161124 Change log for distortosTemplateSubfolder 20161124: http://distortos.org/distortostemplatesubfolder-change-log/#20161124 Link to news article on the website: http://distortos.org/news/distortos-0-3-0-released/ Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2016-05-03 20:22:06
|
Hello! A little over two months and about 400 commits after previous one, second release of distortos – 0.2.0 – was published. This release is accompanied by snapshots of distortosExamples and distortosTemplateSubfolder – both with 20160503 timestamp . You can download source packages in 7z and tar.xz formats from Downloads section of the website ( http://distortos.org/ ) or using the links below: http://distortos.org/files/distortos-0.2.0.7z http://distortos.org/files/distortos-0.2.0.tar.xz http://distortos.org/files/distortosExamples-20160503.7z http://distortos.org/files/distortosExamples-20160503.tar.xz http://distortos.org/files/distortosTemplateSubfolder-20160503.7z http://distortos.org/files/distortosTemplateSubfolder-20160503.tar.xz Change log for distortos 0.2.0: http://distortos.org/distortos-change-log/#0.2.0 Change log for distortosExamples 20160503: http://distortos.org/distortosexamples-change-log/#20160503 Change log for distortosTemplateSubfolder 20160503: http://distortos.org/distortostemplatesubfolder-change-log/#20160503 Link to news article on the website: http://distortos.org/news/distortos-0-2-0-released/ Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2016-04-13 22:50:32
|
Hello! In the last few weeks distortos gained support for ARMv6-M architecture (ARM Cortex-M0(+) and ARM Cortex-M1 cores). The first chip family added to distortos using this architecture is STM32F0. You can select any of 72 chips from that family in the Kconfig configuration system and they are all supported by source code of distortos. Total number of supported chips rose to 281! As usually, the changes include support and test configuration for a board with such chip – this time it is a very cheap NUCLEO-F091RC board with STM32F091RC microcontroller, which can run with frequency up to 48MHz. Menus implemented in Kconfig configuration tool allow you to configure chip’s clocks without writing a single line of code. This is obviously similar to other chip families supported by distortos – STM32F1 and STM32F4 – creating unified workflow for all of them. Link to original news item (which will most likely be updated and extended in the very near future): http://distortos.org/news/support-armv6-m-architecture-stm32f0-chips/ Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2016-03-06 17:40:03
|
Hello! New family of chips is supported by distortos since today! It is now possible to use any of 94 STM32F1 chips – they are all available in Kconfig configuration system and supported by source code. This addition increases total number of chips supported by distortos to 209. Merged changes include support and test configuration for NUCLEO-F103RB board with STM32F103RB chip (72MHz max). Configuration of chip’s clocks and PLLs can be done entirely in Kconfig configuration tool – just as for STM32F4. All selected options are verified either by Kconfig configuration tool or by compile-time checks in source code (static_assert(...) or preprocessor). The checks range from simple value verifications (whether the value is in allowed range), through dependency checks (e.g. you cannot select HSE clock as source of PLL without enabling it), through chip variations (e.g. allowed range for PLL multiplier is different for STM32F103 than for STM32F105 and STM32F107, additional PLLs are only present in STM32F105 or STM32F107) to validation of final setting (e.g. whether all clock-related options result in valid frequencies for the selected chip). All of that makes creating a wrong configuration (almost (; ) impossible, greatly simplifying new hardware bring-up and reducing time required to implement low-level chip initialization. News article on project's website: http://distortos.org/news/support-stm32f1-chips/ Regards, Kamil Szczygieł |
|
From: Kamil S. <dis...@di...> - 2016-02-27 18:58:52
|
On sob, 2016-02-27 at 18:47 +0100, Jasmin J. wrote: > Hello Kamil! > > Very impressive! > Congratulations! > > I am back from the Philippines since two weeks and very busy with > working. > So I haven't had time to work on "my things". > > I know how hard it is to keep on going such a project. I had no time > to look > to the source in detailed, but I know your perfectionism ;) > > I also have seen, that you have a new homepage for the project. > You are really amazing! > > I hope I will find the time to start playing with Distortos soon. > I have a Nuocleo STM32F091 and a STM32L152 here for porting and > tests. > > Best Regards, > Jasmin Hello Jasmin! Thanks for all the kind words! I hope that the source code is actually worthy of such admiration (; Please let me know what do you think about the current state of the project when you have the time to test it - quite a lot changed recently, so I think you may be positively surprised (; I was planning to do the first release for some time now, but there was always something more to fix or just something else (not related to the project) needed to be done ASAP, so the process took a while longer than I though. I hope that a tagged release will show that this project is ready for real-life use, but obviously with some caution. I'm sure that there are bugs or weird corner cases in the code, but more exposure (created by a tagged release) can only help with finding and solving them. No project is bug-free, right (; Actually I'll be doing a new project with STM32F4 and LwIP very soon. I plan to use distortos - we'll see how will that work out and whether this project was worth the 19 months of development (; There's still A LOT to be done, but - I hope I can say that - also quite a lot is already implemented and working fine. I have my own TODO list, but I'm also open to any suggestions for the features that are missing - even if I have them on my list, I'll know that they should have a highest priority. I can also share my TODO list here, so anyone could sort (change/improve/extend) it according to their own preferences, giving me some pointers on what features are considered most important. Any feedback is very appreciated! Regards, Kamil Szczygieł |
|
From: Jasmin J. <ja...@an...> - 2016-02-27 17:59:12
|
Hello Kamil! Very impressive! Congratulations! I am back from the Philippines since two weeks and very busy with working. So I haven't had time to work on "my things". I know how hard it is to keep on going such a project. I had no time to look to the source in detailed, but I know your perfectionism ;) I also have seen, that you have a new homepage for the project. You are really amazing! I hope I will find the time to start playing with Distortos soon. I have a Nuocleo STM32F091 and a STM32L152 here for porting and tests. Best Regards, Jasmin *********************************************************************** On 02/27/2016 12:04 AM, Kamil Szczygieł wrote: > Hello! > > Today first release of distortos (0.1.0), distortosExamples (20160226) > and distortosTemplateSubfolder (20160226) was completed! You can > download source packages in 7z and tar.xz formats from Downloads > section of http://distortos.org/ or using the links below: > > http://distortos.org/files/distortos-0.1.0.7z > http://distortos.org/files/distortos-0.1.0.tar.xz > http://distortos.org/files/distortosExamples-20160226.7z > http://distortos.org/files/distortosExamples-20160226.tar.xz > http://distortos.org/files/distortosTemplateSubfolder-20160226.7z > http://distortos.org/files/distortosTemplateSubfolder-20160226.tar.xz > > Change log for distortos 0.1.0 > https://github.com/DISTORTEC/distortos/blob/master/CHANGELOG.md#010---2016-02-26 > > Change log for distortosExamples 20160226 > https://github.com/DISTORTEC/distortosExamples/blob/master/CHANGELOG.md#20160226---2016-02-26 > > Change log for distortosTemplateSubfolder 20160226 > https://github.com/DISTORTEC/distortosTemplateSubfolder/blob/master/CHANGELOG.md#20160226---2016-02-26 > > News article on project's website > http://distortos.org/news/distortos-0-1-0-distortosexamples-20160226-and-distortostemplatesubfolder-20160226-released/#more-174 > > Regards, > Kamil Szczygieł > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 > _______________________________________________ > distortos-development mailing list > dis...@li... > https://lists.sourceforge.net/lists/listinfo/distortos-development > |
