Yes, the hardware most definitely is able to act as a HID, Mass Storage or almost any type of USB device.  Currently, Teensyduino only adds files to Arduino for a serial type device.  I intend to add other types.  However, the Arduino IDE contains a lot of serial-only assumptions, so support non-serial device types on Arduino is going to take a lot of work.  I am working on that....

You most certainly can use the serial at the same time as the USB.  It's like having 2 serial ports.  Or a HID and serial, if you program the USB to act as HID.

Teensyduino only supports the Teensy.  If you have a usbkey board, Dean Camera's LUFA library, win-avr, and Atmel's FLIP tool are your best option.

Please understand that this project is very new and the website and supporting files are still under development, and Teensyduino (the software add-on for the Arduino IDE) is only in its very first beta test right now.  A full schematic will be added soon.  Many more examples are also planned.  It is a lot of work, as so many people have said dismissively regarding the possibility of using this chip with Arduino.  I'm working on a giant TO-DO list.

However, the bootloader is not open source.  If you are looking for a 100% pure open source project, including bootloader source code and CAD files under a share-alike license, Teensy is not for you.  It is most certainly NOT my intention to deceive anyone.  Building excellent web pages is an iterative process, and the teensyduino page has already been revised substantially based on feedback from many people.  Please if you have any constructive and specific suggestions, contact me directly at paul@pjrc.com  

All code that becomes part of your program is open source.  Everything I have added is under the MIT license, which is more permissive than the LGPL which Arduino uses.  Of course the additions to the Arduino IDE are open source under the GPL, and they are placed in a "src" directory when you run the Teensyduino installer.  The IDE changes have also been offered to the Arduino developer list.

About the PWM, while Atmel's datasheet says there are 5 PWM, and indeed there are inside the chip.  Unfortunately Atmel decided to put 2 of them on the same pin!  The web page says 4 because you can never actually use all 5.  I wouldn't want anyone to buy the board or plan their project around 5 PWM outputs and later discover you can only use 4.

This crazy idea is now in beta test....

http://www.pjrc.com/teensy/teensyduino.html

All the USB chips have separate memory to buffer sending and receiving data on the various endpoints.  The AT90USB162 chip has 176 bytes of this memory, which Atmel calls "DPRAM" (DP = dual port, because it can be accessed by both the processor and USB hardware), and it also has 512 bytes of regular RAM.

USB also includes flow control implemented at the hardware level (in all the Atmel USB chips), so it is not necessary (if done properly) to buffer incoming data in regular RAM.  For example, the regular serial port via FTDI has no flow control (CTS/RTS is not used), so a 128 byte receive buffer is allocated in memory to hold characters your PC might send before your sketch has a chance to read them, like if it's sitting inside a delay() for quite some time.  With USB, the data will be buffered inside the dedicated DPRAM and when that buffer is full, the USB hardware will automatically prevent your PC from transmitting more until your sketch finishes that long delay() and reads the data from the buffer.  (actually, in reality the hardware sends "nak" packets that make your PC retransmit the data, but the point is it's all done at the hardware level so you don't need to consume regular RAM for buffering like would be necessary with regular serial).

A small amount of RAM is needed to hold a few variables related to the USB configuration.  It's surprisingly small.

The USB chips do have a regular UART built in, and if you use that the regular serial buffer memory will be needed.

There are a few of us working on this.  The project is in its infancy right now.  Currently, there is code to allow sketches to run on the AT90USB162, but without any support for using the USB (yet).  If you're alpha/beta testing or getting involved, please contact me.

It is absolutely true that the USB portion is very different from using a UART and supporting it well will be a LOT of work.  I could go on about the details, but honestly at this early stage everything is still in flux.    But if you're interested in getting involved, we could certainly use help.  The rough plan is to add an "easy" API on top of Dean Camera's LUFA (MyUSB) library.  It's not clear yet how the host side and IDE will work and several different ideas are on the table.

