You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mynewt.apache.org by Sterling Hughes <st...@apache.org> on 2015/12/15 21:11:12 UTC

Violating blinky

Last night, at roughly 10.45PM, I violated the sanctity of the blinky
project, adding newtmgr.

I'll send a separate note on newtmgr, which is pretty cool (it allows
you to easily add commands in a cross-protocol fashion -- it will work
over serial, IP and BLE.)

However, I've been using blinky as the default development project,
and I think we should start talking about which projects are what.  I
do think we need a default development project -- or a set of them,
and denote what they should be used for.  Given that most of our
documentation is centered around the blinky project, I think that
should be the simplest project of all of them, and literally just
blink the LED.

So, if I remove the shell & console from blinky where to put it?
Should we create a new project "dev_main" that is the main project?
How many platforms should that project support?

Should we break it into dev_main_sim, dev_main_arm, dev_main_XX.  What
does the breakdown look like in folks minds over time?

To start, I think we should dev_main, and have that support
simultaneously both sim and arm 32-bit platforms.  Then, I think next
is probably to have dev_main_sim, which can support a super-set of
dev_main, due to the increased code and memory footprint available on
sim.  Then, as we go along, we should look to break dev_main into more
and more sub-architectures.

But I could be convinced otherwise, what do folks think?  Are there
alternatives that you've seen work particularly well?

Cheers,

Sterling

Re: Violating blinky

Posted by will sanfilippo <wi...@runtime.io>.
> or a set of them,
> and denote what they should be used for.
I think the above statement is the key point (imo). I have not given this a ton of thought, but having a single development project or default one gets a bit tricky and unwieldy. I think we should have a set of projects and each of these projects does different things and has specific purposes. Blinky should remain inviolate in my opinion :-) The purpose of blinky should be a quick “get up and running with your HW and bsp” (for example). So I agree with you there.

If you want a project to add the shell/console for whatever reason, I would just create a project that uses it; no need to have a “dev_main” really. One question I would ask would be this: what would be the purpose of dev_main? Incorporate as much as possible for testing/demonstrating? Something that runs on as many platforms as possible?

Will

> On Dec 15, 2015, at 12:11 PM, Sterling Hughes <st...@apache.org> wrote:
> 
> Last night, at roughly 10.45PM, I violated the sanctity of the blinky
> project, adding newtmgr.
> 
> I'll send a separate note on newtmgr, which is pretty cool (it allows
> you to easily add commands in a cross-protocol fashion -- it will work
> over serial, IP and BLE.)
> 
> However, I've been using blinky as the default development project,
> and I think we should start talking about which projects are what.  I
> do think we need a default development project -- or a set of them,
> and denote what they should be used for.  Given that most of our
> documentation is centered around the blinky project, I think that
> should be the simplest project of all of them, and literally just
> blink the LED.
> 
> So, if I remove the shell & console from blinky where to put it?
> Should we create a new project "dev_main" that is the main project?
> How many platforms should that project support?
> 
> Should we break it into dev_main_sim, dev_main_arm, dev_main_XX.  What
> does the breakdown look like in folks minds over time?
> 
> To start, I think we should dev_main, and have that support
> simultaneously both sim and arm 32-bit platforms.  Then, I think next
> is probably to have dev_main_sim, which can support a super-set of
> dev_main, due to the increased code and memory footprint available on
> sim.  Then, as we go along, we should look to break dev_main into more
> and more sub-architectures.
> 
> But I could be convinced otherwise, what do folks think?  Are there
> alternatives that you've seen work particularly well?
> 
> Cheers,
> 
> Sterling


Re: Violating blinky

Posted by Christopher Collins <ch...@runtime.io>.
On Tue, Dec 15, 2015 at 12:11:12PM -0800, Sterling Hughes wrote:
[...]
> To start, I think we should dev_main, and have that support
> simultaneously both sim and arm 32-bit platforms.  Then, I think next
> is probably to have dev_main_sim, which can support a super-set of
> dev_main, due to the increased code and memory footprint available on
> sim.  Then, as we go along, we should look to break dev_main into more
> and more sub-architectures.

I think that sounds perfect.

Chris