How about a Digispark for the ATTiny84 series of chips?

[dougal]

For any cuttable traces, it might be nice to have through-holes where we could mount pins for a jumper, in case we might want to re-connect later without soldering the traces directly on the board. Not sure how that affects cost. And I doubt many people would want/need to cut/resolder/recut/etc. anyhow. But the possibility of more easily reconfiguring the board by adding our own jumper could be nice?

[digistump]

I'm in on the thru hole header spots for a jumper for the 3.3v enable - but for the zeners that would mean making a bigger board for a relatively rare use case - if I find there is the room due to other things then I certainly will - but otherwise I'm not sure it is worth it.
If anyone has any ideas on other types of small jumpers/switches that are cheap and small let me know.


@gogl - as you know - once reset is switched to i/o it can't be switched back without a high voltage fuse changer - so it can't just be a menu option - or did you mean have it be an option to get rid of reset and make it an i/o? I kind of like that idea, reset pin is enabled by default, option to change fuse from menu - warning that the change can only be undone with special hardware - but can a fuse be changed from the software side of things? I was pretty sure there was no way to set fuses at runtime - but please correct me if I'm wrong because that would be cool...


Thanks everyone for the input - the excitement around this is pushing it from a project several months out to much sooner!

[digistump]

I've been playing with the design of this:


Good news: only about 3mm bigger on one side!

General thoughts: I'm moving more and more toward disabling reset and using it as P5 as it has been on the regular Digispark - that gives 14 pins! - and keeps the pin functions similar between each (P5 having its own rules such as lower voltage, etc).


Hold ups: It is easy to design it so the voltage output of the regulator can be switched between 5v and 3.3v with a single jumper (close it and 3.3v, open and 5v) the tricky part is that if it is connected to USB for power and running at 3.3v then it needs to go through the regulator, if not then it shouldn't go through the regulator - short of adding a second jumper - any ideas how to accomplish both with one jumper and not a bunch of extra components? I think the only solution would be diode/transistor based in which case I'd likely have two jumpers because that would be too much extra cost to avoid a second jumper. It is very likely that you could feed 5v to the regulator whether you had 5v or 3.3v set as the output and still get 5v out - but that is out of spec - but at least if someone bridged the USB to regulator jumper they could use it both ways (by bridging or unbridging the second 3.3v/5v selection jumper) and just be out of spec. Does that make sense?

[gogol]

@digistump:

