Wanted: Comments on future AVR-based product

Log in or register to post comments
Go To Last Post
14 posts / 0 new
Author
Message
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 684 View posts
Location: Amadora, Portugal
#1
Posted by Nuno: Mon. Jun 2, 2008 - 01:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there Freaks,

I've been developing a little product, which I will start to sell soon enough and I would like your opinion on it.
This is a "firmware-only" product, that is, a single chip product, with the need for very few external components required (if any).
The device will work as an "I/O Expander with UART interface & analog inputs", also supporting inverted UART for easier PC-serial port compatibility.

Well, I'm leaving here the datasheet for the product, and any comments on *any* aspect of this product would be highly appreciated.

Many thanks!!
...

Attachment(s): 

PDF icon ED1021 - I/O Expander with UART interface & analog inputs

Embedded Dreams
One day, knowledge will replace money.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9845 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Jun 2, 2008 - 03:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does the TINY26 support OSCCAL? If so, I'd suggest making the user supply an external 32.768KHz (watch) crystal instead of a 4MHz and do the calibration at startup. That way you save on power, as well as board space and cost for the end-user.

What about a magic TX/RX handshake which enables SPI mode rather than USART?

(Just thinking aloud, not trying to say what you have isn't excellent).

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 684 View posts
Location: Amadora, Portugal
Posted by Nuno: Mon. Jun 2, 2008 - 08:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, we gladly take any kind of comment :).
Yes, the tiny26 supports the OSCCAL, but:

a) Power saving is not a central feature, although the implementation takes that into consideration.

b) The chip is supposed to be easy to use; adding a calibration step not only makes it more complex to use (setup) as it demands that the customer needs extra hardware, know-how and programming tools (hw + sw). This is outside the scope of the targeted customer profile.

Concerning the SPI thing, it would be nice, but doesn't fit the available code space. Furthermore, in SPI mode the crystal would not be needed and those pins would be replaced by the extra pins needed for the SPI interface (and then using the internal RC clock). Your suggestion of using the RC clock would fit this, but makes it too complex for the UART version given the targeted audience. That's why we have other chips models, including one with SPI interface :)

I guess this could be worked out by calibrating the UART by sending a few 55's or AA's at startup, but I hit the code space wall again. Maybe if I can get a good source of Tiny461's... but then price also comes into play.

Thanks!

Embedded Dreams
One day, knowledge will replace money.

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9845 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Tue. Jun 3, 2008 - 02:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

b) The chip is supposed to be easy to use; adding a calibration step not only makes it more complex to use (setup) as it demands that the customer needs extra hardware, know-how and programming tools (hw + sw). This is outside the scope of the targeted customer profile.

Calibration can be done internally at startup - that's why you need the 32.768KHz crystal. You use that as a reference value on one timer, then start another at FCPU for a small duration and compare. If the reference indicates that the internal clock is running too fast, you use OSSCAL to lower the frequency and vice-versa.

Only downside is the requirement of two GPIO pins for the asynch timer, so I suppose it wouldn't be suitable for this application. At any rate, great work.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
eskoilola
eskoilola's picture
Level: Hangaround
Joined: Tue. May 6, 2008
Posts: 435 View posts
Location: Finland
Posted by eskoilola: Tue. Jun 3, 2008 - 02:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some comments as per Your request.

Seems like there is no way to store the current configuration somewhere. I mean, doesn't this chip come with an EEPROM ?

The protocol is fairly simple. How can You tell when a message starts ? I mean if there has been a glitch on the line then the host might loose sync.

Usually this is done by some agreement (protocol) for example so that the header consists of two bytes that have all bits reversed. It might also be a byte that will never occur in the actual message.

You do not need checksum if You use parity on the RS232.


Yet another home page

Top
glitch
glitch's picture
Level: Raving Lunatic
Joined: Sat. Jan 12, 2002
Posts: 8620 View posts
Location: Canada
Posted by glitch: Tue. Jun 3, 2008 - 02:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eskoilola wrote:

You do not need checksum if You use parity on the RS232.

I disagree. A parity bit is only good for detecting a single bit error in a frame. If there is more than one bit error in the frame, the parity bit is unreliable. A checksum has a greater chance of detecting multiple bit errors.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Top
eskoilola
eskoilola's picture
Level: Hangaround
Joined: Tue. May 6, 2008
Posts: 435 View posts
Location: Finland
Posted by eskoilola: Tue. Jun 3, 2008 - 02:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some more about the protocol.

