Digistump Forums

The Digispark => Digispark Projects => Topic started by: CBcracker on July 15, 2013, 04:57:47 pm

Title: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 15, 2013, 04:57:47 pm
I'm trying to design a cost-reduced digispark.  For people in BrIC countries and even poorer areas of G7 countries, I think the $12 shipped cost of the digispark poses a financial impediment.
After seeing Pro Mini 328P variants selling for $5.25 shipped for qty 1, I figured a barebones version of the digispark could be built for much less.
I figure the minimum parts required for a working ATiny85 USB stick are only 3 resistors, 1 cap(.33 uF), a 1.7v red LED, and the MCU (in addition to the board with a USB connection).
When making use of the Tiny85's power saving features, it only consumes a few micro-amps clocked by the internal 8Mhz oscillator.  When not connected to a computer, that would allow it to be powered for years on a single CR2032 cell.  A red LED between the USB 5v and VCC should provide a voltage drop of 1.6v to the MCU when running at 12.8Mhz and drawing ~5mA (figure 22-2, datasheet pg. 173).  Running at 12.8Mhz is supported by v-usb (and therefore micronucleus) and doesn't require any more than 3.3v for stable operation.
I've ordered a couple tiny85 DIPs to build my first prototype, which anyone good with a soldering iron should be able to build themselves for about $1.50:
3/4" x 1 3/4" prototyping board (cut from larger piece): 10c
male USB connector: 18c @DX
ATTiny85 DIP: 115c @ tayda
passives: 5-10c

I've also started on a redesign of the digispark PCB.  I figure my design would fit on a simple 12mmx20mm PCB, including 3mm on the end for solder pads for a user-provided 4x2 male header for ICSP and pin breakout.  The resistors and cap would go just after the USB pads, then the tiny85 SOIC with the power LED beside it, and then 4 3mm pads for connecting the 4x2 male header.  In >1000 unit quantities I estimate the BOM cost at ~75c.

I downloaded Eagle CAD and the digispark design, and started removing components.  I'm stuck now trying to remove traces from the PCB, because Eagle says it can't backtrace them, and to remove them from the schematic.  However the traces don't seem to be shown in the schematic.  I've attached the design (aka hatchet job) so far; I called it digispark-mini.  Can any Eagle users give me some help?

Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: caseyjholmes on July 15, 2013, 05:10:26 pm
I could plug a tiny chip into my AVRISPMKII and call it a day and be at 2x2mm for $1 or so.
But I like the digispark.. it's pretty user friendly for what it is!  8)

who needs PCB's.. solder the components together and glue them together and run magnet wire for traces.  ;D
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 15, 2013, 05:43:14 pm
I should also credit Sparkfun for the idea of a really basic ATtiny85 stick:
https://www.sparkfun.com/products/9147
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: caseyjholmes on July 16, 2013, 05:54:34 am
I have a very tiny board drawn up with express PCB software using the tiny13 MAHR 3x3mm chip if you'd like to take a look at the file.  It's not a USB plugging device like digispark or that chip you link to above, but its much smaller than that chip or digispark. You need to wire it to an ISP like AVRISPMKII.

It's fully featured and will take 1.8-5v, has power led and onboard user programmable LED, capacitors and reset circuit resistors.
The programming header breaks out to a six pin SIP socket row.


Eagle always seemed like more trouble than its worth to me.  I use pad2pad or express PCB. They both work very good and have their own free software you can do just about anything with. 
Only problem is with express PCB you have to learn to create custom components and work their solder masking feature which isn't so obvious.  Pad2pad will make you colored boards in any thickness and size or shape.  They can do things a bit more fancy than express PCB. 

That 3x3mm chip is about the smallest thing I can solder next to the 2x2mm tiny 10 in micro lead frame package. I have had success soldering both at home.  You should see how small they are.


