| Device Name | Flash (Kbytes) | Pin Count | Max. Operating Frequency | # of Touch Channels | Max I/O Pins | UART | ADC channels | Temp. Sensor | SRAM (Kbytes) | EEPROM (Bytes) | picoPower | Output Compare channels | Input Capture Channels | PWM Channels | 32kHz RTC | Calibrated RC Oscillator | Automotive Version available | Price with crystal, if needed | Packages |
| ATtiny1634 | 16 | 20 | 12 | 11 | 18 | 2 | 12 | No | 1 | 256 | Yes | 2 | 2 | 4 | Yes | Yes | No | $1.32 | MLF (WQFN) 20M1 20,SOIC (300mil) 20S2 20,WLCSP 12U1 12 |
| ATtiny167 | 16 | 20 | 16 | 8 | 16 | 1 | 11 | Yes | 0.5 | 512 | No | 3 | 1 | 9 | Yes | Yes | Yes | $1.45 | MLF (VQFN) 32M1-A 32,SOIC TG 20,TSSOP 6G 20 |
| ATtiny84 | 8 | 14 | 20 | 6 | 12 | 0 | 8 | Yes | 0.5 | 512 | No | 4 | 1 | 4 | No | Yes | Yes | $1.07 | MLF (WQFN) 20M1 20,PDIP 14P3 14,SOIC (150mil) 14S1 14 |
| ATtiny861 | 8 | 20 | 20 | 8 | 16 | 0 | 11 | Yes | 0.5 | 512 | No | 6 | 1 | 6 | No | Yes | Yes | $1.72 | MLF (VQFN) 32M1-A 32,PDIP 20P3 20,SOIC (300mil) 20S2 20 |
| ATtiny87 | 8 | 20 | 16 | 16 | 1 | 11 | Yes | 0.5 | 512 | No | 3 | 1 | 9 | Yes | Yes | Yes | $1.32 | MLF (VQFN) 32M1-A 32,SOIC TG 20,TSSOP 6G 20 |
1634 (ext crystal needed) - $0.97
[...]
The attiny1634 seems to be a winner here except that those prices might just be because it is new, and I do have to look at long term sourcing (or hoard them).
One argument might me, that all but the 84 and 861 are only available in soic , qfn and other smd-packages, while the others are still available as DIP.
gogol
Crystals run us about $0.35 each with loading capacitors. SO even with a crystal the 1634, 167, and 87 is a better deal.
however the adapters cost at least three times of the attiny ;-) at least when I compare the prices from my usual sources!
The discussed attinys are in the range of 1€ up to 2.5€ per single piece, the adaptors in the range from 5€ to 14€ :-(
@CBCracker - to run at 12.8Mhz the chip will have to have an internal oscillator that is user calibrated to 1% (same for 16.5Mhz) - and many of the chips don't have that. To run at 12Mhz an external crystal must be used because greater accuracy is required.
Thoughts on the Attiny167? I really like the idea of 16k which is why I'd prefer that to the 87
Regarding the 35 cent price of the crystal - 33 cents + 2x1 cent capacitors - sure you can find cheaper crystals but that price is for a SMT (wayyy smaller than the Tayda ones, which are as wide as a Digispark on their own) and not grey market - we carefully select what markets our parts come from, and that has paid off (failure rate remains about 0.2%) - Crystals and Attiny chips always come from reputable, guaranteed suppliers - to combine grey market crystals and super timing sensitive V-USB with production prices would be a bigger headache then I'd ever want to have.
Getting the other values to work with the internal oscillator would be very interesting - and might push me toward 1634 - though having the pro run at 16mhz is still very appealing - while we have many power users probably 75%+ of our customers are beginners with about 50% first time Arduino anything users - so the more compatible, straightforward, and easy to use it is, the better - and one of the goals with the Pro is to make it not just more powerful but easier to use as well
We'll probably bring reset out to a pin thoughIf you were very cunning with an earth right next to it, so using a two pin header and a screwdriver or other metallic item, would perform a reset....
The Attiny167 is looking like the chip.My vote is still with the ATtiny1634, though I understand the choice of the 167 for the official 16Mhz support. The 1634 can do 8Mhz at 2.7V, so clocking it to 16Mhz @5V would be no sweat. It's a bit cheaper too...
Thoughts?
Why do we want reset pin not to be IO? It seems like there's even less need for it on a chip with more progmem. bootloader upgrade script seems to work great.
@Bluebie - I'm with you on the reset pin - but I'm equally biased - I think the beauty of the Digispark is that we push the attiny to its limits whereas most projects use way more powerful MCUs than they need - I don't want to lose that spirit and disabling it by default encourages people to use any pin they can.
I will try to find time to scope it without the resistors/with caps. I'll have to read those specs in more detail and see the reasoning the v-usb folks gave (after all they might be making up for other things not being in spec, I believe that was brought up before)
If you leave it as a dedicated reset pin, users will be able to use one digispark to program another - something I think will be a big benefit for power users.I believe, that power users have no problems, doing what they want. For me the pin-restrictions of the digispark were the biggest problem, as four of six pins have different restrictions, causing firsthand unforeseen behaving of applications.
Regarding v-usb, Christian is a software guru, not hardware. The fact that the software work (especially the AVR assembly) is well documented while the electrical side is not supports that assertion. Jenna suggested they have a reason for not doing it the way I suggested, which seems to be the classic argument from authority logical fallacy.
One of my favorite quotes is from Einstein: "Unthinking respect for authority is the greatest enemy of truth."
Who said anything about formal training? I'm a university dropout (computer science). Look how far Bill Gates, Larry Ellison, & Mark Zuckerberg got without a degree!Regarding v-usb, Christian is a software guru, not hardware. The fact that the software work (especially the AVR assembly) is well documented while the electrical side is not supports that assertion. Jenna suggested they have a reason for not doing it the way I suggested, which seems to be the classic argument from authority logical fallacy.
One of my favorite quotes is from Einstein: "Unthinking respect for authority is the greatest enemy of truth."
[size=78%]It may be true that it is entirely possible - and it seems you certainly know what you're talking about, so I don't doubt you - like myself and most people here, Bluebie doesn't have any formal training in electronics - so that leaves most of us to follow advice and what resources we can get our hands on - it is great to have you as one of those resources on the hardware side of V-USB.[/size]
[/size][size=78%]So if you want to steer it in the direction of not requiring a pullup (if you do - I'd suggest making it a compile time option for backward compatibility) that would be really cool - I'll even send you some early Pros to play with if it works.[/size]OK, though I probably won't get to it until September. My first priority is to get the NRF24l01's working with the digistump on 4 wires like I promised you. For projects I do for fun, I tend to complete them to the point where I solve the tough problems, and then move on to the next challenge. It might not surprise you that I have ADHD. :-)
[/size][size=78%]One question on this - isn't USB suppose to have a 90 ohm impedance - so therefore a 20 ohm would be more appropriate than none?[/size][/quote
USB termination is a confusing topic, especially since a USB 2.0 host has an active transceiver which switches between voltages and impedances. We're only concerned with the electrical requirements of low & full speed ports. I highly recommend reading the Semtech application note I posted last month. Here it is again:
http://www.semtech.com/images/datasheet/usb_line_termination.pdf (http://www.semtech.com/images/datasheet/usb_line_termination.pdf)
Since the Digistump is normally plugged directly into a USB port, there is no cable impedance to match. The 45-Ohm PER END termination (90 Ohm total) you refer to is based on a 90 Ohm twisted pair cable between the transceivers. Some v-usb devices I've seen have a mini-B connector and use a cable to connect to the PC. I suspect the 68Ohm suggestion from Objective is assuming a cable connection, and also based on a mis-reading of the USB spec requiring 90Ohms per end rather than total for both transceivers.
[/size]You're bang on there.
[/size][size=78%]Now a capacitor between the data lines I've never seen on any usb circuit (most of which I look at are atmel examples) proper or v-usb - I do often see the capacitor to ground though - so I'm thinking (with the bit I know) that the idea there is to get away with one cap instead of two since USB data lines are mirrors (twisted pair) so it would work to dampen/control the change in voltage(slew rate). Please correct me if I'm wrong! [/size]
[/size][size=78%]I'm pretty sure there's not even anything in the spec that says the voltages can't be over 3.6v; in fact I read somewhere (maybe even the USB spec itself) that with 0-3.3V output the signal will swing between -1v and 4.2v with a typical transceiver design.
[/size][size=78%]On the zeners - am I correct that even with all of this - without them when running at 5v it would be exceeding the USB spec of 3.3v (3.6v) max? If there are solder jumpers to disconnect the zeners, do you still hate them? How about you gogol? [/size]
The 0-3.3v output drivers are specified to guarantee a minimum "eye" for signal integrity. Driving at 5V will increase the eye. The only possible negative is reflexions, but with no cable and at 1.5mbps that is a non-issue. At ~200cm/ns for electrical propagation speed, a 3M cable would mean a few ns for reflections, which could be enough to cause problems for full-speed.
With jumpers to disconnect the zeners it's not an issue; it's just a business decision for you if you think it's worth the cost. Personally I'd like to see a digispark plus that is about the same price and size as the original (which I think you could do if you dump the 5v regulator), but I don't imagine you'd want to make your inventory of the current digisparks obselete. :-)
On the zeners - am I correct that even with all of this - without them when running at 5v it would be exceeding the USB spec of 3.3v (3.6v) max? If there are solder jumpers to disconnect the zeners, do you still hate them? How about you gogol?
off to continue to buy every sam3x8e in the USA...
@CBcracker - one thought I've had about pulling the resistors - we're making the assumption it is usually plugged in directly with no cable - which might be wrong seeing as every Digispark I have attached to a computer right now is on an extension (some several meters long). SO perhaps the resistors need to be there but just a lower value to find an inbetween ground when plugged direct vs on a cable?
Just saw this from kick starter fall 2011: http://moderndevice.com/product/extracore/#!prettyPhoto (http://moderndevice.com/product/extracore/#!prettyPhoto) - Yes, I'm new to this area. Here’s hoping to add something:$15 for a small ATmega328 board is about 3x overpriced.
Wow, 5 for $23.70. I posted then saw ATmega328 in 10 count for $2 each, about the same as the Attiny85 - I expected more $ diff.If you're gonna buy 5, last week I posted an AliExpress link to a seller with a price of $17.50 for 5 with free shipping.
One thing the pro will have - if it isn't obvious is solder jumper to detach anything that uses power - these will be on the zeners, LEDs, etc. That combined with sleeping the chip and clocking it down should allow for extremely low consumption
Yeah this all sounds totally rad - especially if CBcracker can get micronucleus working without external pullup - that would be really really great. I don't know much about this stuff.. despite being the maintainer, inventor and main contributor to micronucleus, I have no idea what I'm doing a lot of the time. I don't even know assembly, and there is quite a bit of assembly in micronucleus. If you want to fork micronucleus and be the next Bluebie, please do! Otherwise, my rules are simple: If you want me to pull your thingy and maintain it in to the future, you have to make it using tools I understand - that is, it has to either only replace code in v-usb's drv thing, or it has to be written in well commented C, formatted in the same style as the rest of micronucleus.
So far as I have seen there aren't any USB programmers you can emulate without modifying the protocol or hacking avrdude, because the attiny85 does not have the capability of flash self programming while executing instructions, so every time you request an erase or write, the chip goes to sleep for a couple of milliseconds - if host pc makes any kind of USB request in this time it throws a tantrum and considers the device disconnected.Avrdude shouldn't have a problem with it, since it has no issue programming the attiny using the stk200 protocol. As for the USB protocol, I'll have to look into that. I recall SE0 pulses every ms or so from the host to keep the USB device from going to sleep. I'd think the 4.5ms maximum delay for flash programming shouldn't be a problem.
Did some more investigation, and don't see any insurmountable hurdles. USBasploader/HIDbootloader don't use interrupt endpoints which could cause timeout issues.So far as I have seen there aren't any USB programmers you can emulate without modifying the protocol or hacking avrdude, because the attiny85 does not have the capability of flash self programming while executing instructions, so every time you request an erase or write, the chip goes to sleep for a couple of milliseconds - if host pc makes any kind of USB request in this time it throws a tantrum and considers the device disconnected.Avrdude shouldn't have a problem with it, since it has no issue programming the attiny using the stk200 protocol. As for the USB protocol, I'll have to look into that. I recall SE0 pulses every ms or so from the host to keep the USB device from going to sleep. I'd think the 4.5ms maximum delay for flash programming shouldn't be a problem.
USBaspLoader-tiny85 already does what I'm planning to do (except in a lot more code space):Did some more investigation, and don't see any insurmountable hurdles. USBasploader/HIDbootloader don't use interrupt endpoints which could cause timeout issues.So far as I have seen there aren't any USB programmers you can emulate without modifying the protocol or hacking avrdude, because the attiny85 does not have the capability of flash self programming while executing instructions, so every time you request an erase or write, the chip goes to sleep for a couple of milliseconds - if host pc makes any kind of USB request in this time it throws a tantrum and considers the device disconnected.Avrdude shouldn't have a problem with it, since it has no issue programming the attiny using the stk200 protocol. As for the USB protocol, I'll have to look into that. I recall SE0 pulses every ms or so from the host to keep the USB device from going to sleep. I'd think the 4.5ms maximum delay for flash programming shouldn't be a problem.
https://github.com/baerwolf/USBaspLoader/blob/4fbce7ba82c62eacc957109ebcc33d5884aa89b4/firmware/usbconfig.h (https://github.com/baerwolf/USBaspLoader/blob/4fbce7ba82c62eacc957109ebcc33d5884aa89b4/firmware/usbconfig.h)
Windows supposedly has a default polling interval of 8ms (not sure if that is just for control endpoints or if it ignores the interrupt endpoint polling interval), but in either case at most one poll packets would be missed with a 4.5ms delay during programming.
http://www.nextlevelgamer.com/tweaks/optimizing-your-usb-mouse-polling-rate (http://www.nextlevelgamer.com/tweaks/optimizing-your-usb-mouse-polling-rate)
USBaspLoader-tiny85 requires you patch the USBasp driver in your avrdude installation with a bunch of experimentally determined delays which stop it from making another usb request until the device has had time to do it's busy work. [...]OK, you've convinced me USBasp is not the way to go. AVRdude *does* handle the delays for a number of programmers, and my preference is to avoid a custom programmer. Digging through the code, I found USBtinyISP handles the delays appropriately. http://learn.adafruit.com/usbtinyisp
Yeah this all sounds totally rad - especially if CBcracker can get micronucleus working without external pullup - that would be really really great.
Well, I was a bit dumb. It took me about an hour of digging around until I clued into the fact that 0x2038 is larger than the 8K (0x2000) flash size of the t85. Not knowing the size of the bootloader until it's compiled is one of the things I don't like about C vs assembly. I noticed the build was using ' -fno-inline-small-functions'. inlining small functions is usually good thing for code size since the compiler does it when the size of the inlined code is only a couple instructions. Anyway with that gone the end of the code was at 0x2010. Still not small enough. If I define BOOTSTART to 0x1740 it fits, but I'm going to try to pare a few more bytes out of the code...
@CBCracker - can you share your code changes on github or something? I'd love to try it even with it slightly big.
avr-gcc 4.7 is a no-go. It's more strict, and so the code would require a bunch more changes to compile. Here's just one of the errors:Basically as it is saying, you just need to go through all of the PROGMEM declarations, and add the 'const' keywork (which logically should have been declared const in the first place, but obviously the first implementation of PROGMEM did not require it).
usbdrv/usbdrv.h:479:5: error: variable 'usbDescriptorStringVendor' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
So I'm back to version 4.5.3, with the micronucleus code compiling to 2142 bytes...
I'll try the capacitor and removing the resistors on the o-scope as soon as things settle down - thanks for helping me to finally really understand all that.
Interrupts are turned off during flash erase because in order to enable flash erase and write you must manipulate some registers with precise timing. If an interrupt fires inside those commands, it adds a delay and the write or erase fails, which would suck really hard.I think there are lots of places where Bluebie has been extra cautious about keeping people from bricking their Digisparks - an approach like that is essential given that some countries require us to provide a warranty.
On what should be default, digispark users are fully able to switch to the jumper bootloader if they like. I think it's better to have something which just works. I don't use jumper much - I find it annoying always having to connect buttons or wires or whatever.Agreed - our biggest user base is first time Arduino users - asking them to hook up a wire/button to program and remove to not - or asking them to upgrade if they don't want to do that would result in the rest of my life spent doing tech support.
I think if Erik did ever come across a good cheap button supplier, it would be nice to have a "Program!" button and then I'd support making jumper the default, but until that happens I like the regular version better.I only use the jumper version when I'm completely done with something AND it is startup time critical. A program button would be cool - I've found cheap buttons that are too big, and even some small ones that are relatively cheap (but still like 1/10 the cost of the rest of the parts combined) - but I have yet to find one that is small, cheap, and can be placed with a pick and place - generally the cheap ones are in bulk instead of tape and reel and hand placing them is cost prohibitive given that the Pro will be made in the USA.
As for git versus cvs - yeah you can import other repos in to folders inside, but I haven't learnt how because I don't want other repositories to be able to break micronucleus without me having done anything. I wont use google code. Git is what everyone's using these days - you should learn it - it's good!Agreed - Please no google code ever. Git is worth learning as it is the standard for almost all Arduino libraries, programs, etc. (plus like every other new open source project). Personally I prefer SVN and use it in my day job with a codebase in the millions of lines of code - but Git is perfect for widely distributed projects like open source stuff.
Interrupts are turned off during flash erase because in order to enable flash erase and write you must manipulate some registers with precise timing. If an interrupt fires inside those commands, it adds a delay and the write or erase fails, which would suck really hard.
@CBCracker: For that reason, I have soldered three cables with pings to Vcc, GND and 5V for my breadboard digispark. I just plug the sic pins to the rail, and the power pins to the outside power lanes. I made the cables just long enought, that I can reach the outer ends of my bigger breadboards.
.g
re: Pins in parallel - already in the design! it will support the current shield format as well as pins in parallel formatGreat! Now I want one.
re: Schottky - it is there to protect backflow to the USB when powering externally and does so cheaply and using little space (as opposed to an NPN a few resistors and a mosfet). As for the lack of current regulation - that kind of goes back to the premise that the Digispark is a hack and so it doesn't try to be in spec in non functionally necessary - resettable fuses are very expensive, so they are left out knowing that there is almost always one on the host end. We're considering them for the Pro but it is hard to swallow the price and size of them.
I'm less concerned about accidentally leaving the digispark hooked up to another power source and more concerned about capacitors and inductors in my circuit creating voltage spikes which could render the sensitive high speed processors with firmware in ram on my computer corrupt and perhaps even unconscious.OK, now you're being ridiculous. Did you stay inside last week during the perseids meteor shower out of concern you might get hit? The chance of frying your whole computer from something you plug into the USB port are next to nil. Worst case scenario is you fry the port, and even that's hard to do.
re: Schottky - [...] Regarding them blowing - if they blow they saved you from blowing out the Attiny in many cases!
... We won't be using the 1634 because we'd be limited to 12Mhz for V-USB to work, which would break a lot of existing Arduino libraries/compatibility. I'd like to make a 1634 based one at some point - but we want the Pro to be more user friendly then the original, not less.
It appears to have 18 DIL pins, which I'm guessing are all 16 IO lines, and two power pins, with the three other pins at right angles to those, being the traditional set of Digispark power lines, allowing for compatibility with the original nine pin Digispark, and its shields.Reading the datasheet, I expect the 18 pins to be the 16 IO pins and AVCC/AVGND for the analog supply voltage.
hopefully with 16k of Flash,as it is the 167 and not the 87 there is no question ;-)