The documentation is really short about this subject. It should have examples of all possible messages in all possible setups. I know, it will be like Tolstoi's War and Peace but that's what we expect. At leas some messages should be shown.

Usually the checksum is just the SUM of message bytes. XOR:ing them does not give as good security. It is unfortunate that You're running out of pgmspace - the CRC would be great.

You could also conside using ASCII transfers for the register numbers and values. This would help on debugging the thing (needs just another terminal). It would also enable You to use the special characters on the message header.


Yet another home page

Top
eskoilola
eskoilola's picture
Level: Hangaround
Joined: Tue. May 6, 2008
Posts: 435 View posts
Location: Finland
Posted by eskoilola: Tue. Jun 3, 2008 - 02:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
eskoilola wrote:

You do not need checksum if You use parity on the RS232.

I disagree. A parity bit is only good for detecting a single bit error in a frame. If there is more than one bit error in the frame, the parity bit is unreliable. A checksum has a greater chance of detecting multiple bit errors.


Agree on that. My bad ... what was I thinking...
:oops:


Yet another home page

Top
nanovate
nanovate's picture
Level: Hangaround
Joined: Sat. Jan 6, 2007
Posts: 371 View posts
Posted by nanovate: Tue. Jun 3, 2008 - 03:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ATtiny26 is not recommneded for new designs. The ATtiny261 is the replacement.

Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 684 View posts
Location: Amadora, Portugal
Posted by Nuno: Tue. Jun 3, 2008 - 03:48 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean,
the tiny26 does support OSCCAL, but there's no 32.678KHz "asynch timer mode" as in some of the AVRs (I think that's what you're referring to). Therefore what you suggest isn't doable with this AVR. Furthermore, you would still need a crystal... are those 32.768KHz much cheaper than a 4MHz one?

eskoilola wrote:
Seems like there is no way to store the current configuration somewhere. I mean, doesn't this chip come with an EEPROM ?

Well, yes, the chip has EEPROM. But I'm out of program space. Currently I'm using the EEPROM only to store the internal Vref "correction" constant.
More EEPROM usage is postponed to another version...

eskoilola wrote:
The protocol is fairly simple. How can You tell when a message starts ? I mean if there has been a glitch on the line then the host might loose sync.

First of all, if you're worried about line glitches, then you should use the checksum.
When writing to registers, you should also do a verify (read back and compare to the value you intended to write).

Now, if a glitch occurs, that will cause a checksum error.
If the error was on the message going to the device, the device will ignore the request. This will cause you (the host) to timeout waiting for an answer (when reading) or to detect the failure when doing a write verify (and then repeating the write).
If the error was on the message coming from the device, the host will detect it on the checksum and then retry the operation.

The device has a short timeout when receiving bytes (~13.5ms per byte), so the host can simply wait some time (55ms is enough for the worst case) to synch with the device, for example after a timeout waiting for a device's answer and before retrying the operation.

This way you don't need more complex protocols. This simple protocol was designed also with speed in mind; penalties are avoided on the usual case.

eskoilola wrote:
The documentation is really short about this subject. It should have examples of all possible messages in all possible setups. I know, it will be like Tolstoi's War and Peace but that's what we expect. At leas some messages should be shown.

I confess I didn't give much relevance to that, because the protocol is quite simple and I'll provide reference interface code (both a C and a TCL library), and also a GUI application for PC that can be used to "play" graphically with the device without writing code. But you have a good point anyways. I'm going to think about some improvements to the datasheet on that area.

eskoilola wrote:
Usually the checksum is just the SUM of message bytes. XOR:ing them does not give as good security. It is unfortunate that You're running out of pgmspace - the CRC would be great.

Humm, I've never thought about the security difference between XOR and ADD, I'll look at it. For that I still have pgrm space :)! I think a CRC would be overkill for this application.

eskoilola wrote:
You could also conside using ASCII transfers for the register numbers and values. This would help on debugging the thing (needs just another terminal). It would also enable You to use the special characters on the message header.

