[J-core] Port Idea: Little Kernel

[BGB]

On 11/4/2017 10:24 AM, emanuel stiebler wrote:
> On 2017-11-04 05:15, Ken Phillis Jr wrote:
>> On Sat, Nov 4, 2017 at 5:58 AM, Francisco Javier Bizcocho Antúnez
>> <volkovdablo at gmail.com> wrote:
>>> Just adding to the Little Kernel topic:
>>> - RTEMS is also a great Real Time OS that I've been using for some 
>>> time.
>>> Quite small, but powerful. I actually took the SH4 port that they 
>>> have and I
>>> was in the process to make it boot on Dreamcast.
>>>
>>>
>>
>> I was suggesting the Little Kernel project since this kernel is not
>> under the GNU Public License ( GPL ). This license is troublesome for
>> embedded developers since a lot of embedded manufactures have a nasty
>> habit of failing to comply with the license conditions set forth by
>> the GPL.
>
> Please check:
>
> https://www.rtems.org/license
>
> if it fits you ...


FWIW, I was doing my own mini-OS, but FWIW, the use-cases I have in mind 
overlap both traditional RTOS use-cases (a lot of low-level 
timing-sensitive IO and "bit banging"), and have some need for a lot of 
computational work as well (some DSP type tasks).


for example, one imagined use-case would involve some amount of:
     process images, applying:
         Haar and Hadamard Transforms
             (A, B)=>(A+B, A-B)
             (A, B, C, D) => (A+B+C+D, A+B-C-D, A-B+C-D, A-B-C+D)
         multiply-accululate lots of stuff
             from irregular strides.
         a need to S-Curve the results of said MAC loops
         ...
     some amount of audio processing and synthesis.
     possibly a lot of this via the use of specialized SIMD extensions.

decided from refraining describing this stuff in more detail, mostly to 
avoid bothering people here with a lot of this. but, basically, one 
use-case I have imagined is basically to try to build something useful 
for motor-control and sensory-processing tasks in small robots.

a full-featured OS (like Linux) isn't really necessary, but more useful 
is to have something which can handle events with a fairly low latency, 
schedule event times accurately, and otherwise run other tasks (when not 
handling timing-sensitive events).


but, this is basically hobbyist-level stuff, and I ended up getting 
pretty caught up doing a parallel project (customized ISA variant, with 
customized C compiler, a customized mini-OS, and starting work on 
customized CPU cores), and had largely forgotten what I was originally 
wanting to do with all this...

granted, it still remains unproven if something can be made on an 
affordable FPGA which can match or beat doing similar on an ARM SoC via 
VFP or NEON (and comparably somewhat cheaper than using an FPGA).

it doesn't help though that making this sensory stuff work effectively 
(even with the power of an ARM SoC), is non-trivial (eg: infer depth 
from a pair of cameras in real time with "better than complete crap" 
resolution and quality; or make depth inference which works "in general" 
with a single camera; ... granted, it could be that I mostly just suck 
at this sort of thing).


or such...