I am completely aware of the restrictions disabling RESET. That is why I started the project, using a digispark as FUSE-resetter (http://digistump.com/board/index.php/topic,1039.html), which is doing its job very well!

Right now there is allready the hidden option in the menu:  Once you use the digispark with littlewire as ISP-programmer and store a bootloader on the target, RESET gets disabled by default (and without any warning or need).

Instead of delivering the upcoming sibling with RESET disabled, I would recommend, deliver it with RESET enabled and give a option in the menu for disabling it (for those, who won't work with the command line tools).

With 13 pins the need for the 14th will be very small, compared to the pin-usage of the digispark, where three pins have other restrictions as well.  So users would have the freedom of using RESET in their applications or use ISP-programmers. If they need the 14th pin, the can just go to the menu!

The other way round it would be much more complicated, as a user, who wishes to use RESET needs at least an FUSE-resetter, which is definitely not a beginner task.
 
regards

  gogol

[defragster]

Reading this the other day on minimizing and my thoughts were there - through holes to re-jumper a cut or jumper over power eater diodes would be worth investigating.  Holes show where to edit as well as undo ability.  Will extend the utility from the single part - though perhaps larger in size or cents - larger production & reduced inventory and added 'features' over two alternate versions or lost sales. 

Last notes I saw related to things pulled to a shield and improve the layout/cost - a 'design/test time' connect to protoboard pins / serial port support could be on a programming shield bought once versus many for production boards - fewer led/diodes on core board (maybe empty holes to populate if the design called for them) - maybe the win there for size/parts count wouldn't offset average cost and complexity for the needed connection.  Though perhaps that dev time shield would be replaced with a 'power regulation' unit (digistump 'boost kit' or $4 down volt like seeedstudio #POW00900M) when regulated bench/usb power isn't there so it could run from battery or external supply: <3.3v or <5v or >6v as needed.

.5 k RAM seems restrictive to some tasks - but I suppose getting double size static storage instead could allow lookup tables or other compression techniques to extend the ram.

[Bluebie]

@Digistump


On Prescaler and 16mhz crystals:


Actually I pulled that idea of using the cpu prescaler to conform to power specs out of the air. I am 95% sure it'd be totally fine and within the spirit of the spec if not the exacting language of it, but it maybe wise to shoot off an email to atmel to confirm. I believe the clock speed issue is this: Each time the CPU steps forward (one full clock transition) a whole tonne of transistors collapse their state, with much of the CPU die becoming effectively a short circuit for a tiny moment. As soon as the chip settles it uses effectively no power at all until the next step forward. This is why attiny require those really low value tiny capacitors right near the power pins - to provide this massive surge of power for some tiny fraction of a nanosecond, and then charge back up for the remainder of the time, giving the overall average power usage of 2ma or whatever. The capacitors are supposed to be as close to VCC and GND as possible to eliminate as much inductance from the wiring as possible, improving the ability to send these sudden jolts of power in to the chip. I think at lower voltages the internal resistance of the chip isn't able to reliably power the entire die at higher clock speeds, so bits can get out of sync and then everything goes horribly wrong. The CPU prescaler would insulate the vast majority of the chip from this higher speed, so the power usage would be almost identical to just using an 8mhz crystal.


The reason I'm so confident it'll be perfectly okay is that all the CKDIV8 fuse does is initialize the CLKPR register to some number other than 0 before jumping to reset vector on power up. This fuse is intended as a way to use the chip at lower voltages than those required for the internal 8mhz oscillator - but the oscillator still runs at 8mhz regardless of everything (except OSCCAL register...)! So atmel are kind of sort of already telling people to use clock prescaler to work around low power requirements.


On Through Holes for zenners:


I don't get what these through holes are for. I can kind of see the usefulness of having through holes for choosing between 5v and 3.3v on the regulator for your usual protoboard spark that you may reuse for prototyping a bunch of different projects, but for the zenners as well? It seems to me that there are only ever two reasons to disconnect the zenners:

• Your computer hates the capacitance added by the zenners, and is 5v tollerant, so disconnecting them perversely makes the digispark more reliable with your specific computer in this wacky edge case. (hehe, get it? edge case? like edge transition? nevermind..)
• You're running your digispark at over 3.6v (e.g. 5v) and you want to never use the USB port again (or your computer is 5v tollerant like most modern Mac's seem to be) and you want to save every scrap of power you can and the power wasted by the zenners is a problem for you.

In the first case, why would you want to be frequently changing this mode enough to have through holes and jumpers? And in the second case, exactly the same question again? For the majority case just leave the zenners always connected and they wont waste any power when the spark is running on 3.3v and they'll do their job when you set the regulator to 5v.


I strongly oppose making the PCB even half a millimeter bigger for something which doesn't seem to be actually useful. The whole point of the digispark is to be small! I would be perfectly happy not having through holes even for the regulator 3.3v/5v selection, unless it just so happens that your board layout leaves you with spare space to play with. I'd be fine with soldering a couple of wires on to the little surface mount jumper pads and connecting a switch for my prototype board spark. I'd much rather that than having a board be 0.1mm longer. Smallness is so important!


On reset pin fuse:


I'm 99.99999% sure there is no way for an attiny to program it's own fuses. There is no register for the reset pin, so it cannot be changed at runtime. If there is an option in the IDE to set if the reset pin to do GPIO or ISP functionality, it must work by the user plugging a high voltage serial programmer in to their computer, which the software uses in the usual way to change the fuse. The only other solution I can think of is faking it with a bootloader that hooks the reset pin via pinchange register and then implements the ISP upload protocol and pretends to be the AVR obaying the programmer, but that'd be so stupid! micronucleus USB upload go way faster than any of my ISP programmers anyway, and the bootloader still wouldn't be able to make all the progmem available for usage, and you couldn't change any fuses either. Believe me I have looked for this miracle fuse self programming mode again and again. I wish it was a thing you could do. I would be all over that thing!


On the reset pin thing though, keep in mind that I am biased because I love Micronucleus. I invented it explicitly so I could use that elusive reset pin on my attiny85's without danger. It is my fluffy and I will love it and feed it and call it george. I love my reset pin and none of you can take it away from me!!! To me, it seems like a crime to let a reset pin go to waste when we now have this glorious magical technology! All bow before the regal might of Micronucleus!

[gogol]

@Bluebie:
you are right with the reset pin. That was a shortage in my thoughts, caused by the patched avrdude in the IDE.

When I install a bootloader using littlewire, the original avrdude is running and the fuses are set in ISP mode.  As soon, as I am programming the digispark through the bootloader, the controller has allready started and the micronucleus-binary is talking with its counterpart.

So I have the fuse-option only in conjunction with ISP or HVSP.

So changing the fuse depends in both directions on some additional hardware (which could be in both cases a second digispark).

From that point changing the usage of the reset-pin isn't so trivial, as i thought in my previous post.

So the discussion is only, if the entry-level users of that device are needing reset-capability or another GPIO-pin. 
When reading the datasheet, it looks like, that PB7 with RSTDISBL is a full GPIO (and not one with a weak current, like in the attiny85)

regards

  gogol

[digistump]

The more I think about it the more convinced I am that reset should be disabled by default - so I'm going with that. I think it is better to have a spare i/o to use for the variation of the bootloader that uses an i/o pin to detect if it should go to programming mode - than to have a reset pin that 99% of people won't use.


Re: Prescaler and crystals - that makes sense to me - thanks for the explanation! I will certainly test with a scope when I get a prototype made.


Re; Through hole for zeners - yeah the more I thought about it the more it didn't make sense - I'll put solder jumpers on the bottom that can be cut.


Re: Voltage change - there is extra room for the header pins for that jumper - otherwise I wouldn't put it on.


Overall size is 20mmx20mm plus the USB plug part so only about 2mm bigger than the original


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

[CBcracker]

I've been looking at the electrical specs some more and I'm back to thinking that you should dump the pullup resistor and the 68Ohm output resistors, and put a ~100pf ceramic cap between the D+ and D-.
Take a look at table 21-1 of the datasheet.  With a Vcc@5v and 10mA of current out, the output voltage is 4.3v.  A 0.7v drop = 0.01A * R; R= 70Ohm  In other words the DC output impedance is 70Ohms.  Adding 68Ohms makes it out of the USB electrical specs.  The 1.5K pullup on D- is needed only for speed detection idle; not for data.  So the D- line can be put in output mode high upon bootup.  When a change is detected on D+, switch to input mode.  After the first transmission the port can be left in input, but with pullup enabled for the USB bus idle state.

Without the pullup and with the capacitor for slew rate control, the voltage swings will be lower.  With lower swings there's a better chance it will work fine without the zeners.  Can you tell I don't like the zeners? :-)

