Not 100% true statements

[cyborg5]

I suppose I'm not going to go hungry having spent nine dollars on a digispark and six dollars on an IR shield but I'm disappointed to discover that neither of the products were what I had anticipated. It's my own fault for not thoroughly researching your products before purchasing them but I thought I would point out the source of my confusion.While I appreciate that Digispark is not a full-blown Arduino and I thought I was aware of its limitations, your website says "…the ability to use the familiar Arduino IDE…". I think it would've been more appropriate to say that it is modified version of the Arduino IDE with limited features. I don't know about you but the "familiar Arduino IDE" that I use as a serial monitor. Now I'm not sure if it's the limited hardware capability of your device or the limits with the boot loader or what the reason is and is not really important why. I just think it's a bit deceptive to tell your customers they can expect the familiar and what they get stuck with is something very limited.
I've also expressed my disappointment elsewhere that your IR shield doesn't really have the capability to do output using an IR LED without seriously limiting the capabilities of the device. In a thread in your forums you admitted that the inclusion of the output capability was a last-minute decision that was untested. I suppose I should of been suspicious when you did not include the LED and resistor. However I had one of each of those available and just figured I would solder it in and be ready to go. Unfortunately the pretty serious design flaw means the only way to really use it well is to cut some traces and try to solder in some jumpers.
Like I said, I'm not going hungry over my money wasted and I may find something useful to use your products. I'm sure many people have found really cool things to do with them. I just didn't feel like I got what I was expecting.

 

[Bluebie]

It's early days with the Digispark right now. I'm sorry you feel mislead as to the sort of polished experience you expected. There is absolutely no way to have the regular unmodified arduino software program a digispark - the CPU type isn't supported by any of the built in boards. It sounds like a future version of the Arduino IDE will perhaps allow the digispark to be added by just adding some folders to your libraries folder or something like that, rather than downloading a separate modified IDE.


As for the serial console, the digispark does support the serial console! It just doesn't have a built in serial adaptor, so if you want to use it out of the box right now, you need an FTDI cable or a second digispark hooked up with two wires running the cdc232 firmware as described in the LittleWire tutorial. This is a short term limitation which will hopefully be lifted eventually. I see two ways it maybe resolved:


1) Someone with java experience integrates digiusb support in to the Arduino IDE so it becomes a selectable "serial port"
2) Someone writes a virtual serial port library for digispark. It is quite possible for a serial port to be implemented on the digispark, but it would come at the cost of about 1.5kb of memory (as with any usb library) and would require you call a refresh/update function quite frequently like any other usb library, and would not be compliant with the USB specification in a rather dramatic way, which would make it a feature which will probably work, but maybe not in future OS updates. That's why DigiUSB was created - it isn't likely to be broken by any future OS update.

[Bluebie]

Um.. does this fix your IR problem?

[microtherion]

There is absolutely no way to have the regular unmodified arduino software program a digispark - the CPU type isn't supported by any of the built in boards.

This is true.

It sounds like a future version of the Arduino IDE will perhaps allow the digispark to be added by just adding some folders to your libraries folder or something like that, rather than downloading a separate modified IDE.

This is already possible with e.g. a raw ATtiny85 and a Buspirate as a programmer (just throw a folder into the “hardware” folder). The modified IDE is needed because of the custom upload protocol of the tinyspark.

2) Someone writes a virtual serial port library for digispark. It is quite possible for a serial port to be implemented on the digispark, but it would come at the cost of about 1.5kb of memory (as with any usb library)

I’ve been wondering… presumably some of this code would already be present in the bootloader. Would it theoretically be feasible to factor out some parts of the bootloader to serve as an USB library at runtime (Kind of a tiny OS). It seems a bit of a waste to have all this USB functionality and have it only be used at bootstrap time. 

[Bluebie]

The bootloader does not emulate a serial port at all. It doesn't do anything like that - there's no abstraction in there which looks like passing streams of bytes each way. It works more like remote proceedure calls, with the host operating system calling subroutines in the digispark bootloader to have it perform various tasks.


Anyway, it does include a USB library, but to pull off this sort of tom foolery you'd be performing "pathological coupling", which is generally frowned upon. Certainly I will not provide any assistance in any projects to do that and if someone does make a placeholder V-USB library that hooks in to the functions in a particular bootloader version, I will make no effort to maintain those functions availability at the same addresses in different bootloader versions and ultimately probably digisparks bought at different times (they'll probably switch to a newer version of the bootloader some day). And you'd only be saving like a kilobyte anyway.

[microtherion]

The bootloader does not emulate a serial port at all. It doesn't do anything like that - there's no abstraction in there which looks like passing streams of bytes each way.

Now you made me curious, so I looked, and usbFunctionRead() and usbFunctionWrite() certainly seem to serve like exactly such an abstraction (though the former does not seem to be used in micronucleus).

It works more like remote proceedure calls, with the host operating system calling subroutines in the digispark bootloader to have it perform various tasks.

That may be your session layer view of what’s going on, but underneath that, there is still a data link layer where humble bytes flow (and you should know that best, given that you wrote the code).

Anyway, it does include a USB library, but to pull off this sort of tom foolery you'd be performing "pathological coupling", which is generally frowned upon.

That coupling can be as little as putting a jump vector at a mutually agreed-upon address (Which is precisely what e.g. the last line of leaveBootloader() already does):

asm volatile ("rjmp __vectors - 4");

Certainly I will not provide any assistance in any projects to do that

That’s certainly your prerogative. Your software, your rules 

And you'd only be saving like a kilobyte anyway.

Not necessarily a trivial saving on a system with 6K available.