> 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 <[email protected]> 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