Erik, before you finalize the new digispark I think you should put a scope on the digispark while doing USB communication.  Try it with/without the 68Ohm resistors, with/without the 1.5K pullup, and try it with caps between the data lines.  I'd try one cap between the data lines, and also a separate test with a cap from each data line the way the USB spec states.  If you don't want to do it, send me a 50Mhz storage oscilloscope and I'll do it for you. :-)

[CBcracker]

@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 think was the right choice with the t85; your usable pins goes up 20% in return for giving up the ability to reprogram the t85 with a standard programmer.  On the t167, it will leave you 14 usable pins instead of 13; only an 8% gain.  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.

[digistump]

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)


Regarding the pull-up - as I said before - if micronucleus supports that (Bluebie has mentioned that it can't I believe) then I'd do it - but Digisparks follow micronucleus in compatibility as far as the usb side of things is concerned. I will certainly have a cuttable trace/solder jumper for the 1.5k pullup though.


Zener's aren't going anywhere - it is more important that the digispark doesn't destroy things (while used properly at least) then it is important that it has less parts. With 14 i/o it becomes more acceptable that the USB pins are limited as well.


As far as the reset pin - the reality is most of our 10k+ users are not power users and a power user could reprogram it with a virial payload reprogrammer like bluebie made or a fuse reseter (we'll have an official one some day, it is already designed, just not enough time yet to produce it) - it might make more sense to enhance the viral payload reprogrammer to the point that it is a drag and drop type tool then to remove a pin from everyone - thinking about this more deeply though there is no reason we can't call it both ways since we'll be building these in house, so that likely makes it a mute discussion - if we do a big survey of our users and think that even 100 people want to buy them with reset enabled then we would produce it both ways - heck we could program them as we pack them possibly (but more likely we'll program entire panels at a time)

[CBcracker]

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)

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

