How about a Digispark for the ATTiny84 series of chips?

[CBcracker]

The next thing I'm looking at removing is tiny85FlashInit().  It's called a few lines into main(), and the comments say:
// check for erased first page (no bootloader interrupt vectors), add vectors if missing ...
Which seems redundant to me... if the bootloader is running, then the reset vector has to be pointing to it (at power up and reset the CPU starts executing from address 0x0000).

[MichaelMeissner]

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

Basically as it is saying, you just need to go through all of the PROGMEM declarations, and add the 'const' keywork (which logically should have been declared const in the first place, but obviously the first implementation of PROGMEM did not require it).

[CBcracker]

I'll try the capacitor and removing the resistors on the o-scope as soon as things settle down - thanks for helping me to finally really understand all that.

Looking at the schematic, you could put the caps in place of the zeners.  If the signal quality is better with the caps, even driving at 5v than it is trying to clip the signal above 3.6v, then the improvement can be done with no board change.  And obviously the same goes for the pullup resistor - just leave the pad unused.

[CBcracker]

below the 2K mark!
avr-size main.hex
   text    data     bss     dec     hex filename
      0    2004       0    2004     7d4 main.hex

This is with BUILD_JUMPER_MODE defined.  I think that should have been the default all along.  No boot delay, smaller code, and all you have to do is connect a jumper wire (or low-ohm resistor) between D5 and ground when you want to enable the bootloader.

[Bluebie]

Interrupts are turned off during flash erase because in order to enable flash erase and write you must manipulate some registers with precise timing. If an interrupt fires inside those commands, it adds a delay and the write or erase fails, which would suck really hard.


The bootloader checks for interrupts because when first installed on to a blank chip, there are no interrupts in the first 6kb of progmem. This is how the bootloader sets itself up. Of course with the 'upgrade' version the upgrade program constructs a similar vector trampoline which is sufficient, so maybe I should work on getting those vectors embedded in the firmware to begin with and get rid of those few bytes.


Your micronucleus build is too big because you aren't compiling with avr-gcc 4.3.3. Other newer versions build it bigger. You're right in lowering the bootloader address - make sure you do so by multiples of 64 (the address is a hexidecimal number).


On what should be default, digispark users are fully able to switch to the jumper bootloader if they like. I think it's better to have something which just works. I don't use jumper much - I find it annoying always having to connect buttons or wires or whatever. I mainly use jumper version on my LittleWire (which I made by hand, before I got my first digispark), so that I can install different firmware's to my littlewire like cdc232 and littlewire software updates like 1.2 without having to wait for it to startup normally. I often plug in and unplug my littlewire to power cycle my circuits. For other things I just leave them plugged in and the delay isn't a bother. I think if Erik did ever come across a good cheap button supplier, it would be nice to have a "Program!" button and then I'd support making jumper the default, but until that happens I like the regular version better. Jumper is nice for things where you've already soldered on buttons - for instance my Volume Knob device I wired the knob pressed in connection through d5 so it can be held in to enable software updates.


As for git versus cvs - yeah you can import other repos in to folders inside, but I haven't learnt how because I don't want other repositories to be able to break micronucleus without me having done anything. I wont use google code. Git is what everyone's using these days - you should learn it - it's good!

[digistump]

Interrupts are turned off during flash erase because in order to enable flash erase and write you must manipulate some registers with precise timing. If an interrupt fires inside those commands, it adds a delay and the write or erase fails, which would suck really hard.

I think there are lots of places where Bluebie has been extra cautious about keeping people from bricking their Digisparks - an approach like that is essential given that some countries require us to provide a warranty.

On what should be default, digispark users are fully able to switch to the jumper bootloader if they like. I think it's better to have something which just works. I don't use jumper much - I find it annoying always having to connect buttons or wires or whatever.

Agreed - our biggest user base is first time Arduino users - asking them to hook up a wire/button to program and remove to not - or asking them to upgrade if they don't want to do that would result in the rest of my life spent doing tech support.

