How about a Digispark for the ATTiny84 series of chips?

[Bluebie]

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.


@Digistump Digispark with microusb socket! yes please! Maybe on the bottom side? I love anything that makes digispark smaller in it's default configuration. I often find I'm trying to cram the digispark in to tubes, so if you made it such that it was like 16mm across on one direction, that'd make it really a very nice thing.

[kehribar]

Hi,

In a slightly unrelated topic, here my couple of suggestions.

A reset button can be achieved on the standard digispark by putting a transistor/mosfet/high-side switch between USB 5V and the main VCC line. User can push a button to cut the power then release to reset the device. This way, teensy like "OK, I compiled your program. Please push the reset button to upload" workflow can be achieved. I don't like the plug/unplug routine very much.

Finally, real USB connector, or even a footprint, would be nice

For cost/size reduction purposes, **big** 500ma voltage regulator can be replaced with a sot23-5 sized small LDO. User, if needed, can put an additional high power LDO to drive motors/LEDs externally. I don't know whether that substitution will be enough to keep the cost low enough but if not the two can be added to an experimental _pro_ version of the digisparks.

Best,
ihsan.

[CBcracker]

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.

Well, once I get the f**king avr-gcc assembling my code correctly it shouldn't take me long to get a version working without the pullup.  I only plan to change a few lines of the v-usb assembly code.

As for forking micronucleus, since I want the bootloader in assembly to keep the size down that's not really an option.  I think I can get it under 1K by doing it in assembly, and follow the USBaspLoader using HID so it will work with standard avrdude.  I'll put it all into picoboot and have it build the base bootloader (under 64 bytes so far!), and another with the usbasp emmulation.

[Bluebie]

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. Micronucleus devices communicate their timing requirements to the host, and the software sends requests and then delays to avoid sending any new requests until the chip has had time to wake up again. This works almost all of the time, and when it doesn't, usually the chip reenumerates and the upload app sometimes can detect that and continue the upload, having only stalled for a second or so. Unless you have a neat way of telling the host computer "I'm busy leave me alone!" which doesn't require the chip to respond to interrupts or do anything really at all to change the state of the IO for several milliseconds, you wont be able to emulate USBaspLoader properly. See also USBaspLoader-tiny85 - an attempt at doing just that, which gave birth to micronucleus when it became clear avrdude compatibility in usb bootloaders wouldn't be an option for tiny85 chips.

[CBcracker]

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.

[CBcracker]

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

[CBcracker]

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

USBaspLoader-tiny85 already does what I'm planning to do (except in a lot more code space):
https://github.com/embedded-creations/USBaspLoader-tiny85

[Bluebie]

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. USBaspLoader-tiny85 crashes the usb connection immediately during any sort of flash write or erase with normal avrdude builds, and once you modify avrdude, it will be much slower for ALL usbasp devices, not just these hacky tiny85 ones. I would have implemented a standard protocol if I could have found one, but there were none where the device could communicate it's delay requirements to the host suitably so I create micronucleus protocol to address this, since it was clear avrdude could never support attiny85 usb bootloaders without special drivers written specifically for these devices anyway, so the protocol may as well be one designed for compact bootloaders rather than for programmer devices with plenty of progmem to go around. For example, micronucleus doesn't have to fake flash reads to satisfy avrdude verify steps, nor does it have to pretend to be able to read and write fuses in any meaningful way. USBasp protocol is the main reason USBaspLoader-tiny85 is like half a kilobyte bigger than micronucleus.


Micronucleus protocol is designed to be useful on other chips aside from tiny85 series. The protocol is documented at https://github.com/Bluebie/micronucleus-t85/wiki/Programming-Wire-Protocol-Specification so you don't need to read through any of my messy source code to figure out what's going on. You can even set the delays to 0 on chips which don't need to sleep while self programming flash, and just use it as a neat compact and fast upload protocol. ^_^

