Forums

RTOS popularity

Started by Philipp Klaus Krause December 26, 2015
On 31.12.2015 06:54, Joe Chisolm wrote:
> On Sun, 27 Dec 2015 09:16:11 +0100, Philipp Klaus Krause wrote: > >> On 27.12.2015 01:48, Joe Chisolm wrote: >>> On Sat, 26 Dec 2015 19:54:40 +0100, Philipp Klaus Krause wrote: >>> >>>> There are a lot of RTOSes around. I wonder which are the most used >>>> ones. >>>> In particular, I'm interested in the free ones supporting the STM8, >>>> which currently are: >>>> >>>> * OSA * atomthreads * ChibiOS * ScmRTOS >>>> >>>> But I'd also like to know about the general 8/16-bit situation. >>>> >>>> Philipp >>> >>> FreeRTOS http://www.freertos.org >>> >>> >> I see that people asked for a STM8 port a few times, and over ayear ago >> someone posted a port to the forum: >> http://interactive.freertos.org/entries/40887409-FreeRTOS-port-for-STM8- > micro-controller-and-IAR-compiler >> But there has been no activity otherwise. While FreeRTOS is certainly >> popular in general, it seems not so much for STM8. >> >> Philipp > > Are you locked into a 8 bit uC? Power, pin count, real estate issues?
The free toolchain for STM8 (SDCC, stm8flash, etc) has improved a lot recently. But there is no RTOS that can be used with it yet. Since I might find time to help porting one sometime, I was wondering which one it should be. So far I see three groups of RTOSes wrt. to this: 1) The mainstream ones, that are important, but do not have any STM8 port yet: - FreeRTOS - Contiki - RIOT 2) Others, that already have or had an STM8 port using a non-free toolchain: - atomthreads - ChibiOS - BuguRTOS 3) Others, that don't see much development any more, and in which documentation seems to be mostly in some language I don't know: - OSA - mipOS I guess I will put my attention on one from 2) first, then one from 1). Philipp
On 30.12.2015 20:10, Paul Colin Gloster wrote:
> On December 30th, 2015, Rickman sent: > |---------------------------------------------------------------------| > |"On 12/30/2015 1:20 PM, Nicholas Collin Paul de Gloucester wrote: | > |[�] > |> I advise against STMicroelectronics, as I documented via | > |> e.g. "Referees Often Miss Obvious Errors in Computer and Electronic| > |> Publications", "Accountability in Research: Policies and Quality | > |> Assurance", Volume 20, Issue 3. | > |> | > |> Regards, | > |> Paul Colin Gloster | > | | > |Is there some BS here?" | > |---------------------------------------------------------------------| > > No. There is BS in publications which STMicroelectronics contributed > to which I referred to in "Referees Often Miss Obvious Errors in > Computer and Electronic Publications". > > |---------------------------------------------------------------------| > |"I searched for this document and found it has nothing to | > |do with STM." | > |---------------------------------------------------------------------| > > Thou art mistaken. Cf. > WWW.FPGA-FAQ.com/archives/130600.html#130610
Well, I can't access "Referees Often Miss Obvious Errors in Computer and Electronic Publications" either from home or from Goethe-Universit�t Frankfurt. However it seems from WWW.FPGA-FAQ.com/archives/130600.html#130610 that this is just about some software quality issue. So afr, I'm not using any software from STMicroelectronics. I use their STM8 hardware. And write my own software for it, and use software others wrote for it. The STM8 architecture is not perfect, but IMO still a really good architecture. Philipp
Il 26/12/2015 19:54, Philipp Klaus Krause ha scritto:
> There are a lot of RTOSes around. I wonder which are the most used ones. > In particular, I'm interested in the free ones supporting the STM8, > which currently are: > > * OSA > * atomthreads > * ChibiOS > * ScmRTOS > > But I'd also like to know about the general 8/16-bit situation.
Maybe you already made this question to yourself. Anyway I make it: why do you need a RTOS on those kind of platforms?
El lunes, 4 de enero de 2016, 6:32:41 (UTC-3), pozz  escribi�:
> Il 26/12/2015 19:54, Philipp Klaus Krause ha scritto: > > There are a lot of RTOSes around. I wonder which are the most used ones. > > In particular, I'm interested in the free ones supporting the STM8, > > which currently are: > > > > * OSA > > * atomthreads > > * ChibiOS > > * ScmRTOS > > > > But I'd also like to know about the general 8/16-bit situation. > > Maybe you already made this question to yourself. Anyway I make it: why > do you need a RTOS on those kind of platforms?
hi, It is possible that ChibiOS/RT and ChibiOS/NIL be a good choice http://forum.chibios.org/phpbb/viewtopic.php?f=3&t=2708&sid=48be2b5b322a3823f6d163b469c46e6f Nestor
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-1589325151-1451928616=:20681
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On December 31st, 2015, Philipp Nicholas Krause sent:
|--------------------------------------------------------------------------=
-|
|"[. . .]                                                                  =
 |