I'm out of code space... and that would also be overkill for such a tiny device. You'll hardly find (if at all) such ASCII interface on any commercial chip. At this size, it's "pure bits and bytes" stuff. No space/time can be "wasted".
Thanks for your extensive comments :)!

Embedded Dreams
One day, knowledge will replace money.

Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 684 View posts
Location: Amadora, Portugal
Posted by Nuno: Tue. Jun 3, 2008 - 04:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nanovate wrote:
ATtiny26 is not recommneded for new designs. The ATtiny261 is the replacement.

Yes you're right, but:

a) they still sell it and I can get the Tiny26 40% cheaper than Tiny261 "in quantity"
b) if it runs on Tiny26, it should run on Tiny261
c) Tiny261 actually looks (I haven't done tests on this yet) a bit worse than Tiny26 for this application, because it is more limited concerning the maximum current it can sink/source from all I/O ports (60mA versus 200mA for Tiny26; bad to light LEDs).

Embedded Dreams
One day, knowledge will replace money.

Last Edited: Tue. Jun 3, 2008 - 11:26 PM
Top
nanovate
nanovate's picture
Level: Hangaround
Joined: Sat. Jan 6, 2007
Posts: 371 View posts
Posted by nanovate: Tue. Jun 3, 2008 - 06:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
because it is more limited concerning the maximum current it can sink/source from all I/O ports (60mA versus 200mA for Tiny26; bad to light LEDs).
Looks to be same. Both are limited to <200mA gnd current and the pin driver strength looks pretty similiar -- look at the Y-axis scale at 4.5V both are 20mA sourcing

If this is a one-shot product where you do a lifetime buy then go for the cheaper one. I just brought up that the tn26 is being phased out so that you could decide what is best for your situation.

Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 684 View posts
Location: Amadora, Portugal
Posted by Nuno: Tue. Jun 3, 2008 - 12:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nanovate wrote:
Quote:
because it is more limited concerning the maximum current it can sink/source from all I/O ports (60mA versus 200mA for Tiny26; bad to light LEDs).
Looks to be same. Both are limited to <200mA gnd current and the pin driver strength looks pretty similiar -- look at the Y-axis scale at 4.5V both are 20mA sourcing

It's not, or at least it's not their current recommendation. They have a note in Tiny261's datasheet saying
ATMEL wrote:
4. Although each I/O port can sink more than the test conditions (10 mA at VCC = 5V, 5 mA at VCC = 3V) under steady state
conditions (non-transient), the following must be observed:
1] The sum of all IOL, for all ports, should not exceed 60 mA.
If IOL exceeds the test condition, VOL may exceed the related specification. Pins are not guaranteed to sink current greater
than the listed test condition.

This same note says 300mA per port or 400mA for all ports for Tiny26 (in practice, 200mA since it's the device limit for steady conditions).

nanovate wrote:
If this is a one-shot product where you do a lifetime buy then go for the cheaper one. I just brought up that the tn26 is being phased out so that you could decide what is best for your situation.

I also looked into Tiny261, but since I can get Tiny26 for a much lower price I decided to start with it. Then, when I can't get it anymore or if Tiny261 gets cheaper, I'll switch (and do a new datasheet revision on my product).

Embedded Dreams
One day, knowledge will replace money.

Top
Nuno
Nuno's picture
Level: Resident
Joined: Sat. Nov 1, 2003
Posts: 684 View posts
Location: Amadora, Portugal
Posted by Nuno: Thu. Jun 5, 2008 - 12:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, no more comments? sheeese, this thing must really suck, 42 downloads and comments from only 3 freaks :)

Any application ideas? I would ask "would you buy it?" but a freak is not the typical customer for this product.

I built a PC GUI interface (see pic below), it's not very pretty but allows graphical control, including conversion of the ADC reading to a meaningful value (like A, ºC, ohms, s, whatever) by introducing a math expression. You can configure the function of each pin (in, in w/ pullup, out, ADC) and save all the configuration in a file. Any improvement ideas? I was thinking about having logging facilities, to file and graphical. The application will be free and it's just a way of helping sales, turning the device into something you can use almost directly for some simple data logging or external device control.

Anyways, thanks to all for your comments!

Attachment(s): 

Image icon ed1021_gui.jpg

Embedded Dreams
One day, knowledge will replace money.

Top