package rename
soldair opened this issue · 7 comments
it seems we intend on keeping v1 and v2 sepperate.
should we publish independent v1 and v2 packages and a meta package thats the same interface as i proposed in https://github.com/Pinoccio/js-stk500
I was able to remove my reliance on serial port entirely so my interface changed up to all class methods where you pass in your stream object. This means I hold no global variables around the stream(serialport) object and it seems to have created a very testable modularized package that is ONLY concerned with the protocol. Im working with this to see if I like it or if there are problems, but so far so I feel pretty good about it. The interface for most users at this point is simply Protocol.bootload(stream, hex, board, callback)
Ideally stk500v2 would do the same. Then the meta package wont be an stk500 generalized package, but the nodedude module which can pick what stream to send it (probably nodeserial, but you never know) do any resets if that were ever to be needed again, and tie protocols to boards (and chips?).
Look forward to your evaluation of where stk500v1 is currently.
to clarify this issue is about the fact we already have an stk500 package on npm. we either delete it and publish 2 different modules stk500v1 and stk500v2 or leave it and it can just be meta package that we don't use.
I'm fairly certain stk500 v2 already supports this interface 👍. In that It doesn't have to be a real stream to fit your interface either just that something that has close and can emit data is passed in as the serialport.
Ah yes.
Seems like they call it stk500 and 8bit stk500 which im not sure how to make work:
https://www.google.com/search?q=stk500+protocol&oq=stk500+protocol&aqs=chrome..69i57.5081j0j7&sourceid=chrome&es_sm=91&ie=UTF-8
What are some options?
i'm happy with v1 "stk500v1" and v2 "stk500v2"
I was thinking that the stk500 repo would naturally point to the most
recent version of the protocol but because they are completely different
its important to specify
On Mon, Dec 22, 2014 at 1:31 PM, Jacob Rosenthal notifications@github.com
wrote:
Ah yes.
Seems like they call it stk500 and 8bit stk500 which im not sure how to
make work:https://www.google.com/search?q=stk500+protocol&oq=stk500+protocol&aqs=chrome..69i57.5081j0j7&sourceid=chrome&es_sm=91&ie=UTF-8
What are some options?—
Reply to this email directly or view it on GitHub
#3 (comment)
.
Yeah I think that would have made sense if Arduino didnt ship all million+ units with the old version :)
I dont like any of the options.
From the users point of view they just want to program arduinos so a meta stk500 package makes sense. But that breaks down basically immediately because there are tons of non avr arduinos now so again I come back to the proper place for multi programmer support is a nodedude module. Plus a meta package would have you doing require(stk500).v2 or require(stk500).v1 which Im not sure I love.
Giving up stk500 name to v2 doesnt make any more ( or less ) sense than stk500v1 having it as stk500v2 may be newer but stk500v1 is much much more common. Plus if we give up the name stk500 and dont do a meta package with it someone else will just take it, removing all the 'clarity' we tried to create.
For now I vote stk500v2 should be called just that.
OK sounds good
On Dec 22, 2014 1:57 PM, "Jacob Rosenthal" notifications@github.com wrote:
I dont like any of the options.
From the users point of view they just want to program arduinos so a meta
stk500 package makes sense. But that breaks down basically immediately
because there are tons of non avr arduinos now so again I come back to the
proper place for multi programmer support is a nodedude module. Plus a meta
package would have you doing require(stk500).v2 or require(stk500).v1 which
Im not sure I love.
Giving up stk500 name to v2 doesnt make any more ( or less ) sense than
stk500v1 having it as stk500v2 may be newer but stk500v1 is much much more
common. Plus if we give up the name stk500 and dont do a meta package with
it someone else will just take it, removing all the 'clarity' we tried to
create.For now I vote stk500v2 should be called just that.
—
Reply to this email directly or view it on GitHub
#3 (comment)
.