Help is of course very welcome.  I would particularly like to hear from you if you're able to do Alpha (not even "alpha", pre-alpha, whatever) testing with good, reproducible bug reports.  That will be very helpful as the USB support is added.  Unlike the FTDI chip, there are a lot of ways the USB can work with and much testing will be needed.

Regarding the hardware cost, while the bigger chips are pretty spendy, the little chips that have admittedly only 1/2 the RAM of an Arduino are very affordable.

Some LED controller chips actually control the current using a transistor built inside the chip, so you can connect the LED directly without any resistor.  Of course, a no-resistor connection should never be attempted on a chip that doesn't specifically include such a feature.  Usually chips that do require a single "reference resistor", which connects to a dedicated pin rather than to any LED.

Had you giving the specific LED controller part number (or better yet, a direct link to its datasheet), this message probably would have been much more helpful.....

This is pretty typical of Atmel when releasing a new and very different AVR... it's always expected in about 3 to 4 months.

In September I was told the xmega was expected around December to January.  At the time, I found several older press releases that said it was expected around Q2 2008, which had already passed.

I'm sure they will eventually release it.  I just wouldn't hold my breath!


Thinking of vapor, how does a Teensy ( http://www.pjrc.com/teensy/ ) with 46 I/O pins for $25 sound?  ... by the end of January.

Is the xmega still vapor?

Yes, you absolutely can program it as native HID.  In fact, the "blinky" example on the C compiler page is native HID for the debug messages, which you can receive with the "HID Listen" program.  Dean Camera's LUFA library has can work on this chip and has lots of HID and other device types.  Of course, that's with win-avr, or equivalent tools on mac or linux.  (yes, avr-gcc and avr-libc fully support this chip)

Making that work in a nice way from the Arduino IDE, and with a simpler API like you'd expect in the from Arduino... well, that is much harder!

I do need to draw a good Arduino/wiring pinout diagram.  The pin names printed on the board are the names from the datasheet and the names you'd expect if you use the I/O registers directly.

I'll get a better diagram drawn up this weekend.

I'd like to let you know about a small-form-factor USB board I've been working on, called Teensy.  It's based on the AT90USB162 chip on tiny board the size of a DIP-24 chip.  Here the web page.

http://www.pjrc.com/teensy/index.html

What does this have to do with Arduino?  I just made the first beta test release of "Teensyduino"... an add-on to Arduino-0012 that tries to add support for this board to the IDE.

http://www.pjrc.com/teensy/teensyduino.html

While the sketches look pretty much the same, underneath this is very different from a normal Arduino.  You're using the actual USB built into the chip, not a serial port and a FTDI USB-serial converter.  You can transfer data at the full USB speed (though in practice your code can only generate data at a fraction of the full 12 Mbit/sec, but still a lot faster than normal serial at 38400 or 57600 baud).  You can also call a transmit flush function that causes any buffered data to get transfered to the PC ASAP (which is difficult with the FTDI chip without a hardware hack or modified PC drivers)

Right now this installs only a single board which emulates a serial port.  I am planning other non-serial options for future Teensyduino releases.  How sketches will use such features and how non-serial devices will work nicely with the Arduino IDE is still a work-in-progress.... but it is coming and if you give this a try I could really use your input and feedback.

What value of pullup resistor are you using?

Perhaps you could try using a lower value resistor?  Or if you have a long cable, try using a lower capacitance cable.

I guess 11uS margin (15uS - 26uS) is little much for the safety of reading this chips.

Did you test at the temperature extremes, or only at room temperature?  The wide timing margin is needed to accommodate changes in the timing inside the 1-wire chips, which lack accurate clocks and can change substantially over temperature.  They can also change from batch to batch.

Ignoring the the 15 us maximum would not be a good practice.  While it worked with the 4 devices you tested, at whatever temperature you tested, going beyond the spec is just asking for trouble.

My guess is your pullup resistor is a bit weak.  Using a stronger (lower value) resistor will likely pull the line up faster, enabling you to use the DS18B20 timing.

The DS18B20 is probably the most common 1-wire device.  Here is the datasheet:

http://datasheets.maxim-ic.com/en/ds/DS18B20.pdf

Please look at Figure 16 "Recommended Master Read 1 Timing" on page 17 of 22.  The diagram shows the line is supposed to be sampled shortly before 15 us after the initial low pulse began.  The timings in the current code are 3 us low pulse, plus 9 us.  That's 12 us, which allows the small amount of extra overhead from code execution to be as much as 3 us (if the CPU is running at 8 MHz or slower).

The page you linked suggests 18 us from the initial pulse until sampling (or "A to CR").  That's 3 us beyond the maximum recommended by the DS18B20.  Also, your code below generates a 9 us pulse plus a 15 us delay, which is a total of 24 us from "A to CR", or 6 us more than the page you linked, and 9 us more than suggested for the DS18B20.  That doesn't seem like such a good approach....

I am open to increasing the timings, but since the DS18B20 and similar chips are so very common, I really think it's a not good to increase the total "A to CR" more than 14 us (it's currently 12), since it's supposed to be less than 15 for those incredibly common parts.