|                                                                          =
 |
|Well, I can't access "Referees Often Miss Obvious Errors in Computer and  =
 |
|Electronic Publications" either from home or from Goethe-Universit=C3=A4t =
      |
|Frankfurt.                                                                =
 |
|However it seems from WWW.FPGA-FAQ.com/archives/130600.html#130610 that   =
 |
|this is just about some software quality issue. So afr, I'm not using     =
 |
|any software from STMicroelectronics. I use their STM8 hardware. And      =
 |
|write my own software for it, and use software others wrote for it. The   =
 |
|STM8 architecture is not perfect, but IMO still a really good architecture=
=2E|
|                                                                          =
 |
|Philipp"                                                                  =
 |
|--------------------------------------------------------------------------=
-|


Hi:

I was motivated to type this paper after we discovered a bug in
software from STMicroelectronics for designing NoC (on-chip-network)
hardware (and after finding mistakes in documentation by
STMicroelectronics and after finding lack of HDL skill of
STMicroelectronics). I recently looked at a non-8-bit not specifically
NoC document from STMicroelectronics, and it had an error. If you
would have a product from STMicroelectronics which would work and
which you would be happy with, then be happy, but I would not blindly
trust a datasheet.

Happy New Year.

Regards,
Paul Colin Gloster
--8323329-1589325151-1451928616=:20681--
On December 30th, 2015, Rickman sent:
|---------------------------------------------|
|"So you are "whistle-blowing" on buggy code?"|
|---------------------------------------------|

Buggy code kills persons via cars and could also kill persons via
defective equipment in hospitals and taxes should not be wasted on
such code.

Happy New Year.