Micronucleus could certainly work without the pullup.  If Jenna doesn't want to do it, I'll code the patch myself and test it on a digispark with the pullup trace cut.  If you find the time to check the scope for my suggested interface changes, then you could have a concrete reference to see if changes (such as no pullup) are quantifiably better.

[gogol]

@CBCracker:

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. 
So I went the way down, programmed core attinys with an disgispark as IS-Programmer with littlewire, which solved all the USB related problems.

As it will be more difficult with the 167 for beginners to program core-chips (as they are not available in DIP-packages) I think, that Eriks statement is right, to give as many as possible PINs without restrictions to the users.  The nice thing is, that at least reading the datasheet, that PB7 is a full GPIO-pin on the 167 and not one, with a weak drive, like in the 85!

That is why I support also your ideas of getting rid of zeners and pullups und the USB side, and from what I was reading in the last month, I see nothing, which contradicts your opinion. If you have patched versions of the bootloader, I volunteer for testing!

regards

  gogol

[digistump]

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

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. I'm very interested in seeing it work without the pull up but it seems I can't test that with micronucleus without it being patched - and that falls outside of my expertise, I could and would stumble through it the next time I have time, but that won't be for quite awhile (DigiX production + adding components selection to the webstore is keeping me up all night right now). If you want to submit a patch for it that would be awesome - and then I would test it on the double - not only would I appreciate it - but I bet Bluebie would as well, I know that a lot of people suggest things for micronucleus but only a few (a wonderful few!) actually submit improvements and rarely are those things that would improve the bootloader for everyone (usually they are aimed at a very niche goal). Bluebie doesn't get paid to maintain it or work for Digistump in any way, which is awesome because it keeps us from having control over a bootloader that should be there for any hardware, we (Digistump) do sponsor it when we can with hardware - but otherwise I'm committed to using micronucleus in whatever direction it goes. 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.


Both Bluebie and you are far smarter than me when it comes USB stuff - but I am starting to get the reasoning behind no resistors on the line (because impedance is 70 ohms already) and in my recent work with proper USB devices which keep recommending ~30ohm resistors the ~60ohm ones were starting to seem high - of course I'll scope this and log it to the computer and share it as soon as I get a chance (I'm still new to my current scope - a Rigol DS1102E - so it might take some fiddling (previously had an analog scope... which I often miss). 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?


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!

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?


When we sell to retailers we have to say that we didn't knowingly design something that would harm a users personal property - while we interpret that loosely - putting 5v on a 3.3v data line might not be honoring the spirit of that....


Thanks for all the technical input!

[CBcracker]

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]

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!

[/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
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]

[/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]

You're bang on there.



[/size]

[size=78%]
[/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]

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