RE: OS starting before main
Hi Will,
Thanks for your response, and sorry, the priorities were incorrect... "idle"
should be a lower priority "proc" but higher than "main". I will also attempt a
better explanation: In the example, the code in proc_task should only be
executed after `some_event()` returns truthy. If there is a scheduling point
after the perhaps poorly named "idle" task is initialised and before the "proc"
task is added to the task list, the execution switches to the "idle" task and
then even when `some_event()` returns truthy and releases the semaphore,
nothing is waiting on it so the task spins forever.
Corrected priorities:
> os_task_init(_task, "idle", idle_task_handler, NULL, 2,
> OS_WAIT_FOREVER, idle_stack, IDLE_STACK_SIZE);
>os_task_init(_task, "proc", proc_task_handler, NULL, 1,
> OS_WAIT_FOREVER, proc_stack, PROC_STACK_SIZE); }
Single threaded equivalent (desired) functionality:
>while (1) {
>if (some_event()) {
>//...
>}
> }
It is likely that being careful about the order of initialised tasks is the
answer and I just preferred it when I had control over when the OS started!
Also thanks for the assert advice.
Julian
-Original Message-
From: will sanfilippo [mailto:wi...@runtime.io]
Sent: 11 May 2017 18:45
To: dev@mynewt.incubator.apache.org
Subject: Re: OS starting before main
Julian:
Given your example I am a bit confused about some things. I think part of my
confusion is that you intialized the idle task to priority 1 and the other task
to priority 2. Priority 1 is higher priority than 2. I guess idle task to me is
something special but I realize this could just be an example name. So I will
go with the presumption that the priorities you have specified are correct:
idle_task_handler is the highest priority task and proc_task_handler is a task
lower in priority.
The other part of this example that confuses me is what happens in
some_event(). I presume that this function is waiting for some event to occur
and it is yielding if no event is available. If it is not, you will never yield
and you will be stuck in that task forever (and that does not have anything to
do with the order of initialization as far as I can see). If that call does
yield, I do not see the problem.
Anyway, and I probably should have said this first, yes, you have to be careful
about the order in which things are initialized. This does indeed get tricky at
times but should be possible given that sysinit has stages of initialization
and can be used to make sure that data structures are initialized prior to them
being called.
Just an FYI. I realize that you are just showing example code and probably
typed this up quickly, but just in case… I would not do the following: assert(
func_call() == OK ). This is because assert may get defined out and then you
are not making that function call. Better to do this:
rc = func_call();
assert(rc == OK);
I have been burnt by this in the past so I wanted to point it out.
> On May 11, 2017, at 2:41 AM, Julian Ingram <julian.ing...@imgtec.com> wrote:
>
> Hi all,
>
> Having moved the PIC32 port to the newer start-up method where os_start is
> called before main, there have been problems with a tick potentially
> occurring between task initialisations.
>
> Am I missing something here? If not, what is the standard fix, just be
> careful about the order of task initialisation, initialise them a critical
> section or?
>
> For example:
>
> void
> idle_task_handler(void *arg)
> {
>while (1) {
>if (some_event()) {
>os_sem_release();
>}
> }
> }
>
> void
> proc_task_handler(void *arg)
> {
>while (1) {
> int err = os_sem_pend(, OS_TIMEOUT_NEVER);
>// ...
> }
> }
>
> int
> main(int argc, char **argv)
> {
>sysinit();
>assert(os_sem_init(, 0) == OS_OK);
> os_task_init(_task, "idle", idle_task_handler, NULL, 1, OS_WAIT_FOREVER,
> idle_stack, IDLE_STACK_SIZE);
>// if a systick happens here I'm stuck in the idle task
> forever.
>os_task_init(_task, "proc", proc_task_handler,
> NULL, 2, OS_WAIT_FOREVER, proc_stack, PROC_STACK_SIZE); }
>
> Thanks,
>
> Julian Ingram
> Software Design Engineer
> MIPS Platforms
> Imagination Technologies Limited
> t: +44 (0)113 2429814
> www.imgtec.com<http://www.imgtec.com/>
>
OS starting before main
Hi all,
Having moved the PIC32 port to the newer start-up method where os_start is
called before main, there have been problems with a tick potentially occurring
between task initialisations.
Am I missing something here? If not, what is the standard fix, just be careful
about the order of task initialisation, initialise them a critical section or?
For example:
void
idle_task_handler(void *arg)
{
while (1) {
if (some_event()) {
os_sem_release();
}
}
}
void
proc_task_handler(void *arg)
{
while (1) {
int err = os_sem_pend(, OS_TIMEOUT_NEVER);
// ...
}
}
int
main(int argc, char **argv)
{
sysinit();
assert(os_sem_init(, 0) == OS_OK);
os_task_init(_task, "idle", idle_task_handler, NULL, 1, OS_WAIT_FOREVER,
idle_stack, IDLE_STACK_SIZE);
// if a systick happens here I'm stuck in the idle task forever.
os_task_init(_task, "proc", proc_task_handler, NULL, 2,
OS_WAIT_FOREVER, proc_stack, PROC_STACK_SIZE);
}
Thanks,
Julian Ingram
Software Design Engineer
MIPS Platforms
Imagination Technologies Limited
t: +44 (0)113 2429814
www.imgtec.com<http://www.imgtec.com/>
RE: [apache/incubator-mynewt-core] PIC32 port (#218)
Hi Marko,
The Microchip license:
/*-
*
* Copyright (c) 2014, Microchip Technology Inc. and its subsidiaries
("Microchip")
* All rights reserved.
* This software is developed by Microchip Technology Inc. and its
* subsidiaries ("Microchip").
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are
* met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
* 3. Microchip's name may not be used to endorse or promote products
* derived from this software without specific prior written
* permission.
*
* THIS SOFTWARE IS PROVIDED BY MICROCHIP "AS IS" AND ANY EXPRESS OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR PURPOSE ARE DISCLAIMED. IN NO EVENT
* SHALL MICROCHIP BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING BUT NOT LIMITED TO
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA OR PROFITS;
* OR BUSINESS INTERRUPTION) HOWSOEVER CAUSED AND ON ANY THEORY OF LIABILITY,
* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*
*-*/
The only other thing is the Microchip SDK is quite large (several GB), this
being the case it might be worth making it a separate package. We would likely
be dooming our users to having 2 copies of the SDK on their drives as the SDK
is installed with the compiler when you download it so it might be worth
picking out just the bits we need.
Thanks,
Julian
-Original Message-
From: marko kiiskila [mailto:ma...@runtime.io]
Sent: 30 March 2017 17:28
To: dev
Cc: apache/incubator-mynewt-core; Subscribed
Subject: Re: [apache/incubator-mynewt-core] PIC32 port (#218)
Hi Julian,
I’m sending this response to dev-list, as I think this discussion is good for
all :)
The way we’ve done this for other MCU SDKs is in one of the 2 ways:
a) create a package out of the SDK itself; this we did for nordic’s SDK,
https://github.com/runtimeco/mynewt_nordic/tree/master/hw/mcu/nordic_sdk
https://github.com/apache/incubator-mynewt-core/tree/develop/hw/mcu/stm/stm32f7xx
which are part of core repo; again, good license.
And for Atmel SAMD21master/hw/mcu/nordic_sdk>
Nordic’s SDK is not part of the core repository, because their license terms
prevent us from including it. It is free enough for us to host it somewhere
else though.
And for NXP,
https://github.com/apache/incubator-mynewt-core/tree/master/hw/mcu/nxp/src/ext/sdk-2.0-frdm-k64f_b160321
Their SDK license allowed us to include it in core.
https://github.com/runtimeco/mynewt_arduino_zero/tree/master/hw/mcu/atmel/samd21xx
This too had to be placed outside core repository, due to more restrictive
license.
We’ve packaged MCU SDKs as packages so that we have control over which version
we compile against.
I think we should take a look at microchip license, and see if the SDK part of
it is extractable. If it is, then good. If not, then we must consider
alternatives.
Thanks for doing this work, BTW.
—
M
> On Mar 30, 2017, at 5:19 AM, IMGJulian wrote:
>
> @IMGJulian commented on this pull request.
>
> In compiler/xc32/compiler.yml
> :
>
> > +# Unless required by applicable law or agreed to in writing,
> +# software distributed under the License is distributed on an # "AS
> +IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY # KIND, either
> +express or implied. See the License for the # specific language
> +governing permissions and limitations # under the License.
> +#
> +
> +compiler.path.cc: "xc32-gcc"
> +compiler.path.as: "xc32-gcc"
> +compiler.path.archive: "xc32-ar"
>
PIC32 port
Hello, Just to let you know, a PIC32 port is underway as of today. I will initially be targeting the PIC32MX470 using Microchip's XC32 toolchain. Thanks, Julian Ingram Software Design Engineer MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com<http://www.imgtec.com/>
MIPS port pull request
Hi All, There is now a MIPS port pull request: https://github.com/apache/incubator-mynewt-core/pull/123 Thanks, Julian Ingram Software Design Engineer MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com<http://www.imgtec.com/>
MIPS port (WIP)
Hello all, I have just committed a work in progress MIPS port here: https://github.com/IMGJulian/incubator-mynewt-core/tree/julian_dev I am currently working on some tests, and will make a pull request soon with a more polished version. Thanks, Julian Ingram Software Design Engineer MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com<http://www.imgtec.com/>
JIRA username
Hi All, I have been assigned the task of porting your OS to the MIPS platform. If you wouldn't mind adding my JIRA account to the MYNEWT project I would be grateful. My username is: JulianI Thanks, Julian Ingram Software Design Engineer MIPS Platforms Imagination Technologies Limited t: +44 (0)113 2429814 www.imgtec.com<http://www.imgtec.com/>
