How about a Digispark for the ATTiny84 series of chips?

[CBcracker]

@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

The 1634 is the only AVR chip I've found with an internally temperature-controlled oscillator; neither the tiny85 nor the 167 have it; i.e. the internal clock on the 1634 should be more stable than the tiny85.  For now I'll agree that you need an external crystal for 12 or 16Mhz v-usb operation.  I'm working on the v-usb code, and think I can get it to work reliably with the internal clock of the tiny85 as low as 8Mhz.  Here's part of my code from usbdrvasm8.inc to read a bit and store the last bits received in just 6 clocks (at 8Mhz there's 16 clocks for every 3 bits):
    in      x2, USBIN       ;1 [1] sample bit
    eor     x1, x2          ;1 [2] RZI
    ror     x1              ;1 [3] x1[0] -> C
    ror     shift           ;1 [4] C -> shift
    st      y+, shift       ;2 [6]  save received bits

Also because of the 1K vs .5K SRAM (and both with 16K flash) I still prefer the 1634 over the 167.

[CBcracker]

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.

I don't know about their reliability, but Abracon crystals are available through digi-key; 15c for qty 1000 (ABLS-16.000MHZ-B4-T).  It is a large footprint surface mount part, but still smaller than the footprint of the digispark's regulator.  At the volumes you're producing the digispark boards (>40K units last I read), you're probably paying < 10c/sq in for PCB, so the bigger footprint for the crystal (4.8x11.5mm) would cost a fraction of a penny for the extra board space.

[digistump]

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


Regarding the crystal - I'm certainly considering some of the larger surface mount crystals - and surely 35 cents was a number to figure by, not a final production number. Board space is never a factor because of cost, as you're right that is completely marginal, simply because the Digispark is partly known for being so small!


Thanks for the great feedback!

[CBcracker]

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

I agree with the compatibility point and keeping it simple.  I'm not sure you'd get away with using the existing digistump code based on a 16.5Mhz clock if you switched to a 16Mhz crystal.  It might be OK for serial (115k might be hard), but timekeeping code would be 3% slower.  Plus you'd also want separate libraries for the pro to take advantage of things like the 32K internal RTC oscillator...

As for the size of an external crystal, I have another suggestion.  The Funduino Pro mini I just ordered from Fasttech just arrived, and I've noticed they use a tiny 16Mhz resonator - just like Sparkfun's Arduino Pro Mini 328 that it seems to be a clone of.  The resonator is even smaller than the 10uF caps on the board!.

I'm also wondering if the reset button is of much use on a USB powered device like the digispark that you can just unplug.

[digistump]

Resonators generally aren't reliably accurate enough for V-USB - another case of they might work, but not reliably enough for large production.


There will not be a reset button, I'm sure of that - buttons are very expensive, especially in tape and reel form that I need them in to machine place them - to me it isn't worth raising the price just to have a reset button. We'll probably bring reset out to a pin though, so if someone really wants to use it they can attach their own button.


Most Digispark code will work at 16Mhz because most of it was never ported to 16.5!

[Mark]

We'll probably bring reset out to a pin though

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

just a thought

Mark

[Bluebie]

The more I think about it the more I want a digispark with these properties: Four to six more pins, 3.3v operation via linear regulator (or maybe selectable via solder jumper? but then would still need zenners annoyingly), precise crystal timing, snap off PCB USB plug, ability to run at 16mhz, but default to 8mhz via clkpr = 1 in bootloader. 16kb of progmem would be amazing!


So important to this device is that it can sleep properly if you disconnect the power LED. If there are zenner diodes and 5v support it should be easy to disconnect the zenner's somehow - maybe default on solder jumper. I really like the idea of a digispark which has a built in real time clock. I think that would be really useful for lots of stuff.


If a thing like that exists in the future I would find it so amazingly useful I would definitely contribute open source stuff for it (maintain bootloader, make libraries more compatible, etc..). 3.3v is really important to me. There's so much stuff I try and do with digispark or arduino where I need 3.3v and it's a massive pain. There is comparatively few things that can only communicate with 5v devices. A zenner diode (or maybe linear regulator does it anyway?) to ensure the digispark micro never went above 3.5v or so would allow the internal clamping diodes to handle any devices sending 5v at the spark, so long as you connect them with a resistor and don't mind power inefficiency. Every 3.3v device I've seen a datasheet for supports at least up to 3.5-3.6v within spec, as does usb, so it should be fine.

[digistump]

The Attiny167 is looking like the chip.


It has:
16kb of flash! (so likely at least 14k after bootloader - thats over 2X as much)
Internal RTC
max 16 i/o pins - 2 will be used by the crystal, 1 by reset - the plan is to have 6 more pins than the standard digispark fully available for use
11 ADC channels
2 SPI, 1 I2C, 1 UART, 1 LIN


It would be run with a precise crystal at 16mhz


5v vs 3.3v - my plan is to make use a regulator that can supply both and either manufacture both versions (with zeners left out on 3.3v) from the same PCBs or make it switchable with solder jumpers. I'm leaning towards manufacturing it in two versions - with the 5v possibly switchable via solder jumper.


@Bluebie - any input on which pins should be used for the V-USB/Bootloader?


My goal is to have it cost at most $2 more. But I'm thinking maybe to kick it off it would be offered to existing customers or as a pre-order at a discount.


Thoughts?

[bobricius]

How is price difference betwen attiny167 and atmega168, atmega328?
No compactibility problems, no special libraries, UsbAsp bootloader like Metaboard in protected memory.
I think that 1-2$ cheaper chip and couple of days for solving libraries compatibility and chip difference is not good.

And what about stm32f103cbt6? .... 128kb flash, RTC and more. Arduino like IDE (maple) I working on this small boards:)
http://sardravce.sk/tuke/smartstickSTM32.brd
 http://sardravce.sk/tuke/smartstickSTM32.sch