Good luck whatever you do. 
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 16, 2013, 09:15:28 am
I want something that is compatible with the digistump (use the same bootloader & s/w tools), so I'll stick with the tiny85.

I doubt I could solder a 3x3mm MLF; you must have steady hands for that.  I've never done anything smaller than 1.27mm pitch surface-mount chips.  For my PCB design I plan to use 0805 passives instead of 0603 to make the hand-soldering of the prototypes easier...

Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 16, 2013, 09:21:05 am
I just realized dumping the 1.5k pullup will also solve the following power problem:
"in current versions of the Digispark hardware a couple of milliamps are consumed constantly by the USB connector circuitry, even if you aren't using the USB interface.
The power lost through the USB connector maybe able to be fixed in a future version, but no promises."
http://digistump.com/wiki/digispark/tricks
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: Bluebie on July 17, 2013, 05:22:46 pm
If you remove the pullup, your circuit will not be able to do usb. It is not possible to use the AVR's internal pullup. This is not because the internal pullup is over 10kohm - which could be a problem as well - it is because the AVR cannot switch between pullup mode and pull to ground - it can only switch between pullup and floating input, or switch between ground and vcc, or switch between those two modes (input and output) The V-USB software pushes the avr to it's limits to be able to communicate the 1megabaud USB protocol, so it simply does not have time to switch the pin between input and output as well as switching it's state between high and low, and it is not possible AFAIK to do both operations at the same time.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: Bluebie on July 17, 2013, 06:56:48 pm
More stuff: When you use a circuit which runs the AVR at a lower voltage and omits zenner diodes, the 1.5kohm resistor only uses power when the digispark is communicating with the host computer actively over usb, or when you're using that pin and have it set as an output written low (connected to ground). So to efficiently sleep on battery, you just need to set the pin high (connect to vcc), or set it to be an input. Either will work fine.


I have some devices which run v-usb and use two diodes in series to drop VCC down to about 3.8v, and they seem to work, but I'm unsure because my computers are all 5v tollerant on usb ports - that is to say, a digispark running at 5v without zenners works fine for me. 3.6v is in the USB specifications as the absolute maximum voltage a usb device should connect to a data pin when trying to communicate with the host, and people say there are some computers which do not in fact talk to 5v devices (though they aren't damaged by them at all - it just doesn't work). If I had a computer which was intolerant like that I'd feel a lot better about experimenting and making recommendations for circuits like this. In some ways, the USB port reliability is actually improved by getting rid of zenners and running at 5 volts, because the zenners add some capacitance and so make the data less clear and precise in both directions. I think running the AVR at 3.6v while using micronucleus at 16.5mhz will probably work, but a word of warning - I tried running at about 3.0v while programming through micronucleus at 16.5mhz and I bricked my chip. I don't have a high voltage serial programmer and it was embedded in a chunk of plastic, so I ended up having to cut the chip out with a power tool!


When you do the maths on this stuff, keep in mind that USB power is between 4.5 and 5.5v, and it seems more often than not usb host ports output 5.5v exactly, to make up for the voltage drop caused by resistance in usb cables and stuff like that, so a 1.7v LED may only drop the voltage down to 3.8v on some computers, which is still slightly out of spec, but maybe the 5v intolerant computers will tolerate 3.8v.


The 12.8mhz stuff is really interesting. If you have any success playing with that, I'd love to see. My only reservation is that 12.8mhz would be a really annoying clock speed for doing stuff like serial, OneWire™,


