Live data from Hacker News

Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

github.com

41–47 of 47 posts

Re: Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

#41
post #17

I thought this was about UC Berkeley's TinyOS: https://github.com/tinyos/tinyos-main This was a big deal in some academic circles in the early 2000s

I did my master thesis working with that in 2006. It was fun but challenging to work with a so primitive OS (no memory dynamic allocation, etc.) and so many bugs.

Re: Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

#42
post #22

The README mentions ARMv7-M, RISC-V, and AVR, but no actual SoCs or boards, and the source code contains unconditional inline assembly for Arm. Similarly, there are measurements of context switch time on RISC-V, while the scheduler is one big stub that doesn't even enter a task, only returns from itself using Arm-specific assembly [0]. The examples rely on this scheduler never returning, so there's no way any of them…

As a rule people do not read the linked content, they come to discuss the headline.

The first indication to me this was AI was simply the 'project structure' nonsense in the README. Why AI feel this strong need to show off the project's folder structure when you're going to look at it via the repo anyway is one of life's current mysteries.

Re: Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

#43
post #22

The README mentions ARMv7-M, RISC-V, and AVR, but no actual SoCs or boards, and the source code contains unconditional inline assembly for Arm. Similarly, there are measurements of context switch time on RISC-V, while the scheduler is one big stub that doesn't even enter a task, only returns from itself using Arm-specific assembly [0]. The examples rely on this scheduler never returning, so there's no way any of them…

As a rule people do not read the linked content, they come to discuss the headline. The first indication to me this was AI was simply the 'project structure' nonsense in the README. Why AI feel this strong need to show off the project's folder structure when you're going to look at it via the repo anyway is one of life's current mysteries.

Honestly, maybe this is the problem.

A web-of-trust-like implementation of votes and flags, as suggested below, might be a solution, but I feel like it's an overkill. I've recently flagged a different clickbait submission, about Android Developer Verification, whose title suggested a significant update but that merely linked to the same old generic page about the anti-feature that was posted here months prior. Around 100 points too, before a mod stepped in, changed the title, and took it down.

Maybe the upvote button is just too easy to reach? I have a feeling that hiding it behind CSS :visited could make a massive difference.

Re: Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

#44
post #22

The README mentions ARMv7-M, RISC-V, and AVR, but no actual SoCs or boards, and the source code contains unconditional inline assembly for Arm. Similarly, there are measurements of context switch time on RISC-V, while the scheduler is one big stub that doesn't even enter a task, only returns from itself using Arm-specific assembly [0]. The examples rely on this scheduler never returning, so there's no way any of them…

HN used to provide a really high signal to noise ratio for me, but it's degrading pretty quickly. There are new accounts below saying "hey I just learned what RTOS means, thanks!" I reflexively reload HN many times per day, but I'm wondering if I need a walled garden with some sort of curation of individuals - which sucks - to get the signal level I want.

This site is very much drowning in all the slop. It's over half of posts now I think, not just the "Show HN" posts. Those are 100% slop, as are all the non-show-hn new project announcements.

All the moderators have done is drop Show HN posts by newish accounts. It fixed nothing. I have to hope they have some ambitious plan along the lines of what you suggest.

Re: Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

#45
post #22

The README mentions ARMv7-M, RISC-V, and AVR, but no actual SoCs or boards, and the source code contains unconditional inline assembly for Arm. Similarly, there are measurements of context switch time on RISC-V, while the scheduler is one big stub that doesn't even enter a task, only returns from itself using Arm-specific assembly [0]. The examples rely on this scheduler never returning, so there's no way any of them…

HN used to provide a really high signal to noise ratio for me, but it's degrading pretty quickly. There are new accounts below saying "hey I just learned what RTOS means, thanks!" I reflexively reload HN many times per day, but I'm wondering if I need a walled garden with some sort of curation of individuals - which sucks - to get the signal level I want.

This probably isn't just an HN problem (GH's model is broken now). It's so cheap to make software that the previous process of releasing something new associated with a person is probably outdated. AI knows what sounds impressive too. So now we're drowning in software releases and attributing software to a person is meaningless.

Re: Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

#46
post #20
post #10

Question: Do you mean real time, meaning there is some kind of expectation of task switching time, nothing can stop other threads from executing, etc; or do you really mean embedded?

It doesn't implement task switching at all...

Can you back that up? It supports `os_task_create()`, `ps`, `top`, and the default for `MAX_TASKS` is 8.

Re: Show HN: TinyOS – A minimalist RTOS for Cortex-M written in C

#47
post #46
post #20

Earlier quoted context omitted.

It doesn't implement task switching at all...

Can you back that up? It supports `os_task_create()`, `ps`, `top`, and the default for `MAX_TASKS` is 8.

https://github.com/cmc-labo/tinyos-rtos/blob/2a47496047fdb45...

This codebase is essentially a stage prop, it has never been compiled nor executed.

Post reply on HN