[CBcracker]

The Attiny167 is looking like the chip.

Thoughts?

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

If you're going to start at a slower clock like Jenna suggests, perhaps start at 12Mhz/3.3v.  12Mhz is supported by v-usb, and would avoid the kludge of using the zener diodes to clip the USB D+/D- voltages.  A jumper could select 3.3/5v operation for 5v when running at 16Mhz (even though clocking to 16Mhz should be fine even at 3.3v).

[digistump]

@bobricius - atmega168 is about 3x the price - $2 extra for a chip comes out to much more than that once it is assembled, shipped, profit is added (though currently we don't make any) - switching to an atmega could take us from a $10-11 (possibly lower) price point to a $13-14 which moves us into a different price bracket of boards and puts us in competition with the sea of clones (and Arduino itself - who we kinda like to leave to their market,afterall they inspired all of this). More importantly, the Attiny is our niche, we think there is something wonderful about them and building devices that do just enough - that is how this all started after all!


Not to say I don't often think about doing an atmega device but that will be a separate product - for now, when I want an atmega device I reach for an Arduino.


I have a strong interest in the ARM board (as evidenced by the DigiX) and the potential to make some very cheap small ones, but that is a MUCH bigger project as I don't feel the Maple is compatible enough at this point and see that project taking the form of direct Arduino compatibility (like the Due/DigiX).


In other words - both great ideas - but the Digispark line will remain Attinys with things more like your suggestions certainly in the works and likely would be compatible with the Digispark form factor (so many projects so little time!)


@CBcracker - I wish the 1634 would officially support 16Mhz - but talking with some folks it seems it doesn't for good reason (after all atmel wouldn't just not support it for the heck of it) and I don't want to base a design on overclocking a chip to a likely unstable rate - it sounds like a 16mhz version may come out, but no word on when.


The clock issue - specifically 3.3v not supporting 16mhz - makes me lean towards producing a 3.3v and 5v version (same PCB with different parts) with 3.3v running at 8mhz (with 8mhz crystal) and 5v at 16mhz (with 16mhz crystal) (why not 12mhz for 3.3v? - when I am converting examples and libraries for the Digispark most for the attinys are written for 8Mhz so that would make them compatible with no changes, and 8Mhz is generally more standard for Arduino code then 12mhz (second only to 16Mhz)) - still very open to input/ideas here.




If the 167 is the chip here are the pins available for USB (need two D+, D-) - PB3, PB6 (which has INT0), PA3 (which has INT1), PA6, PA7

[Bluebie]

