Hi, every one:
I have write a blog about how to build the RTEMS on POK. However, the RTEMS
can't run on POK now. Here is my blog[1].
[1]. http://huaiyusched.github.io/rtems/2014/03/15/how-to-run-rtems-on-pok/
--
Best Regards.
Youren Shen.
___
rtems-dev
Hi,
On Sat, Mar 15, 2014 at 11:34 PM, Janek van Oirschot
wrote:
> Hello,
>
> Seeing any form of "hello world" pop up always feels euphoric when working
> with embedded software/hardware. Attached to this email is a screenshot of
> getting a customized hello world ("Hello RTEMS") application runni
On Mar 15, 2014, at 18:01 , Joel Sherrill wrote:
> There are three pieces and I may have confused you.
>
> + current stack in tree
> + some add on drivers with porting kit
> + new dual mode stack
>
> I do not think there is an smc driver in the add on kit. I just thought if
> you decided to
Hello,
On Sun, Mar 16, 2014 at 6:08 PM, Gedare Bloom wrote:
>
> That student is focusing on the effort to get RTEMS working within
> Pok. Implementing arinc 653 interfaces in RTEMS might still be useful.
I wouldn't mind implementing ARINC653 or ARINC653-p4 for RTEMS. The
problem would be that th
On Sun, Mar 16, 2014 at 5:49 PM, Janek van Oirschot
wrote:
> Hello,
>
> On Sun, Mar 16, 2014 at 6:08 PM, Gedare Bloom wrote:
>>
>> That student is focusing on the effort to get RTEMS working within
>> Pok. Implementing arinc 653 interfaces in RTEMS might still be useful.
>
> I wouldn't mind imple
Hello everybody,
we have a student (Premysl Houdek) who has interrest
in ARM based embedded systems. He has long term experience
with Cotex-M LPC based boards.
He has not used RTEMS yet but he likes idea to test it,
work on it and eventually use it in applications.
We have discussed possible sum
Hi Pavel,
Hopefully Sebastian may comment as he is most familiar with ARM, but
here are my two cents:
On Sun, Mar 16, 2014 at 7:40 PM, Pavel Pisa wrote:
> Hello everybody,
>
> we have a student (Premysl Houdek) who has interrest
> in ARM based embedded systems. He has long term experience
> with
Hi all,
I have updated my proposal on both melange[0] and github[1], if you have
any comment please tell me. Thank you!
Updates:
1. Modify the plan scheduling according to Gedare comments, thank you
Gedare!
2. Add a plan for 'Improve the classic CV capabilities, such as dealing
with priority inve
Hi Json,
Please remove _CORE from the score interfaces. This _CORE is not part
of the current Coding Conventions:
http://www.rtems.org/wiki/index.php/Coding_Conventions#SuperCore
For priority inversion, see
http://ertl.jp/~shinpei/conf/ospert13/slides/TommasoCucinotta.pdf and
http://ertl.jp/~shi