Digispark competitor from Adafruit: Trinket

[dougal]

Adafruit has announced the 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

[digistump]

A few other differences:


Bootloader takes nearly 3k (instead of 2)
Regulator provides only 150ma (instead of 500)

[dougal]

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.

[MichaelMeissner]

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.

[Bluebie]

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!

[digistump]

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

[Bluebie]

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!

[digistump]

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!

[kehribar]

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.

[digistump]

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...

[Mark]

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

[Bluebie]

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.

[defragster]

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

[digistump]

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!

[Embedded-Creations]

(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.