Digistump Forums
General Discussion => Other Arduino Talk => Topic started by: dougal on September 03, 2013, 02:12:23 pm
-
Adafruit has announced the Trinket:
http://learn.adafruit.com/introducing-trinket (http://learn.adafruit.com/introducing-trinket)
Very similar to Digispark, in some ways:
* Based on ATTiny85
* USB bootloader
* On-board power and signal LEDs
* $7.95 price-point
Some differences:
* Trinket comes in separate 3.3V and 5.0V versions, input voltage is 3.5V - 16V
* Trinket doesn't reprogram RST pin as a GPIO, so only 5 data pins available instead of 6
* Parallel pin rails, slightly more breadboard-friendly
* Reset button for entering bootloader
-
A few other differences:
Bootloader takes nearly 3k (instead of 2)
Regulator provides only 150ma (instead of 500)
-
Bah, for some reason, my original post failed, and when I went back in my browser and posted, it lost my closing comments...
I meant to say that I still preferred Digispark because of the extra I/O pin and wider range of input voltage, if nothing else. But it's still cool to see a new ATTiny85 cousin on the market.
Also, hadn't seen that the Trinket bootloader was so much bigger. That extra 1K gone can make a big difference. And I hadn't spotted the lower current output, either.
I guess my main question is: if you burned the Digispark micronucleus bootloader into the Trinket, would you basically get a Digispark, but with lower available current, and a button on P5? :)
I'm tempted to get one just to see if its USB works with my MBP. I'm going to have to find a way to program my Digisparks from my new laptop, eventually.
-
I guess my main question is: if you burned the Digispark micronucleus bootloader into the Trinket, would you basically get a Digispark, but with lower available current, and a button on P5? :)
According to the trinket documentation, the 6th pin is wired to the ATtiny's reset pin. Also, I imagine the extra space for the bootloader, is to allow loading from avrdude instead of the method digispark uses.
-
It looks like trinket's USB connector is wired the same, and it sounds like their clock settings are the same. Regardless the reset pin function is enabled so you can recover it using an ISP programmer. I'll bet uploading micronucleus with an ISP programmer will work just fine. Without having seen precisely how their bootloader manages interrupts and positions data I'm not yet comfortable advising people use the micronucleus 'upgrade' version to change the bootloader without having a programmer handy in case of error, but i'm 95% sure that'll work fine too.
It's an interesting design. The 3v version is especially appealing to me, and the uniquely narrow shape. Very cool! Kind of disappointing that their bootloader leaves users with about 88% as much space as micronucleus, all so the can be compatible with AVRdude while still requiring config changes (so you still have to mod your arduino ide...). If their problem was really just with the VID/PID thing, they could have trivially forked micronucleus and used their own VID/PID pair - which i think is weird and proprietary, but perhaps they have some business reasons for going the extra mile complying with USB-IF.
Good to see more competition! Shame they haven't obsoleted my work yet. Come on Adafruit! Make me irrelevant!
-
I guess my main question is: if you burned the Digispark micronucleus bootloader into the Trinket, would you basically get a Digispark, but with lower available current, and a button on P5?
According to the trinket documentation, the 6th pin is wired to the ATtiny's reset pin. Also, I imagine the extra space for the bootloader, is to allow loading from avrdude instead of the method digispark uses.
A reset button is just a button on that pin though, so if you change the fuses (like the Digispark does) then you have a button on P5 instead of Reset - Dougal, it seems that is exactly what you'd have - it probably has a pull up too.
@Bluebie - I'm not sure why they go to such great lengths to avoid ever acknowledging the Digispark exists, much less not build on micronucleus - but if you have a chance check out the bootloader code - it is both interesting and has lots of warnings about not being foolproof which is interesting since they say "We really worked hard on the bootloader process to make it rugged and foolproof, this board wont up and die on you in the middle of a project!" - I also wonder why they said that - do other attiny85 bootloaders die after 72 hours in your project? I'll have to look deeper as to how it detects whether to enter programming mode... if it doesn't need programming to be on the machine started first then that is a neat a feature that would make a better case for a button on the Digispark Pro
-
There's a register you can check which tells you if the AVR was started naturally, by power appearing on VCC, or if it was restarted by reset being pulled to ground. Some of the big brother usb bootloaders like USBaspLoader use this method to have instant startup of user code, so it only delays if you press the reset button, but you still have to be careful about timing with avrdude stuff, reset, then press upload, but don't wait too long or the device times out.
There are a lot of things which really disappoint me about this product. It's good that most of them can be fixed with a software update though! I also find it weird that they wont acknowledge the Digispark which clearly proved the market. I've repeatedly mentioned digispark and micronucleus to them over twitter and their live video casts and they just act like they've never heard of either of them and don't care. If it wasn't for embedded-creations pioneering USBaspLoader-tiny85 port there would have been no basis for anyone to expect it to be even possible to put a usb bootloader on a tiny85 chip. It didn't seem reasonable until Louis found a way! They could at least acknowledge that great work, even if they want to ignore the digispark for whatever mysterious reasons. It is annoying to me to see a competing product which is in many ways worse than the thing we already have. Tech is supposed to improve each time, but adafruit got too caught up in Not Invented Here ideology and was too precious about their USBtinyISP protocol to do what's best for this new product.
Still, 3.3v and a narrower design are both really appealing to me, as is a usb socket. Those are three things I think they got really right. Surely the benefit of having watched digispark and the areas people had difficulties. Whatever - it does us no harm for them to rake in the millions making subpar products. They will surely make more arduino libraries compatible with the loose timing afforded by the attiny85's internal oscillator, and that'll be great for us all!
-
Interesting - I just found this super simple presentation of the different reset states: http://web.engr.oregonstate.edu/~traylor/ece473/lectures/reset.pdfSince we can detect brownouts as well (and they result in a restart) any ideas on how to have a button induce a brownout without more than one other extra part ( due to space) - if we could have a button induce a brownout then it could be used as a restart button without us having to leave the restart pin - which would mean 15 i/o + restart button
3.3v and a narrower design are both really appealing to me, as is a usb socket
The newest revision of the Digispark Pro has a button (if we can make it useful), 15 i/o, mounting holes, micro usb plug (with thru hole reinforcement), and can be made in 3.3v or 5v from the same PCB - and it is smaller than the original Digispark!
-
Erik,
Correct PDF link is this I guess :) http://web.engr.oregonstate.edu/~traylor/ece473/lectures/reset.pdf
For utilising the button,
As I said before, you can unplug the system's ground connection with a transistor / mosfet. Which means, you can create a reset condition via power down - power up sequence. If you do that, you can use the /RESET button as a simple GPIO pin.
Below you can find my fast sketch. :) This uses NPN transistor and "low side switching" technique. Proper way to do that should be handled via a P-mosfet and a "high side switching" technique.
If this idea sounds good to you, we can work on creating an actual working reset button mechanism.
Best,
ihsan.
-
That is a good trick but I'm not sure I can ever fit 3 more parts on the board - it is backed full already and at 6/6 just to route it (8/8 for power).
I was thinking more of something like attaching the switch to a zener to ground on one side and Vcc on the other - when pressed it would drop vcc to the zener voltage - though we'd need a resistor in that to prevent it from drawing too much current - but that gets us closer...
-
Eric
Is it possible to find a normally closed switch.?
I've never actually looked for a minature one before, but it could break either vcc or ground to achieve your brownout condition.
Mark
-
So what is the idea with the button? It's just to let the bootloader do the hold button and plug in to program thing, or is it supposed to actually reset the device?
I'm just imagining maybe when the user presses the reset button, the pinchange interrupt fires and the bootloader checks if the button is pressed and if it is, it turns on the watchdog timer to 1ms or so. Then it jumps to the interrupt vector in the user program. If the user program isn't using the pinchange vector I think it defaults to jump to reset, which jumps back in to the bootloader and does that thing. If the user program does define an interrupt handler for that pinchange port, they can optionally turn the watchdog off at the start of their interrupt handler, allowing them to use the button for stuff. It'd add slightly more pinchange latency though and make the bootloader a tiny bit bigger.
A simpler version of this would be to just leave the pinchange interrupt enabled on that pin on startup, but not do the watchdog thing, so programs which don't use pinchange would automatically reset when the button is pressed, and programs which do use the pinchange interrupt would not have that functionality, but may choose to implement button reset in userspace. Users who wanted to use the button for GPIO could just turn the pinchange interrupt off for that pin or define an interrupt handler which does nothing.
When the device does restart it could check for the button being held as the micronucleus jumper version does now, and decide if it bootloads on that basis.
Is that roughly where people are wanting this feature to go?
I remain unsure of the utility of the button, but if it takes up no extra space I suppose it's kinda cute, and could be neat to ship the default program on the uberspark as a virtual keyboard which types something in when you press the button. Perhaps it opens a web browser and enters the url to a welcome page! Also it should blink (obviously!)
If you can, put the indicator LED beside the button, so it can be used to tempt the user to press the button. The page it opens could include instructions on how to setup the digispark software and stuff.
-
I read it as 'device reset' to facilitate programming and avoid manual power interruption for whatever reason.
@Bluebie - Software definable solution would be cool if it could be made to work in some way like you suggest.
I don't see any DigiDump details on pinchange - I found this: http://playground.arduino.cc/Main/PinChangeInt (http://playground.arduino.cc/Main/PinChangeInt)
-
When the device does restart it could check for the button being held as the micronucleus jumper version does now, and decide if it bootloads on that basis.
Is that roughly where people are wanting this feature to go?
Yes exactly what my idea for it was - a reset button, and a programming button ala the jumper version - basically a direct response to the trinket having a button - "We have a button, and you can still use the pin" was the goal - because that would be cool and the board is about 2mm bigger because of it at most, probably not any bigger at all given that the biggest problem is having space to route all the i/o lines.
I was packing orders and thinking "there must be a way to do this with the watchdog" sounds like there probably is - and I think that
A simpler version of this would be to just leave the pinchange interrupt enabled on that pin on startup, but not do the watchdog thing, so programs which don't use pinchange would automatically reset when the button is pressed, and programs which do use the pinchange interrupt would not have that functionality, but may choose to implement button reset in userspace. Users who wanted to use the button for GPIO could just turn the pinchange interrupt off for that pin or define an interrupt handler which does nothing.
Would probably be best - as it would keep it simple and only power users would hit the limitation - maybe the more complex approach could be super easy to activate from the sketch - like a class/library...
If you can, put the indicator LED beside the button, so it can be used to tempt the user to press the button. The page it opens could include instructions on how to setup the digispark software and stuff.
I have the led near the pin 1 - it is a super tight board to route (of course) as it is only 18x26.5mm - but I like the idea of hitting the button to open the how to page!
-
(I'm not writing this to be provocative. Being somewhat new to Open Hardware and attribution, I'm trying to understand more about it)
@digistump and @Bluebie I'm genuinely interested in why you think Adafruit should acknowledge the Digispark, and how you think they should do it. If you take the top features of the two designs (ATtiny85, Arduino IDE, USB, boot loader), of course they look similar. If you look in more detail, they were implemented in quite different ways. What about the Trinket makes it a derivative of the Digispark?
I was at the Open Hardware Summit last week, and there was a panel called "Implications of Open Source Business: Forking and Attribution". Nate from Sparkfun answered a vague audience question about the "controversy" between Sparkfun's Lillypad and Adafruit's Flora. I don't have a recording or transcript so I'm paraphrasing, but Nate basically said Adafruit releasing Flora was a good thing, and the competition renewed Sparkfun's development in Lillypad. Adafruit does acknowledge Lillypad on their Flora product page however it also says "Adafruit created the FLORA from scratch".
It's not always clear to me what level of attribution is needed for a project/product, and where it should be published. I think for an open hardware project that has used ideas from other open hardware projects, it's best to share as much information on where ideas came from as possible, and to not bury that information somewhere. One of the best examples of good attribution I've seen is from @kehribar's Little Wire: "This project is proudly and heavily based on: ..." put right on the homepage.
-
I don't think it is any desire for label acknowledgement - I think it is a combination of the lack of recognition that it even exists when asked directly, ignoring any mention of it, and perhaps more importantly - that the marketing language around the Trinket seems to imply things are wrong with the Digispark that aren't true at all
Do I think they should put "Inspired by the Digispark" on the product page/PCB/etc - definitely not, who knows if it was or not
Do I think they should acknowledge or at least not ignore our existence? yes
and perhaps even have a friendly email session of comparing notes, I'm sure that would have been helpful to them going into it - I would have happily shared all I knew
I think any foul air here is about attitude (very likely not isolated to just this product) and not at all about formal recognition
All that said, they can do what they want, and we can talk crap - in the end it doesn't change much of course, but generally I hope that open source companies will get along a bit better, especially the big with the small, but then again my complaints are a bit biased
More than all of the complaints and perhaps lost in them - I am very glad the attiny ecosystem is opening up!
-
@digistump I understand what you mean now. I won't try to read anything into why they didn't acknowledge the existence of the Digispark after knowing about it, but it is odd. It doesn't feel so "open" but who knows, maybe they're just too busy to keep up with what's out there or reach out. I didn't hear from you for the first time until after the Digispark Kickstarter campaign was already complete. I could have assumed you were just out to profit from my open source contribution, but knowing you now, I don't think that was the case.
I met Limor at the Open Hardware Summit, introducing myself as the person who made the first ATtiny85 VUSB boot loader. We had a very short conversation, but she volunteered that they didn't use my boot loader as they wanted AVRDUDE compatibility without modification, and she didn't mention micronucleus or the Digispark. She said something about paying for a signed Windows 8 driver, which is why I assume they have a unique VID/PID for the boot loader and don't want anyone else to use it. That might explain using a more standard vs an optimized protocol like micronucleus uses, though I don't know much about what a signed driver implies.
I also think its great the attiny ecosystem is growing. I'm glad to see that Adafruit's product is significantly different from the Digispark, so there's definitely room for competition based on features.
-
I am surprised that trinket arduino core is only one file with few lines.
-
The newest revision of the Digispark Pro has a button (if we can make it useful), 15 i/o, mounting holes, micro usb plug (with thru hole reinforcement), and can be made in 3.3v or 5v from the same PCB - and it is smaller than the original Digispark!
The micro usb is a major improvement IMO, and yes, the through hole reinforcement are important, I peeled two in the last month. ;-)
When will this pro version be available?
Will the button be used to initiate programming (this how the teensy works, no need for 5 sec delay). The 5 seconds delay is a major disadvantage in my next application.
I like the form factor of the Trinket.
-
The newest revision of the Digispark Pro has a button (if we can make it useful), 15 i/o, mounting holes, micro usb plug (with thru hole reinforcement), and can be made in 3.3v or 5v from the same PCB - and it is smaller than the original Digispark!
The micro usb is a major improvement IMO, and yes, the through hole reinforcement are important, I peeled two in the last month. ;-)
When will this pro version be available?
Will the button be used to initiate programming (this how the teensy works, no need for 5 sec delay). The 5 seconds delay is a major disadvantage in my next application.
I like the form factor of the Trinket.
I do tend to like micro-B female usb ports, since a lot of other devices have switched to it due to European laws mandating a common charging platform (except Apple). On the other hand, I've seen reports that a lot of micro-B usb in consumer electronics pull off if you are doing a lot of inserting and removing of the cord. You don't see it in cell phones as much because the plastic casing prevents some of the stress. I've seen speculation that the reason Adafruit has remained with the now deprecated mini-B port is it is more stable when soldered to the boards. For programming, I just bought the new generation of Cerebus USB cable from Sparkfun that has one cable that connects to the computer, and it has a mini-USB hub in it with the original B male (Uno), mini-B male (Trinket/Gemma), and micro-B (Teensy 3.0/DigiX). The old Cerebus just connected all three ports together, and it could have signaling issues with high speed devices. Unfortunately, it does not have standard A female for the Digispark. But for some things, the standard A male plug on the spark is better.
In terms of form factor, I much prefer standard dip packaging where you have all pins in parallel rows with 0.1" spacing, and separate the two rows by 0.2" of dead space so it fits in a standard breadboard. I dislike the positioning of the ground/power/vin on the spark, since it doesn't fit in some of the breadboards/perfboards I have collected (particularly the common 170 hole mini-bread board that has no power rails, but also some breadboards with power rails that aren't aligned with the normal pins). So in this regard, I prefer the teensy 3.0 over the spark (possibly the trinket too, if mine weren't bricked). One other thing I like about the Teensy 3.0 is by paying a little more, I can get it with the pins soldered in. I seem to have bad luck with soldering.
In terms of a button, hopefully it is better than the trinket/gemma. I have bricked both of mine, and I can't get them to reboot. I really, really, really do not want to have to remove my hands from the keyboard or mouse to press a button at just the right time to begin the programming. A common complaint on the Adafruit forums, is people not getting the timing just right, and having to repeat/rinse/lather until they get the board reprogrammed. In this regard, I prefer the Teensy 3.0 and Uno R3, in that I can start the compile/download in the IDE, and it automatically does the download without pressing a button or reconnecting the board at just the right time. Occasionally, I do have to press the reset button, but that is not the norm. On the Teensy 3.0 in fact, I like when I press the reset button, it does reflash the last program I compiled under the IDE.
-
Michael - this is some of the most constructive feedback I've had yet on the Pro - thanks! Also on the shortcoming of the Trinket.
The micro-Bs do have issues with board pull off, but we fixed that on the DigiX with a micro-B that is surface mount but has two posts extend through the board and soldered in place - I think it makes it more robust than most mini-Bs - I've swung them around by the cord to test (not recommended though!).
I wanted to give the Pro a standard A plug, I know some hate it, but I see it as the Digispark's trademark look - but it would have made it bigger - right now it is the same size as a Digispark so that saved area gave room for the extra pins and crystal. The original Digispark isn't going anywhere though.
The form factor will be backward compatible with the Digispark to allow the use of Digispark shields - but if you aren't using Digispark shields or your first shield on the stack is a Pro shield then you need not populate the 5V,GND,VIN pins with a header as they are also present in the main rows of pins - so it can be used in a DIP format and have all pins broken out.
Pre-soldered headers may happen - if we have the labor to do it, we will.
I can't disclose how our button is going to work - but it will be an addition to the existing micronucleus setup - in other words it will be very reliable and build on the reliability we've seen with the bootloader on all the Digisparks. Not to say Digisparks don't get bricked, but not because of the bootloader. I'm pretty sure it will work so that you have to hold it down for a second and then you can hit upload at any time, so no delicate timing.
In this regard, I prefer the Teensy 3.0 and Uno R3, in that I can start the compile/download in the IDE, and it automatically does the download without pressing a button or reconnecting the board at just the right time. Occasionally, I do have to press the reset button, but that is not the norm.
This is a great feature - but it is possible because these boards either use a USB to Serial converter or use a proper CDC implementation with a chip that supports a proper bootloader - my goal is to give as many options as possible. I have some ideas how a bigger core might be able to do this - so it may be an option for those who don't mind giving up another 1.5kish of space (the pro will have 16k total) - but the button will also be an option, and unplugging/plugging or using the prog tool will also be an option/is always a failsafe.
Thanks again for the feedback!
-
When will this pro version be available?
Will the button be used to initiate programming (this how the teensy works, no need for 5 sec delay). The 5 seconds delay is a major disadvantage in my next application.
I like the form factor of the Trinket.
Launching in Kickstarter in the next monthish - it is pretty ready to go, but I have to get DigiXs out the door first.
There will be several options for programming - button with no delay, delay (use button pun as i/o), and possibly the auto reset functionality seen on the Arduino Uno.
The form factor will be DIP/breadboard friendly but also backward compatible with Digispark shields when needed.
-
one good tip I was reading in the last weeks, that it is very recommended to put several vias in those regions, where connectors are soldered on the surface.
The vias work like small anchors for the pads, far away from through the hole, but ways better, than just relying on the connection between pad and pcb.
-
Michael - this is some of the most constructive feedback I've had yet on the Pro - thanks! Also on the shortcoming of the Trinket.
The micro-Bs do have issues with board pull off, but we fixed that on the DigiX with a micro-B that is surface mount but has two posts extend through the board and soldered in place - I think it makes it more robust than most mini-Bs - I've swung them around by the cord to test (not recommended though!).
Yeah, it may have been on the digiX comment list, I started reading about micro-B's pulling off.
I wanted to give the Pro a standard A plug, I know some hate it, but I see it as the Digispark's trademark look - but it would have made it bigger - right now it is the same size as a Digispark so that saved area gave room for the extra pins and crystal. The original Digispark isn't going anywhere though.
You might want to consider offering a USB 2.0 A to Micro B adapter in your store like this product: http://www.ebay.com/itm/New-USB-2-0-A-to-Micro-B-Standard-Mini-Data-Cable-Adapter-Male-Male-Black-/360660652301?pt=US_Video_Cables_Adapters&hash=item53f90cd10d (http://www.ebay.com/itm/New-USB-2-0-A-to-Micro-B-Standard-Mini-Data-Cable-Adapter-Male-Male-Black-/360660652301?pt=US_Video_Cables_Adapters&hash=item53f90cd10d)
The form factor will be backward compatible with the Digispark to allow the use of Digispark shields - but if you aren't using Digispark shields or your first shield on the stack is a Pro shield then you need not populate the 5V,GND,VIN pins with a header as they are also present in the main rows of pins - so it can be used in a DIP format and have all pins broken out.
It sounds like the best choice, allowing backward compatibility and such.
Pre-soldered headers may happen - if we have the labor to do it, we will.
I can't disclose how our button is going to work - but it will be an addition to the existing micronucleus setup - in other words it will be very reliable and build on the reliability we've seen with the bootloader on all the Digisparks. Not to say Digisparks don't get bricked, but not because of the bootloader. I'm pretty sure it will work so that you have to hold it down for a second and then you can hit upload at any time, so no delicate timing.
If you have to press a button or power cycle the board, at least the way you do it of having a prompt in the IDE telling you when to power cycle is better than the Trinket which you have to guess how long the compilation step will be and press the button just as the thing is ready to upload. I believe you have a longer timeout period than the trinket, and I can understand the pros and cons, that if you are primarily using the gadget and not programming, it takes to long for the timeout to finish. That seems to be a common complaint in the various boards.
In this regard, I prefer the Teensy 3.0 and Uno R3, in that I can start the compile/download in the IDE, and it automatically does the download without pressing a button or reconnecting the board at just the right time. Occasionally, I do have to press the reset button, but that is not the norm.
This is a great feature - but it is possible because these boards either use a USB to Serial converter or use a proper CDC implementation with a chip that supports a proper bootloader - my goal is to give as many options as possible. I have some ideas how a bigger core might be able to do this - so it may be an option for those who don't mind giving up another 1.5kish of space (the pro will have 16k total) - but the button will also be an option, and unplugging/plugging or using the prog tool will also be an option/is always a failsafe.
Thanks again for the feedback!
Yep, there are tradeoffs in each approach. The extra chip that the Uno has adds to the cost, but it allowed the USB/serial port to remain consistent while the newer processors break the connection when rebooting which can lead to periods when the connection isn't there and the USB port being renamed on the debug OS. In terms of debugging, the Uno was the best, because I could leave the serial port open, while with the teensy I have to re-establish the port, and lose the first few messages.
Speaking of debugging, it would be nice if somehow gdb support could be added into the processor stack like you have in the more commercial embedded development processes (or typical hosted environments). Yeah, as you get down the ATtiny85 boards like the spark, it becomes rather difficult (and if you have fewer pins like the gemma, nearly impossible).
-
I don't think it is any desire for label acknowledgement - I think it is a combination of the lack of recognition that it even exists when asked directly, ignoring any mention of it, and perhaps more importantly - that the marketing language around the Trinket seems to imply things are wrong with the Digispark that aren't true at al
I am no fan of Adafruit, trust me. Nonetheless, Digistump, get off your high freaking horse...
I agree that comparing notes with you guys would have been useful and beneficial... But, it's Adafruit's call to do so. Why, you ask? Well, if you dig deeper you'll see that the Trinket's firmware/bootloader was developed by non other than Frank Zhao who may or may not be a full time employee there. In case you didn't know, he is quite knowledgeable on USB bootloaders, and have been doing so (in an extremely Open-Source way) since way before your time:
http://forum.arduino.cc/index.php?topic=8571.0
He is the creator of USnoobie, and other Open Source projects, so before going on your little rant about how Adafruit neglected you, please do some reasearch. I like the Digispark, and I've seen how you guys have acknowledged the projects (usbasp, etc.) that you've used to build on... But yes, I had to create this account to set the record straight.
>:(
-
It's totally their call to do whatever they want, of course - just like we can rant about it - its not like we sued them, published an article about them, we talked about it in our community forums, so welcome to the discussion! I'm not sure what Frank Zhao's involvement or how long he has been in the game has to do with our disappointment that Adafruit ignored that the Digispark exists when asked about it. I'm very aware of his works, think he is a great member of the open source community, and didn't direct any of my rant towards him. His contributions to it are awesome, truly open source, and his intentions unquestionable - my rant was about Adafruit and in direct response to questions asked. The shortcoming of their bootloader, that I and others brought up aren't a challenge to Frank's competence - I didn't know he was involved until recently - but are fair criticisms, most echoed in the Adafruit forums - much as there are many valid criticism of the Digispark bootloader, no one is on a high horse for pointing out what we've done badly/could do better.
I'm not sure what record you are setting straight since I didn't snub Frank nor did I say Adafruit was obligated to share notes with us - is it that you feel we are on a high horse? I'd think this thread should be viewed in the context of several frustrated community members and in light of the fact that the issue was fairly quickly left to die and turned instead into suggestions on how to make the Digispark better - sure I had a good rant, but given that I dedicated about 1/1000 of my week to it and then moved on, it seems you may have read more importance into this thread then it actually has around here.
Of course, your rant is as welcome here as ours - but since you created an account it'd be great if you'd join us on other threads too!
I left the ranting part of this to die so I could continue working on our products, anyone can join in of course, but personally I'll leave it at this.
Thanks for your input and support of the Digispark! Welcome to our community, I hope you'll consider contributing on our other threads as well.
-Erik