I'm also toying with another bootloader idea now: I want to make a much more compact bootloader which works over a single wire, or possibly two wires, but does not do usb. My idea is that this bootloader be under 1kb big, that it speak some really simple protocol, and that I have a USB programming device which plugs in to it and exposes the micronucleus usb interface so it would still be compatible with everything. It could potentially program quicker because the micronucleus implementor device can disable the usb hacks used to work around the sleeping the attiny85 has to do when self programming, so the device can run at absolute maximum speed all the time. This could make programming happen as much as twice as fast!! The other thing I am interested in is making it somehow work with an audio device, so you could have a very compact attiny85 bootloader which you plug in to an audio jack on a phone or computer, and play a wav file to it and it uploads a program. It would be slower - it could take a few more seconds than the digispark bootloader, and there could be upload errors if you get a notification sound on your phone or set the volume level badly or something like that, but I think the possibility of having precompiled arduino apps embedded in to webpages, which then can modify bits of data in the program and upload them in to a device even on a phone or tablet without having to install any crazy drivers or mess around with java and arduino junk, could be pretty great for making things that you give to friends or even sell to people. If you fix some bugs, you can distribute it to them as a wav file in an email!


There is a project like this called Audioino, which works on atmega chips. It might be cool to port it to attiny85. What do you guys think? would audio be a useful kind of bootloader?
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 17, 2013, 07:48:31 pm

But it only has to do VCC pullup during the detection phase.  Once the host has recognized it (through the presence of the voltage of the data line), V-USB can switch to normal floating input.
The pullup resistor is not necessary for data transfer; only for device detection.  In fact, once the device is detected the 1.5K pullup resistor just wastes power.
The 10K internal pullup shouldn't be a problem since the spec requires at least 15K pulldown resistors on the data lines on the host side.  Most hosts use more than that minimum; I've seen 22K used in home routers that have USB ports.  And if the 10K pullup did cause problems, then putting the port in output mode and going high for ~100ms should be more than enough time for the host to detect it.

If you remove the pullup, your circuit will not be able to do usb. It is not possible to use the AVR's internal pullup. This is not because the internal pullup is over 10kohm - which could be a problem as well - it is because the AVR cannot switch between pullup mode and pull to ground - it can only switch between pullup and floating input, or switch between ground and vcc, or switch between those two modes (input and output) The V-USB software pushes the avr to it's limits to be able to communicate the 1megabaud USB protocol, so it simply does not have time to switch the pin between input and output as well as switching it's state between high and low, and it is not possible AFAIK to do both operations at the same time.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 17, 2013, 08:48:08 pm


More stuff: When you use a circuit which runs the AVR at a lower voltage and omits zenner diodes, the 1.5kohm resistor only uses power when the digispark is communicating with the host computer actively over usb, or when you're using that pin and have it set as an output written low (connected to ground). So to efficiently sleep on battery, you just need to set the pin high (connect to vcc), or set it to be an input. Either will work fine.




Good point about no power loss w/o the zener diodes.


I have some devices which run v-usb and use two diodes in series to drop VCC down to about 3.8v, and they seem to work, but I'm unsure because my computers are all 5v tollerant on usb ports - that is to say, a digispark running at 5v without zenners works fine for me. 3.6v is in the USB specifications as the absolute maximum voltage a usb device should connect to a data pin when trying to communicate with the host, and people say there are some computers which do not in fact talk to 5v devices (though they aren't damaged by them at all - it just doesn't work). If I had a computer which was intolerant like that I'd feel a lot better about experimenting and making recommendations for circuits like this. In some ways, the USB port reliability is actually improved by getting rid of zenners and running at 5 volts, because the zenners add some capacitance and so make the data less clear and precise in both directions. I think running the AVR at 3.6v while using micronucleus at 16.5mhz will probably work, but a word of warning - I tried running at about 3.0v while programming through micronucleus at 16.5mhz and I bricked my chip. I don't have a high voltage serial programmer and it was embedded in a chunk of plastic, so I ended up having to cut the chip out with a power tool!



That's what I'd expect from a couple of 1N diodes; 0.6v drop each, so you'd get 3.8v left from a 5.0v supply.  A standard red led has a forward voltage drop of 1.7v@20mA, and ~1.6@5mA, so the voltage to the tiny85 should be ~3.4v.  The high-brightness LEDs wouldn't work since they have a Vf of ~2.2v.