[CBcracker]

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
usbtiny.c line 425: usleep( p->chip_erase_delay )

Strangely, although usbtinyisp supposedly uses the v-usb code, just a hex file for flashing to the ATtiny is included so I can't tell what changes they've made to the v-usb code.  However I can figure out enough from usbtiny.c to be able to make a compatible usb bootloader.

[CBcracker]

Yeah this all sounds totally rad - especially if CBcracker can get micronucleus working without external pullup - that would be really really great.

Finished the first shot at the code changes, but it looks like I have to fix a build bug in micronucleus first:
avr-gcc -Wall -Os -fno-move-loop-invariants -fno-tree-scev-cprop -fno-inline-small-functions -I. -Ilibs-device -mmcu=attiny85 -DF_CPU=16500000 -DBOOTLOADER_ADDRESS=0x1780  -o main.bin usbdrv/usbdrvasm.o usbdrv/oddebug.o main.o libs-device/osccal.o -Wl,--relax,--gc-sections -Wl,--section-start=.text=1780,-Map=main.map
/opt/cross/avr/lib/gcc/avr/4.5.3/../../../../avr/bin/ld: warning: -z relro ignored.
/opt/cross/avr/lib/gcc/avr/4.5.3/../../../../avr/bin/ld: address 0x2038 of main.bin section `.text' is not within region `text'
/opt/cross/avr/lib/gcc/avr/4.5.3/../../../../avr/bin/ld: address 0x2038 of main.bin section `.text' is not within region `text'
collect2: ld returned 1 exit status
make: *** [main.bin] Error 1

[CBcracker]

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

[digistump]

@CBCracker - can you share your code changes on github or something? I'd love to try it even with it slightly big.


@ihsan - the big DPAK regulator was there on the first Digispark because it was (and still is cheaper) - in order to fit the bigger MCU we're going to a sot223 type LDO, though it costs a few more cents. Regarding a reset button - we won't be adding any buttons or switches any time soon - they just cost too much in pick and placeable format (even cheap ones from dubious suppliers)- that is the purpose of the prog tool for those who don't like unplugging.


USB connector footprint unpopulated on the bottom all of them is a good idea i"ll make sure to add that to the pro. A populated one with the current USB tab removed and connector will be on top, because placing even one part on the bottom would double assembly cost/time - will come after the pro  - very soon after hopefully!

[CBcracker]

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

There was a lot of low-hanging fruit in the micronucleus code.  tiny85FinishWriting was commented out, but the didWrite... global variable was still defined and used in writeFlash.  I got rid of that.  There's also a lot of code turning off and on intterupts, and sometimes saving/restoring SREG.  I don't know why it's being done, and I double checked the datasheet and cant find anything about interrupts needing to be turned off during flash erase.  So far I've got it building to 2164 bytes, including the few extra lines of code to for setting USBMINUS to output high for it to work without pullup.  I think I can easily a few more lines of code, but not enough to get down to 2048.  I'll give avr-gcc 4.7 a quick try to see if it generates smaller code than 4.5.3...

[CBcracker]

@CBCracker - can you share your code changes on github or something? I'd love to try it even with it slightly big.

My stomach churns with angst because I'm not doing good code management.  Making changes to a local copy is a bit of a hack.  I don't want to start my own repository since that's too much code duplication.  As it is it seems silly that micronucleus, USBaspLoader, ... all having separate clones of the v-usb code.  I think what would be best is if micronucleus was on google code, and I (and others) could svn ci off the main branch.  If Jenna approves of the code change, she could tag it to the main branch, and if she doesn't it still would be available for people who want to try experimental stuff.  Maybe there's a way this would work in git, but I'm really a CVS guy, which has been pretty much superceded by subversion.

The digispark I ordered still hasn't arrived, so I can't give it a real test yet.  So until something is worked out on how to manage the code, I'll just send it to you in an email.

[CBcracker]

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