I think if Erik did ever come across a good cheap button supplier, it would be nice to have a "Program!" button and then I'd support making jumper the default, but until that happens I like the regular version better.

I only use the jumper version when I'm completely done with something AND it is startup time critical. A program button would be cool - I've found cheap buttons that are too big, and even some small ones that are relatively cheap (but still like 1/10 the cost of the rest of the parts combined) - but I have yet to find one that is small, cheap, and can be placed with a pick and place - generally the cheap ones are in bulk instead of tape and reel and hand placing them is cost prohibitive given that the Pro will be made in the USA.

As for git versus cvs - yeah you can import other repos in to folders inside, but I haven't learnt how because I don't want other repositories to be able to break micronucleus without me having done anything. I wont use google code. Git is what everyone's using these days - you should learn it - it's good!

Agreed - Please no google code ever. Git is worth learning as it is the standard for almost all Arduino libraries, programs, etc. (plus like every other new open source project). Personally I prefer SVN and use it in my day job with a codebase in the millions of lines of code - but Git is perfect for widely distributed projects like open source stuff.

[CBcracker]

Getting the discussion back on topic (since I'm to blame for digressing into the bootloader discussion), one option for keeping the digispark plus cheap and small (i.e. USB PCB board rather than separate usb male connector) would be to do like a lot of the usb bluetooth and uSD readers do, and put the components on the back side of a think pcb.  I think the ATtiny1634 SOJ is 1mm thick, so a 1.2mm thick board and a .1mm thick plastic sticker covering the back side of the plug would give an overall 2.3mm of thickness.  That should also improve the electrical contact problems that some users have been having with the 2mm thick plug on the current digispark.

[CBcracker]

Interrupts are turned off during flash erase because in order to enable flash erase and write you must manipulate some registers with precise timing. If an interrupt fires inside those commands, it adds a delay and the write or erase fails, which would suck really hard.

I'll start a new bootloader design thread to keep things separate.

[CBcracker]

I have another suggestion for the digispark plus; make the breakouts parallel instead of the L-shaped pattern on the digispark.  It would be much easier for breadboard prototyping.  With the digispark you can solder male headers on the back for P0-P6, but Vin, Gnd, & 5v aren't on the same .1" spacing as P0-P6.  I unfortunately found this *after* I soldered male headers on the back of 5v & Gnd thinking they'd plug nicely into the + & - rails on my breadboard. :-(

[gogol]

@CBCracker: For that reason, I have soldered three cables with pings to Vcc, GND and 5V for my breadboard digispark.  I just plug the sic pins to the rail, and the power pins to the outside power lanes.  I made the cables just long enought, that I can reach the outer ends of my bigger breadboards.

.g

[CBcracker]

@CBCracker: For that reason, I have soldered three cables with pings to Vcc, GND and 5V for my breadboard digispark.  I just plug the sic pins to the rail, and the power pins to the outside power lanes.  I made the cables just long enought, that I can reach the outer ends of my bigger breadboards.
.g

That would work, though I think what I'll do is unsolder the pins (even though it's a pain), and solder the 3-pin female header there.  That way I can plug it into a computer USB port without worrying about the 5v shorting out (did that once already and don't want to do it again).  When I plug it into a breadboard, I'll plug a couple jumper wires into the 5v/Gnd to connect to the power rails.

[CBcracker]

I think you should get rid of the schottky diode.  My understanding of the usb spec is that there has to be non-permanant current protection on the ports (i.e. current choke or resettable fuse).  It also drops the voltage by ~.3v when powered by USB - not really a big problem, but it was a source of confusion when I was measuring the power until I looked back at the schematic.

[digistump]

re: Pins in parallel - already in the design! it will support the current shield format as well as pins in parallel format


re: Schottky - it is there to protect backflow to the USB when powering externally and does so cheaply and using little space (as opposed to an NPN a few resistors and a mosfet). As for the lack of current regulation - that kind of goes back to the premise that the Digispark is a hack and so it doesn't try to be in spec in non functionally necessary - resettable fuses are very expensive, so they are left out knowing that there is almost always one on the host end. We're considering them for the Pro but it is hard to swallow the price and size of them.

[CBcracker]

re: Pins in parallel - already in the design! it will support the current shield format as well as pins in parallel format

Great!  Now I want one.

re: Schottky - it is there to protect backflow to the USB when powering externally and does so cheaply and using little space (as opposed to an NPN a few resistors and a mosfet). As for the lack of current regulation - that kind of goes back to the premise that the Digispark is a hack and so it doesn't try to be in spec in non functionally necessary - resettable fuses are very expensive, so they are left out knowing that there is almost always one on the host end. We're considering them for the Pro but it is hard to swallow the price and size of them.

Powering it externally when it is plugged into USB seems redundant, and a rare use case.  I'd just leave out the diode and add a notice "device should not be plugged into a USB port when powered externally"  On the first day I had them I managed to blow the diodes on 2 digisparks.  Rather than replace them I'll short the pads so it won't be a problem any more.

[Bluebie]

I pretty much disagree with every suggestion CBcracker has made so far.


snap off PCB usb plug please, with little through holes behind it so you can snap it off and solder on a usb cable if the port is giving you trouble or you just want to mount it somewhere inside a thing. Shottkey diode does the job and I'm glad my digispark can't backwash in to USB ports on my computer. I'm less concerned about accidentally leaving the digispark hooked up to another power source and more concerned about capacitors and inductors in my circuit creating voltage spikes which could render the sensitive high speed processors with firmware in ram on my computer corrupt and perhaps even unconscious.


I don't think a fuse is necessary, I mean, who uses computers that don't have fuses on the ports? That would be insane! Maybe there are some cheap and nasty USB phone chargers which don't have them, but nobody should be going in to a relationship with a $3 usb charger expecting to have any protection what so ever from mains AC. Some of those things are just a rectifier, capacitor, and a linear regulator. So dodgy.


If you want jumper bootloader, just install it. I can't believe people are complaining that it's too hard. I made it so easy! You don't even need a programmer to do it! I don't know of any other arduino where you can change out the bootloader without an AVR programmer of some sort, just with a command line program!


Okay now I have one totally absurd request.. @Digistump Do you think you could put traces for a microsd card slot on the bottom of the digispark pro, wired up to the usual SPI pins? I mean, it's kind of a crazy request, but I feel like SD cards are so useful - you can play audio from them or log to them or store animations to control servos or lights or a zillion other things. I don't think you should necessarily put the lot on as well - especially because I imagine fabrication would be quite a lot more annoying if adding components to the bottom side. I would find that very useful for a whole bunch of applications - I would definitely maintain a library for dealing with them, optimised for the spark. It kind of makes more sense for the pro than the regular digispark because SD card libraries use at least 2kb of memory - 4kb if you want fat32 support - but on a device with 14kb or so of memory 4kb doesn't seem nearly so bad. As well, it'd totally be rocking in regards to the 3.3v mode, seeing as you wouldn't need a bunch of level conversion stuff! Yeah? yeah. Keen to hear what you think of that one. It's kind of weird and specific, but also so useful and potentially fun! If not keen, perhaps a shield? Smallness would be very important for my uses. There are remarkably few very small devices on the market which have an AVR and a microsd slot. The only one I could find was SparkFun's OpenLog - which doesn't break out many pins at all (too few for my uses) and is quite expensive. atmega seems like overkill, as I'm sure you'll agree.


Hopefully you could find some good cheap microsd card slot where all the bits that need soldering protrude out the side so it can easily be hand soldered on when needed. I'm also thinking I might make an alternative bootloader for it to boot from sd - so you could upgrade firmware in place by putting a hex file on an SD card. Could be useful for something I'm working on.