Re: [distortos-development] Adding support for LPC17xx series / Adding new Drivers

[Winston R. <win...@gm...>]

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