When you do the maths on this stuff, keep in mind that USB power is between 4.5 and 5.5v, and it seems more often than not usb host ports output 5.5v exactly, to make up for the voltage drop caused by resistance in usb cables and stuff like that, so a 1.7v LED may only drop the voltage down to 3.8v on some computers, which is still slightly out of spec, but maybe the 5v intolerant computers will tolerate 3.8v.


That's not what I've seen.  On PC's it's usually dead on at 5.0v.  Even cheap $2 USB battery chargers are usually in the 5.0-5.2v range.  You should never see anything over 5.25v as that should fail compliance testing; it has to be between 4.75 and 5.25v to pass.
www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf
A word of warning; don't test the voltage by sticking multimeter leads into your usb port.  It's easy to short the 5v to the shield ground and fry it.  Cut up a USB cable instead.


The 12.8mhz stuff is really interesting. If you have any success playing with that, I'd love to see. My only reservation is that 12.8mhz would be a really annoying clock speed for doing stuff like serial, OneWire™,

I would have thought 12.8 is no less annoying than 16.5Mhz.  Is 16.5 close enough to 16 so that code expecting a 16Mhz clock will still work at 16.5?
The V-USB site states that 12.8 is one of the supported frequencies.  I guess I'll find out how well it is supported once I try it out.


I'm also toying with another bootloader idea now: I want to make a much more compact bootloader which works over a single wire, or possibly two wires, but does not do usb. My idea is that this bootloader be under 1kb big, that it speak some really simple protocol, and that I have a USB programming device which plugs in to it and exposes the micronucleus usb interface so it would still be compatible with everything.


It sounds like a fun project, but not so practical for general use.  I only ordered my first Arduino board a couple weeks ago (still waiting for it to arrive from Hong Kong), but I've already dug up a DB25 from my parts bin to make a simple parallel port programmer.  I think the attraction of the digispark is that it's great for those who are not hardware inclined and just want to learn embedded software development.  If you don't want to make your own programmer or don't have a computer with a parallel port and want a small bootloader, buy a $4 USBASP using a mega8, and go with optiboot at only .5KB.
https://www.fasttech.com/products/0/10000022/1002900-atmegaattiny-51-avr-isp-usbasp-usb-programmer-down
http://code.google.com/p/optiboot/

Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: Bluebie on July 18, 2013, 06:19:32 am
on clock speeds, if you want to delay 2us, you just need to waste 16*2+1 cycles. The minimum amount of time you can delay that lines up to microseconds like that on 12.8 would be quite a bit larger. 16.5mhz is easier to deal with because in many instances you can fix the timing of some precise bit of code by just adding an extra NOP instruction somewhere. And for many things it is close enough to 16.0 that it works okay without any adjustment - certainly code written for 16.0mhz which interfaces ws2811 LEDs generally works fine at 16.5mhz because all of the timing is still within the tolerances of the receiving devices.


Arduino has only ever shipped 1mhz, 8mhz, and 16mhz devices AFAIK too, so 12mhz isn't very close to any of those, meaning timing specific code - anything which prescales the system clock to run a peripheral like PWM or serial or even the ADC need to be reconfigured, and any assembly code with specific timing needs to be adjusted. There's much less chance of things being close enough to work without adjustment.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: gogol on July 18, 2013, 08:30:24 am
I have just detected, that this thread answers some of the question, I posted in http://digistump.com/board/index.php/topic,986.0.html.
My problem is, that the zeners and the pullup rendering the ports unusable for analog-read, as the voltage is limited to about 3.5V.
I created a diagram in this message http://digistump.com/board/index.php/topic,986#msg3959