Regards,
Nicholas Collin Paul de Gloucester
On 1/4/2016 12:34 PM, Paul Colin Gloster wrote:
> On December 30th, 2015, Rickman sent: > |---------------------------------------------| > |"So you are "whistle-blowing" on buggy code?"| > |---------------------------------------------| > > Buggy code kills persons via cars and could also kill persons via > defective equipment in hospitals and taxes should not be wasted on > such code.
I'm not going to argue this indefinitely, but I expect the code they are providing is not guaranteed for safety critical systems. I know I would never use code from any outside source and assume it is bug free. Further, I expect nearly every supplier of code has bugs in their code. Have you found any supplier of perfectly bug free code? So is the fact their code has bugs the only issue you have with STM? The actions you have taken seem rather extreme for that. -- Rick
On 1/4/2016 12:30 PM, Nicholas Collin Paul de Gloucester wrote:
> On December 31st, 2015, Philipp Nicholas Krause sent: > |---------------------------------------------------------------------------| > > |"[. . > .] | > | > | > |Well, I can't access "Referees Often Miss Obvious Errors in Computer > and | > |Electronic Publications" either from home or from > Goethe-Universität | > |Frankfurt. > | > |However it seems from WWW.FPGA-FAQ.com/archives/130600.html#130610 > that | > |this is just about some software quality issue. So afr, I'm not > using | > |any software from STMicroelectronics. I use their STM8 hardware. > And | > |write my own software for it, and use software others wrote for it. > The | > |STM8 architecture is not perfect, but IMO still a really good > architecture.| > | > | > |Philipp" > | > |---------------------------------------------------------------------------| > > > > Hi: > > I was motivated to type this paper after we discovered a bug in > software from STMicroelectronics for designing NoC (on-chip-network) > hardware (and after finding mistakes in documentation by > STMicroelectronics and after finding lack of HDL skill of > STMicroelectronics). I recently looked at a non-8-bit not specifically > NoC document from STMicroelectronics, and it had an error. If you > would have a product from STMicroelectronics which would work and > which you would be happy with, then be happy, but I would not blindly > trust a datasheet.
That is true for every device from every manufacturer. -- Rick
On Mon, 4 Jan 2016 13:12:55 -0500, rickman <gnuarm@gmail.com> wrote:

>On 1/4/2016 12:34 PM, Paul Colin Gloster wrote: >> On December 30th, 2015, Rickman sent: >> |---------------------------------------------| >> |"So you are "whistle-blowing" on buggy code?"| >> |---------------------------------------------| >> >> Buggy code kills persons via cars and could also kill persons via >> defective equipment in hospitals and taxes should not be wasted on >> such code. > >I'm not going to argue this indefinitely, but I expect the code they are >providing is not guaranteed for safety critical systems. I know I would >never use code from any outside source and assume it is bug free. >Further, I expect nearly every supplier of code has bugs in their code. > Have you found any supplier of perfectly bug free code? > >So is the fact their code has bugs the only issue you have with STM? >The actions you have taken seem rather extreme for that.
There are no such things as reliable hardware or software !! There are ways to use redundant systems, but in the long run, adding similar redundant channels doesn't increase the total system reliability. in practice it will reduce the total system reliability. Ten identical cooling systems in a NPP doesn't improve the total reliability, if all channels suffer from the same problem (such as contaminated fuel in all NPP emergency cooling systems.:-I.
On 1/4/2016 4:03 PM, upsidedown@downunder.com wrote:
> On Mon, 4 Jan 2016 13:12:55 -0500, rickman <gnuarm@gmail.com> wrote: > >> On 1/4/2016 12:34 PM, Paul Colin Gloster wrote: >>> On December 30th, 2015, Rickman sent: >>> |---------------------------------------------| >>> |"So you are "whistle-blowing" on buggy code?"| >>> |---------------------------------------------| >>> >>> Buggy code kills persons via cars and could also kill persons via >>> defective equipment in hospitals and taxes should not be wasted on >>> such code. >> >> I'm not going to argue this indefinitely, but I expect the code they are >> providing is not guaranteed for safety critical systems. I know I would >> never use code from any outside source and assume it is bug free. >> Further, I expect nearly every supplier of code has bugs in their code. >> Have you found any supplier of perfectly bug free code? >> >> So is the fact their code has bugs the only issue you have with STM? >> The actions you have taken seem rather extreme for that. > > There are no such things as reliable hardware or software !! > > There are ways to use redundant systems, but in the long run, adding > similar redundant channels doesn't increase the total system > reliability. in practice it will reduce the total system reliability. > > Ten identical cooling systems in a NPP doesn't improve the total > reliability, if all channels suffer from the same problem (such as > contaminated fuel in all NPP emergency cooling systems.:-I.
Or a faulty installation procedure for the cylinder head gaskets. It happened at the North Anna plant. When the plant disconnected from the grid during an earthquake, one of the backup generators failed because of this problem. It is not inconceivable that more of them would have failed. Rick -- Rick