I want to get behind the 8 or 16mhz sentiment. Many arduino libraries explicitly support only these two speeds - as far as I know 8mhz and 16mhz are the only two cpu speeds arduino have shipped on their own boards. 12mhz would make timing sensitive stuff harder to adapt, and it would mean getting a 1mhz clock would be much more annoying (can't just use frequency divider hardware). For these reasons 12mhz would make a board way less useful to me.


On the 5v/3.3v thing, I think it makes more sense to standardise. I don't see any reason not to use 16.0mhz crystals on all the boards - it gives users overclocking options, makes your inventory less annoying, maybe helps bulk discounts slightly. The current digispark core includes code at startup to configure the clock prescaler to whatever frequency the user selected in the boards menu. it'd be trivial to have a similar system with big sister digispark. using one standard clock frequency on all of the devices would simplify the clock adjustment code and probably save a few instructions. I'd like 8mhz to be the standard frequency *regardless of voltage*, with 16mhz and 1mhz as options for people who require them.


Here's how 8mhz with 16mhz crystals would work:


Chips are programmed with ckdiv8 fuse, so the chip starts up running at 2mhz (16/8). Bootloader immediately changes the clock prescaler from /8 to /2, switching up to 8mhz. This speed change would take a four bytes or so I think - a number totally dwarfed by the savings of having a precise crystal. Next up the bootloader launches in to the installed program and the program startup code either leaves the clock speed at 8mhz or switches the clock divider again. This code currently attempts to (poorly) detect a bootloader by checking if the device has had it's frequency tuned already by the 16.5mhz calibration, so it makes sensible decisions when the same code is installed on non-bootloaded devices. This fingerprinting could trivially be improved to read the chip fuses and decide if the chip is naturally running on 8mhz or a crystal by looking specifically at the clock source section, then adjust the clock divider by one.


Now I think about it, leaving zenners on 3.3v model wouldn't cause much power wastage - 3.6v zenners wouldn't leak much when the spark is only outputting at 3.3v. It'd be fine to leave them on I think, for simplification - then it'd just mean making the regulator switchable somehow, if you could find a neat one which can do both 3.3 and 5v that'd be super cool, otherwise I guess two models makes sense.


On pins, I don't think it matters?


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.

[CBcracker]

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.

A dedicated reset pin means the user can flash it themselves without a high-voltage programmer.  While USBasp is ~$4 and a parallel port programmer (stk200) goes for half that, high-voltage programmers are hard to find for less than ten times that amount.  I've decided to build a fuse resetter (<$5 in parts) then use a regular programmer, but it's a whole lot simpler if you don't need the fuse resetter.
http://www.simpleavr.com/avr/hvsp-fuse-resetter

[digistump]

So it sounds like 16Mhz it is! Thanks for the explanation bluebie - I didn't know 16Mhz crystal was OK at 3.3v even with the divider. Buying one type of crystal will be a big cost advantage (a few cents each) which should allow us a bit more freedom in crystal choice (meaning smaller).


The voltreg idea is already fleshed out - it will be switchable between 5v and 3.3v - with the option to add a shunt jumper to switch it easily (it will come in 5v mode with jumper unsoldered, there will be a surface mount solder jumper or a 0.1" pitch shunt jumper to enable 3.3v - either can be used) - sound good?



I think I'll leave the zeners on - and just give a cutable solder jumper with trace on the bottom so they can be cut and also reconnected.


For which pins for USB I think it comes down to
PB3 & PB 6 - lose some PWM pins, PB6 is INT0 (doesn't that make v-usb easier, no need to use pin change interrupts?)
or
PA3 & PA7 - lose two adc, aref, isrc, PA3 is INT1 (again does that make v-usb easier?)
or
PA6 & PA7 - no INT pins, lose 2 adcs, lose aref, ss


I think the idea behind leaving reset is because it makes it more hackable - I think a HVSP (or your vural method) is easy - but it reboot being readily available encourages fuse changes, bootloader changes, etc - it would be on the header so easy to use either way - just a question of what the factory default is - open to thoughts on this of course

[gogol]

Hi all,

it sounds, that the sibling of the digispark gets more and more flesh. I don't understand the reset-discussion, as this could be just one more option in the menu like the frequency!
If you need the IO-pin you go for that option, which disables reset!
As resetting fuses is no problem at all, and this sibling should be the perfect base for my FUSE-resetter (http://digistump.com/board/index.php/topic,1039.0.html)
as it has enough pins!
I like the idea for the cutable solder jumpers for the zeners (when the core digispark gets an upgrade it would be there as well a big advantage!)

regards

  gogol

@cbcracker:  thanks for the futurelec-link. They have also cheap 20pin SOIC to DIP adapters, haven't found so cheap ones up to now!