I solved that problem for me now, that i destroyed the zeners and the pullup with a scalpel, and modified a programming tool (http://digistump.com/products/42) soldering those components on the backside.

Now I am still able to program the digisparc and can use analog inputs.  However its tricky to kill the components and there is always a risk, killing the digisparc complete by this action.

gogol
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 18, 2013, 09:48:35 am

When you do the maths on this stuff, keep in mind that USB power is between 4.5 and 5.5v, and it seems more often than not usb host ports output 5.5v exactly, to make up for the voltage drop caused by resistance in usb cables and stuff like that, so a 1.7v LED may only drop the voltage down to 3.8v on some computers, which is still slightly out of spec, but maybe the 5v intolerant computers will tolerate 3.8v.


That's not what I've seen.  On PC's it's usually dead on at 5.0v.  Even cheap $2 USB battery chargers are usually in the 5.0-5.2v range.  You should never see anything over 5.25v as that should fail compliance testing; it has to be between 4.75 and 5.25v to pass.

www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf (http://www.usb.org/developers/devclass_docs/USB_Battery_Charging_1.2.pdf)
A word of warning; don't test the voltage by sticking multimeter leads into your usb port.  It's easy to short the 5v to the shield ground and fry it.  Cut up a USB cable instead.

Just finished checking the voltage output on a few devices around the house.  PC: 5.05v, Motorola satellite decoder: 5.03v, Blu-ray player: 4.96v.
I've also been reading more USB specs, and figure the 1.5v D- pullup will have to stay; suspend mode requires it.
http://www.beyondlogic.org/usbnutshell/usb2.shtml

I've also been looking at the I-V curves for red LEDs, and a red LED rated 1.7v@20mA has a forward voltage of ~1.5v@5mA.  So connected to a typical PC @5.05v, the data lines would be at 3.55v and within the 3.6v maximum in the USB spec.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 20, 2013, 06:10:32 pm
The 12.8mhz stuff is really interesting. If you have any success playing with that, I'd love to see. My only reservation is that 12.8mhz would be a really annoying clock speed for doing stuff like serial, OneWire™,

I downloaded the v-usb code, and found out the code for 12.8Mhz is 244 bytes bigger than for 16.5Mhz!
So instead I'm going to try micronucleus @16.5Mhz when I finish building my digispark clone.
First I need to get some different red LED's to try for dropping the voltage.  I tested the 3mm red LEDs I have on hand and they appear to be 2.2v.  With a 1400Ohm series resistor and power from a couple NiMh cells the current was 0.6mA, and the drop across the resistor was 1.825v (& 0.8v drop from the resistor).  I figure I'll need at least 3.5v to safely be able to run an ATtiny85 @16.5Mhz.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 20, 2013, 06:24:12 pm
3.6v is in the USB specifications as the absolute maximum voltage a usb device should connect to a data pin when trying to communicate with the host, and people say there are some computers which do not in fact talk to 5v devices (though they aren't damaged by them at all - it just doesn't work).

After reading more of the spec, the host port must be able to handle >3.6v for speed detection.  With a 1.5K pullup to vbus (+5) on the usb device and 15K pulldown on the host side, the voltage will settle out at 4.5v.
If people are having problems interfacing AVR MCUs @5v, the problem could be improper termination.  The following document indicates a low-speed device should have 50-150pf capacitors to ground on D+ and D-:
http://www.semtech.com/images/datasheet/usb_line_termination.pdf
The digispark doesn't have any, and I haven't seen any used on the usbasp schematics or on Stephan's tinyusbboard.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: gogol on July 23, 2013, 10:22:02 am
@CBcracker: looks like you are on the right path:

Out of the 650 page USB 2.0 reference:
http://www.usb.org/developers/docs/usb_20_070113.zip

6.4.3
...
Low-speed drivers are characterized for operation over a range of capacitive loads. This value
includes all sources of capacitance on the D+ and D-lines, not just the cable. Cable selection must
insure that total load capacitance falls between specified minimum and maximum values. If the
desired implementation does not meet the minimum requirement, additional capacitance needs to be
added to the device. Refer to Section 7.1.1.2 for details.

7.1.1.2
A low-speed device must have a captive cable with the Series A connector on the plug end. The combination of
the cable and the device must have a single-ended capacitance of no less than 200 pF and no more than 450 pF
on the D+ or D- lines.

7.1.6.1
For full-speed devices with captive cables, the device itself may have up to 75 pF of lumped capacitance to
ground on D+ and D-. The cable accounts for the remainder of the input capacitance
.....
An implementation may use small capacitors at the transceiver for purposes of edge rate control. The sum of the
capacitance of the added capacitor (CEDGE), the transceiver, and the trace connecting capacitor and transceiver to
RS must not exceed 75 pF (either single-ended or differential) and the capacitance must be balanced to within
10%. The added capacitor, if present, must be placed between the transceiver pins and RS (see Figure 7-22).







Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 23, 2013, 03:21:08 pm
@CBcracker: looks like you are on the right path:

Out of the 650 page USB 2.0 reference:
http://www.usb.org/developers/docs/usb_20_070113.zip (http://www.usb.org/developers/docs/usb_20_070113.zip)

7.1.1.2
A low-speed device must have a captive cable with the Series A connector on the plug end. The combination of
the cable and the device must have a single-ended capacitance of no less than 200 pF and no more than 450 pF
on the D+ or D- lines.

Thanks for checking.  I downloaded the reference a couple weeks ago, but it's length is beyond my attention span. :-)
I think I'll go with 220pF.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: Bluebie on July 23, 2013, 07:13:00 pm
V-USB does mention the use of capacitors, but please keep in mind that the digispark (the attiny85 specifically) does not have a hardware USB interface, and the software emulation layer is not and can not ever be compliant with the USB spec as far as I can make out. Advice in the spec applies to devices where other parts of the circuit are compliant with other parts of the spec. Here's what the capacitors do: By absorbing some energy after the resistor, they create a low pass filter on incoming signals. This low pass filter has two effects - it reduces or eliminates ringing on the line, and it delays the data by some amount of time. You may like to consider that because timing is such a hard issue with V-USB devices that the timing used in V-USB maybe less than a real USB device.


The digispark implements the circuit schematic recommended by the V-USB developers, which they suggest to be the most universally reliable while remaining compatible with 5v. I would not suggest deviating from their recommendations, especially where it adds more components, complexity, and cost!
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: gogol on July 24, 2013, 12:30:22 am
parallel to this discussion i see another idea, how to deal with the advantages/disadvantages of the virtual USB solution.

What about a slightly different PCB-layout for any upcoming next generation of v-usb powered spark:


PCB arranged in two parts

+------------+ +-----+
|°   ° ° °   +-+     +-------+
|°            |° U     ======|
|°            |° S      =====|
|° attiny     |° B      =====|
|°            |°       ======|
|°           +-+     +-------+
+------------+ +-----+


If all USB-parts like resistors, zeners, safety-diode, ... are placed immediately behind the plug, there can be the second part with the attiny divided with two small incisions between those the pcb can be cutted in two parts.
When the USB part than has still lands for soldering headers you have different possibilities:
That way you could have a solution for both scenarios within one single production for only a slightly higher PCB cost.
Perhaps the LED from PB1 would go as well to the USB side of the crack, (which means, that there needs to go a 5th pad in my sketch as well on that side)
That way there is a simple solution for all problems when projects are running in limitation with pins.

We have only 6 pins, and 4 of them are somehow restricted:


Regards

 .g
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 24, 2013, 07:31:08 am
The digispark implements the circuit schematic recommended by the V-USB developers, which they suggest to be the most universally reliable while remaining compatible with 5v. I would not suggest deviating from their recommendations, especially where it adds more components, complexity, and cost!

I haven't seen postings from anyone who has hooked the data lines up to a scope to see what they look like.  With the digispark being plugged directly into the host USB port there is no cable capacitance, and with no capacitors on the board the ringing is going to be significant.  I'd bet that when going low the voltage drops below -1v.  Going high it will likely go over 6v, then drop once the 3.6v zener starts to conduct, swing down to ~3v, until it stabilizes around 3.6.

A 220pF capacitor is ~1c, even in low volume.  It should reduce complexity in the sense a cleaner signal is simpler to process.

As I mentioned in an earlier post, I'm keeping the 1.5K pullup resistor.  It wouldn't work anyway - after you mentioned it, I checked the datasheet (table 21-1, pg 162).  Rpu = 20-50KOhm, which is way to high to be able to pull the line up over 3v when there's a 15K pulldown resistor on the other side.

Besides adding the capacitors, the other hardware change I'd suggest is moving the data lines to pins 5 & 6, with D+ on pin 6 (PB0).  With that change it's possible to read a bit and do NRZI decode in only 4 cycles:
 in    x1, USBIN    ; D+ -> x1[0]
 eor    x1, x2        ; NRZI decode
 ror    x1        ; x1[0] -> C
 ror    shift        ; C -> shift[7]
 in    x2, USBIN    ; D+ -> bit 0 of x2
 eor    x2, x1        ; NRZI decode
 ror    x2        ; x2[0] -> C
 ror    shift        ; C -> shift[7]

With an extra cycle per bit, there's enough time to do unstuffing.  I plan to do end-of-packet detection when there's a bitstuffing error, like it's done in high-speed USB (instead of se0 detection).
I have written some draft code that should be able to work at 8Mhz; at that speed there's 16 cycles for every 3 bits of USB data.  My code only needs 28 cycles to receive 6 bits, so I had to put in a few nops.  At this point it's only on the back of an envelope (literally), and I have yet to even download AVR studio.  Before the summer is over, I hope to have something working.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on July 24, 2013, 07:46:17 am
My suggestion would solve these three problems:
  • PB0 or PB1 have the LED connected, which will interfere with several use cases as well
  • PB3 has the pullup and a zener connected, which renders analogRead unusable and interferes with other use cases
  • PB4 has the zener connected, which allows analogRead only the input-range from 0-3.5 Volt and interferes with other use cases as well

The red LED would be connected in series with Vcc, so it wouldn't interfere with any of the data pins.  The 5v pullup would draw from Vbus before the LED, so when disconnected from the USB port and powered by another source there would be no voltage on the pin used for USB D-.
Vbus -----+---->---Vcc
               R
By dropping Vcc to ~3.5v, the zeners can be left out.
The capacitors to limit clock slew should have no impact as they would be filtering high-frequency signals that are too fast for the MCU to detect.

Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: defragster on August 05, 2013, 03:49:37 am
I got one of the programmer 'switch' units to minimize wear and tear. 'Ideally' some non-runtime parts could be migrated this way to reduce the per unit load (mA & $).  This thread was old but that is how I read what Mark wrote: http://digistump.com/board/index.php/topic,188.msg2922.html#msg2922 (http://digistump.com/board/index.php/topic,188.msg2922.html#msg2922)  And also "This design may allow the use of thinner PCB's rather than the thick version required for the USB connection, and removes the need for gold ..."
Lower parts/power cost refinement would be great - perhaps only to allow room for other 'Pro' improvements.  A more capable main board means fewer shields/expanders - and more 'networking' options when needed.
I ordered two Sparks and two DigiX units - but also two NANO {[font=]SainSmart V3 ATMEGA328[/font]} w/USB cable for $13.99 delivered China direct - and +$3 each for two MEGA2560 R3. 
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: Mark on August 05, 2013, 04:22:03 am
Quote
that is how I read what Mark wrote
yep that's the way I intended.
one of the other advantages was it releases the full potential of the two pins as well.


mark
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on August 05, 2013, 09:35:41 am

I ordered two Sparks and two DigiX units - but also two NANO {[font=]SainSmart V3 ATMEGA328[/font]} w/USB cable for $13.99 delivered China direct - and +$3 each for two MEGA2560 R3.

Fasttech has a 328P "pro mini" for ~$5.  They're also selling on aliexpress for only $3.50:
http://www.aliexpress.com/item/5pcs-lot-Pro-Mini-328-Mini-ATMEGA328-5V-16MHz-Free-Shipping-Dropshipping/714840800.html
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: defragster on August 05, 2013, 01:20:58 pm
Will be interesting to see how 'Spark' refinement works out. 
Those Lots of 5 for $17.50 are ridiculous for a complete 'Atmel Atmega328P-AU' system when I paid $14 each like a sucker.  It shows the group at $3.50 each - and includes free shipping from China?
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: CBcracker on August 05, 2013, 08:35:58 pm
Will be interesting to see how 'Spark' refinement works out. 
Those Lots of 5 for $17.50 are ridiculous for a complete 'Atmel Atmega328P-AU' system when I paid $14 each like a sucker.  It shows the group at $3.50 each - and includes free shipping from China?

Sounds like you ordered a 328P module with an on-board USB-TTL converter; those go for ~$7.50.
If you need usb-ttl it would be cheaper to get a separate PL2303HX module ($1.81 @fasttech.com) and the basic $3.50 328P module.

Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: defragster on August 06, 2013, 01:28:10 am
Indeed USB included - very handy for starting.  Also my wife working on an Arduino library program is what rekindled my interest in 'these type' of things.  In that scenario having USB and ease of use critical.  But a low enough cost solution might allow participants to take one home
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: jaghvi on August 26, 2013, 03:00:59 am
you might wanna see this
using only DIP packages
https://github.com/mehtajaghvi/Digispark-on-breadboard/blob/master/images/20130816_205919.jpg (https://github.com/mehtajaghvi/Digispark-on-breadboard/blob/master/images/20130816_205919.jpg)
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: Bluebie on August 26, 2013, 03:24:33 am
Woah! Rad!!
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: jaghvi on September 05, 2013, 09:14:14 am
https://github.com/androportal/anuduino/blob/master/doc/getting_started.rst (https://github.com/androportal/anuduino/blob/master/doc/getting_started.rst)
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: Bluebie on September 05, 2013, 10:46:08 am
Is there any evidence at all that it's possible for the micronucleus bootloader to overwrite any part of itself if you try and upload programs which are a little too big, or did you just make that up? There are many systems in place to ensure that is not possible, so to me it sounds like a lie.


What would be compelling evidence to me is this:


Get an attiny85, upload micronucleus and do the fuses, but don't disable the reset pin so you can still use an ISP programmer with it. Next, use avrdude to download a copy of the entire chip's firmware. After that, upload something which corrupts it, then use avrdude again to download the firmware. You can dump to a binary file and use a hex editor to find differences between each. If there really is a corruption in the bootloader's code I will be very interested. This is the process I use to verify the bootloader isn't doing anything strange in the way it is storing data, and to verify that the upgrade programs work perfectly. It is certainly not impossible that I have made off by one bugs that allow the bootloader to mess itself up, but it seems very unlikely especially as there are protections in both the host computer and the device.


Till I see some evidence it remains my view that there is no command you can send to micronucleus which causes it to brick itself, except for uploading a program which itself specifically writes over the bootloader section.
Title: Re: a smaller, cost-reduced digispark (<$1)
Post by: jaghvi on September 14, 2013, 01:13:27 am
I just thought with what I have learnt so far of microcontrollers, that it might overwrite bootloader in the sense that ,if code is greater than 6k it is likely to occupy the memory used by bootloader until it is locked somehow .I have removed this question for now ,until I am assured of whats correct.and the entire tut is shifted to www.github.com/androportal/anuduino






Sorry for the inconvenience.