Does it work on your device if you use 4 us pulse and 10 us delay before reading?

Can you capture the actual signal on your device with a digital scope?

One other person (who's local to me) reported a problem.  I'm going to meet with him on Monday and try to learn more.  It might be related.

If you could get the 64 bit ID numbers from your 5 chips and post them here, it would really help.

I really do want to get to the bottom of this.  To be realistic, right now I'm working on finishing up a highly urgent project, so it might be a week or two until I can really focus on OneWire again.  But I definitely will.  Hopefully before then I can find a way to reproduce the problem here.

Can you update the playground, please?

Done.

I have created a new version of OneWire which fixes long-standing bugs in the I/O code.  Robin James's search function was merged, and I made several small optimizations, mostly to eliminate unnecessary RAM usage.  After a few emails with the authors I could contact, I'm calling this version 2.0, to distinguish it from the many other buggy copies online.

http://www.pjrc.com/teensy/td_libs_OneWire.html

If you've used any prior versions of OneWire, even with Robin James's search function merged, you almost certainly experienced occasional CRC errors or devices not responding to the search, no matter how good your wiring and pullup resistor are.  Version 2.0 fixes these long-standing problems.

In ks0108.h, add this:

Code:

#elif defined(__AVR_AT90USB646__) || defined(__AVR_AT90USB1286__)
#include "ks0108_Teensy++.h"

Then add a new file ks0108_Teensy++.h, with this:

Code:

/*
  ks0108_Arduino.h - Arduino library support for ks0108 and compatable graphic LCDs
  Copyright (c)2008 Michael Margolis All right reserved

  This is the configuration file for mapping Teensy++ pins to the ks0108 Graphics LCD library
*/

#ifndef KS0108_CONFIG_H
#define KS0108_CONFIG_H

#define CSEL1                           18              // CS1 Bit  
#define CSEL2                           19              // CS2 Bit
#define R_W                             8               // R/W Bit
#define D_I                             9               // D/I Bit
#define EN                              7               // EN Bit
#define LCD_CMD_PORT                    PORTE           // pins 8, 9, 18, 19

// these macros  map pins to ports using the defines above      
// the following should not be changed unless you really know what your doing
#define LCD_DATA_LOW_NBL   C   // port for low nibble:  pins 10-13
#define LCD_DATA_HIGH_NBL  C   // port for high nibble: pins 14-17

// Teensyduino always optimizes digitialWrite when used with const inputs
#define fastWriteHigh(_pin) (digitalWrite((_pin), HIGH))
#define fastWriteLow(_pin)  (digitalWrite((_pin), LOW))

#endif

Connect the 8 data lines to pins 10 to 17, and the 5 control signals to pins 7, 8, 9, 18 and 19, as documented in the comments.

It works great.

Soon I'll take some photos and draw some wiring diagrams and get them up on the website.