XMEGA

Go To Last Post
440 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I though that the CPU was not blocked when writting on EEPROM, unless you are waiting to the 'writing end'. I always thought that this was like ADC conversion: you start peripheral operation, then you can wait until it ends, or do other things until it ends, while polling, or write some ISR that performs certain actions, like starting the next write.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just a little hint: IAR does support XMegas. Check new 5.1 release at theyr web page.

BTW: Where can I find information about ATmega1284. It seems to be available with certain packs (Raven), but no information on it.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guillem Planisi wrote:
Just a little hint: IAR does support XMegas. Check new 5.1 release at theyr web page.

BTW: Where can I find information about ATmega1284. It seems to be available with certain packs (Raven), but no information on it.

I also noticed they cover the new ATmega32C1 and ATmega32M1 Automotive AVR's in this release.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am curious about what happens when you have EEPROM mapped into the data address space, and you try to use that mapped space to directly store a number of bytes in sequence.

According to the architecture overview document, it seems to me that it ought to be possible. Does the CPU automatically insert wait states? Do successive writes simply fail silently until the first write is complete? Does it automatically buffer the writes, and require you to perform some sort of page program command at the end to transfer it all into real EEPROM?

The documents I've read seem quite short of details on this point so far.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
am curious about what happens when you have EEPROM mapped into the data address space, and you try to use that mapped space to directly store a number of bytes in sequence.
it appears to me like the memory map just does away with the 'normal' writing to ADDR0:ADDR1 and DATA0. But it looks like you are still dealing with the requirement to start a 'write' after the page buffer is loaded as you see fit (via memory map or normal method). Maybe the bigger 'gain' of memory mapped eeprom comes when reading (memory mapped page loading would also be good, though).

I don't see the "memory programming data sheet" for the CMD register though. Which would help.

(just guessing, though)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guillem Planisi wrote:
Just a little hint: IAR does support XMegas. Check new 5.1 release at theyr web page.

IAR said EWAVR 5.1 should be downloadable for those of us with a current IAR support plan on Friday or Monday. Ditto the eval version for everyone else.

IAR's doing a lot better than Atmel with the xmega so far. We've talked to a couple of application engineers, our rep, and our usual contacts in distribution, and nobody knows much of anything beyond what's in the press release. No samples, no pricing and no dates for production quantities. It's kind of sad.

The parts do look interesting, but I wonder how long it will be before the next revision of both the xmega manual and the A1-series datasheet? In the past, it's usually at least several months between AVR documentation revisions. There's lots currently missing--like the ADC/DAC specs, power consumption, oscillator specs, instruction set, timing, etc. I can't even find the usual ordering information--what are the speed ratings, temp ranges, etc?

My impression so far is Atmel rushed this out to go public at Embedded World but xmega wasn't quite ready to come out of the oven yet? Given the typical problems with early parts, I also wonder how long until most of the bugs are sorted out in the most complex AVRs ever--especially in the entirely new stuff like the Event System and Crypto? Atmel has had some very embarrassing problems with early revs of other new AVRs and those parts were child's play by comparison.

And the STK600 has been talked about in reference to the AVR32 for what, nearly a year now? Why doesn't anyone know when we'll be able to actually get our hands on one those either? And it's likely useless for xemga work without the TQFP100 adapter which appears to be yet another unknown item we'll need before we can even power up an xmega?

I'll be at ESC in California in April. Hopefully by then the xmega will either be real and I can find out more from the Norway boys, or I'll just laugh as I walk past the Atmel booth to visit those vendors who understand what "available now" really means to the rest of the world.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I understand that Atmel is more interested to release XMegas to the world, than to present the new IC's that they had released lately in a quiet way. ATmega1284 is an example: they have products that use this IC (like Raven), while there is no information about it in theyr website. OTOH, they have datasheets available for the XMega families but none of us could see the real IC's.

Anyway, It seems that people from IAR and other compilers have some samples already that they used to test the new supported features of theyr compilers. I bet other compiler manufacturers will release a new versio so soon that would support XMegas. And probably samples would be released soon for the rest of the mortals.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rocket Scientist wrote:
My impression so far is Atmel rushed this out to go public at Embedded World but xmega wasn't quite ready to come out of the oven yet? Given the typical problems with early parts, I also wonder how long until most of the bugs are sorted out in the most complex AVRs

But the Xmegas have been talked about for a LONG time and the initial rumours were that they would be released in Feb 2007 not Feb 2008. So they must have been doing SOMETHING for the last year?!?

Rocket Scientist wrote:
And the STK600 has been talked about in reference to the AVR32 for what, nearly a year now? Why doesn't anyone know when we'll be able to actually get our hands on one those either?

Well I got my one back in early October and was told at the time that the delay was because they had regulator issues and wanted to sort those before releasing it. So I think the suggestion that they have rushed this things to market is quite ludicrous. Unusually (in the electronics game) they appear with both xmega and 600 to have delayed lauches for a long time until they have got things exactly right and, in the case of the Xmegs, I think this also means filling the supply pipe in readiness.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rocket Scientist wrote:
Guillem Planisi wrote:
... or I'll just laugh as I walk past the Atmel booth to visit those vendors who understand what "available now" really means to the rest of the world.

Gosh, please tell me who those vendors are. In my experience they all have problems with delivery schedules, failure to deliver all that was promised, and many even announce stuff that never appears. I quit Motofreescalerola over their lying about delivery dates and then replacing a whole family of devices with another non-pin compatible family - causing huge numbers of folks to have to redesign their PCBs. IMHO so far Atmel has been the best in customer sensitivity. So do tell what company(s) you think are better so I can include them in my analysis.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I admit that I am very interested in the xmega256A1 -- I'm kind of a "big iron" guy in the microcontroller world. So far, it looks like I could significantly reduce the size of my code by rewriting it using some of the new Xmega features.

I still have my JTAGICE mkII, so I'll need to pick up an STK600 and wait for the "big guys" to be released. In the meantime, I'll just have to muddle through with my m2560. :( :lol:

The AES/DES feature is interesting -- it looks like they implemented the sub-hash parts of the algorithm and have the programmer cycle through the loops. I'd have to look at the exact implementation to see if the DES could be modified for a 3DES -- IIRC, the hash is different on 3DES. Still, it won't be lightening fast. OTOH, most people don't need it to be lightening fast.

I also need to read more in the App Notes about the DMA. I'm not quite sure how they handled bus arbitration between the external and internal SRAM busses. While the DMA should be faster than programmed I/O (both in latency and in throughput), it seems to me that using DMA will affect program performance during a DMA transfer. Eh, I suppose that's true with any computer system, right?

At any rate, I'll have to convince my boss to buy me some new toys when they become available!

Oh, and I'll have to move FreeRTOS to the XMega... :D

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
it seems to me that using DMA will affect program performance during a DMA transfer.

It shouldn't affect it too much. The cpu core has priority over DMA on the bus, and the cpu doesn't usually access ram that often. Also, if you (or your C compiler) make good use of the 16 gpio registers, cpu access of ram could be significantly reduced.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
Gosh, please tell me who those vendors are. In my experience they all have problems with delivery schedules, failure to deliver all that was promised, and many even announce stuff that never appears... I

I don't want to hijack an AVR thread talking about other vendors, but I'd say we've had significantly better luck overall with TI while Microchip and NXP also do many things better than Atmel. But I agree they all have their weaknesses.

I understand many of the active members of this forum have most or even all of their microcontroller eggs in the AVR/Atmel basket. So I'm not looking to step on their toes. My comments are addressed more at Atmel.

It's hard for me to understand why a company as large as Atmel cannot have someone put together say an e-mail to send out to their own field engineers, the product managers at their distributors, and their manufacture representatives with information on a major product release like the xmega? The e-mail should have answers to the common questions those people will be immediately asked even if the answer to some questions is "we don't know yet". Such a communication should have happened before, or the same day as, the press release.

Some of the people I have talked to thought they were still under NDA and didn't even realize the press release had happened. For such a major product rollout, I think it's been handled rather poorly. That's partly why I said it seems Atmel has rushed things to make the trade show.

I realize they've been working on this for a long time, but that makes the lack of information, incomplete datasheets, lack of development boards, lack of samples, sloppy rollout, etc. all the more difficult to understand and excuse. Hopefully most of the issues that have been raised will be sorted out in the next 6 weeks before the Embedded Systems Conference. But if they're not, I personally think that reflects badly on Atmel and the AVR team given what they said in the press release.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It's hard for me to understand why a company as large as Atmel cannot have someone put together say an e-mail to send out to their own field engineers, the product managers at their distributors, and their manufacture representatives with information on a major product release like the xmega? The e-mail should have answers to the common questions those people will be immediately asked even if the answer to some questions is "we don't know yet". Such a communication should have happened before, or the same day as, the press release.

Well, I've been on the other side during a major product launch, so I can understand. There are a lot of things to get right. Even though Atmel is a large company, they have a lot of products, so the crew devoted to any individual launch is probably lean and very busy.

That e-mail you want: a) would have had to have been on somebody's checklist to make happen, b) have been assgined to someone to compose, c) had to have been reviewed by a couple of other people, d) queued up for sending as one of a zillion other tasks to do on launch day, e) ?? stuff I forgot. At some point, you have to ask yourself if it is more important than other work associated with a good launch, especially when they are trying to do a major trade show at the same time.

We all know schedules are wobbly. Some companies do a better job of expectations management that others. I agree with the above comment that Freescale does (and back when they were Motorola did) about the worst job of expectations management imaginable. Over the years, I've learned to believe in silicon on my workbench, running code, and the rest I discount.

Good companies work hard to hit their schedules and manage expectations well, but, hey, stuff happens. In terms of "fame per byte of code", my personal best is a 200 byte test program that I wrote that showed what was thought to be "finished goods" representing 6 weeks of production of a new speed grade of the Pentium sitting in a warehouse in Malaysia to be, in fact, scrap. The results came back on the same day the V.P. of Marketting was on an airplane to NYC to start the long-lead press tour. Stuff happens.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rocket Scientist wrote:
IAR said EWAVR 5.1 should be downloadable for those of us with a current IAR support plan on Friday or Monday.
Thanks for the notice -- downloading now (big version number jump from 4.30G to 5.10A)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also had some problems with Freescales (there is a nice word joke with them), and not many with Atmel. Right now, I find that Atmel does a pretty good job about that, and there is the point that Ravens are powered with a new IC that is not easy to find the datasheet (Mega1284). Thus the silicon is there, while there are no news about it.

And this last weeks I had been 'tuning' the production tools in order to release a new product to the marked (ATmega based, of course). So I know quite well how salesmen handle expectations and sell 'vapourware'. From this point of view, Atmel is doing things quite well. Of course, we will see how the new Xmegas silicon work.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All my phone calls, e-mails, and perhaps even cranky posts here on Freaks, have resulted in a bit more information:

The STK600 supposedly will sell for $199 USD.

It will NOT include the TQFP100 daughterboard--i.e. the ATSTK600-TQFP100--it's another $99 USD.

Both of the above, along with TQFP100 samples of the 64A1 and 128A1, are supposed to be available by the end of March. Production quantities of the two devices are being quoted for the third quarter.

I also have preliminary pricing for the two devices at various quantites but probably shouldn't post that information here. I can say it's about what you'd expect based on what's in the press release and what Atmel has done in the past for lower quantities through distribution.

So, assuming the above information is accurate, we're making progress!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way, as this thread is about Xmega, someone just noticed:

http://www.atmel.no/beta_ware/

Where Studio 4.14 has X support. (be warned: 86MB!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh and simulator 2 appears to have fully arrived!! :)

But only for "modern devices" :(

Quote:
Supported devices
ATmega128

ATtiny25/45/85
ATtiny43U
ATtiny48
ATtiny88
ATmega1284P/644P
ATmega164P/324P
ATmega48P/88P/168P/328P
ATmega32HVB

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I can say it's about what you'd expect based on what's in the press release and what Atmel has done in the past for lower quantities through distribution.

We rarely deal in more than 100s, so I don't have a grasp on that: For 'classic' AVRs, how does the Qty. 10000 price compare to the Qty. 100 price? About 1/2? 2/3?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Where Studio 4.14 has X support. (be warned: 86MB!)

Is it at least a complete package, or an 86M patch kit to a 30M base?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee,

Well it appears to be a complete release (4.14 as distinct from 4.13) but when I installed it on this machine it actually said "found 4.13.n and upgrading to 4.14.580"

But for a virgin machine I think it's a complete package (you'd certainly hope so for 86MB of download!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stu_san wrote:
I'd have to look at the exact implementation to see if the DES could be modified for a 3DES -- IIRC, the hash is different on 3DES. Still, it won't be lightening fast.

Yes, it is easily possible.

3DES simply is an Encrypt-Decrypt-Encrypt (or Decrypt-Encrypt-Decrypt for decryption) sequence using either 2 or 3 single DES keys.

So 3DES is three times slower.

BTW: There is IMHO no hashing involved in DES, as in any other cipher!
Hash function are, per definition, always one-way.

Bertolt

PS: Somehow it is a pity that they did not add an hardware randomnumber generator :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
PS: Somehow it is a pity that they did not add an hardware randomnumber generator Smile

But every AVR has several useable random sources. Look here.

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

But every AVR has several useable random sources...

Including, I presume, the number of days from "available now" to "distributor stock". ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Lee,

Well it appears to be a complete release (4.14 as distinct from 4.13) but when I installed it on this machine it actually said "found 4.13.n and upgrading to 4.14.580"

But for a virgin machine I think it's a complete package (you'd certainly hope so for 86MB of download!)

It will always say "upgrade" if studio is installed from before, at least at my desktop (w2k), but yes, it really is a full package and no service pack.. However, i really expect quite some from these eXtraMegaSuperDuperAlfVegardRisk machines since it adds 20MB to the "old" studio size (77MB on disk, this one has 90MB on disk) ...

By the way, 86MB was nothing to scare for since the atmel server feeded me with an average of 500KB pr/s at most ;)

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
By the way, 86MB was nothing to scare for since the atmel server feeded me with an average of 500KB pr/s at most

I was thinking more of the poor sods who dial-up on a 56K modem ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

56K modem?

On a sunny day I can get 45K but we don't see many of those around here.

The trick is to make friends with someone who has a cable modem.

Actually the only thing I use AVR Studio for is checking the fuses.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:
By the way, 86MB was nothing to scare for since the atmel server feeded me with an average of 500KB pr/s at most

I was thinking more of the poor sods who dial-up on a 56K modem ;)

I know, I am joust bragging. My cable modem company has recently upgraded their network with no extra cost, and guess who's happy :D

However, as far as i know, samples is joust around the corner and after all, Atmels tactic seems to work by first releasing the xmega and then hold the market with excitement, building up an pressure of curiosity which I think will serve Atmels marked share well. I am not talking many % but the word is spreading. joust look at the freakers impatient only two weeks after release. I think its more funny to watch this than waiting for samples to arrive :). And one more comment, many of us would like to see dip packages since they are so easy to use in the lab, but dont forget that bigger packages contains more smoke and thus require longer manufacturing time. So those who wait may see... Give'em a year or so for the smaller xmega variants, thats my best guess...

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
John_A_Brown wrote:
I was hoping to be able to grab a few DVB packets, and analyze them at leisure for progamme identification.

Just being nosey - DVB-T, DVB-S or something else?

(it's just that in the main DVB-S source in the UK 184 of every 188 byte TS packet is scrambled anyway - so all you can identify are the PIDs)


DVB-S, and I'm not interested in the video/audio content.

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
John_A_Brown wrote:
I saw that, but, looking at the DMA trigger information, I was unable to see how a strobe from an external device could be used in the DMA system. I'll look into it further.

John--as far as I can tell streaming to/from an I/O port should be a standard DMA function. Look in the datasheets (actually the A family doc) at the SRCADDR and DESTADDR registers, a 24-bit pointer into the universal address space. PORTn (PINn?) is just one of those addresses. [An interesting very small side note probably insignificant: I don't see a spot in the universal address space for R0-R31, which used to be SRAM address 0. Rarely used it myself, though the compiler did sometimes when a pointer to a register variable was needed.]

Anyway, see the DMA app note AVR1304 http://www.atmel.com/dyn/resourc...
which should have almost the right example in the source code. "Almost" 'cause it is from SRAM streaming to a port. Ignore the interesting cut/paste typo

Quote:
2 Module Overview
This section provides an overview of the basic configuration options and functionality of the DAC. Section 3 then walks you through the basic steps to get up and running, with register descriptions and configuration details.
2.1 DMA Channels
In addition to ...

I'll check this out later, I've been away for a few days, and I'm a bit behind with this thread.

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bmildner wrote:
3DES simply is an Encrypt-Decrypt-Encrypt (or Decrypt-Encrypt-Decrypt for decryption) sequence using either 2 or 3 single DES keys.

So 3DES is three times slower.

I knew that 3DES was 3 times slower, but...
bmildner wrote:
BTW: There is IMHO no hashing involved in DES, as in any other cipher!

Hash function are, per definition, always one-way.

Sorry, I mis-spoke. I remembered a "permutation" in the function. It turns out that the permutations had...
Wikipedia wrote:
almost no cryptographic significance, but were apparently included in order to facilitate loading blocks in and out of mid-1970s hardware, as well as to make DES run slower in software.
http://en.wikipedia.org/wiki/Dat...

Serves me right for posting without going back to check my facts.

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see the fabled Xmega devices are now listed under the 8 bit AVR section of Atmel's web site. Wonder we we will actually be able to get our hands on them?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Err.. they've been there for most of last week and already widely discussed in this 12 page thread:

http://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See http://www.avrfreaks.net/index.p... and view ALL pages, and search for "available now" with your browser. :twisted:

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
search for "available now" with your browser.
I suppose the issue is "what is available now". From my local FAE:
Quote:
XMega128A1 is limited to Engineering Samples now, Production samples expected at the end of March.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Err.. they've been there for most of last week and already widely discussed in this 12 page thread:

http://www.avrfreaks.net/index.p...

I did see that post, but it was so long I must have missed the bit where the Atmel web site was updated. Sorry. :oops:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll merge this into that other thread.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S-Sohn wrote:
Quote:
PS: Somehow it is a pity that they did not add an hardware randomnumber generator Smile

But every AVR has several useable random sources. Look here.

Thanks! Its an very interesting read!

My concern with random number generators always is that in many cases it has turned out to be the weakest link in real world crypto applications!
So the ideal solution would be a known to be good (over production cycle, product life time, temerature range, voltage range, ...) hardware RNG that is on-die ...
On the other hand XMegas are designed for general purpose and not for high security applications. I guess most of the RNGs described in your document would be ok for typical XMega applications.

Bertolt

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see the XMega has "fractional baud rate generation"!
I wondered what this was, but having read the datasheet, I now see it's something I've done before in bit-banged implemetations. Still pretty neat, though!

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Thanks! Its an very interesting read!

My concern with random number generators always is that in many cases it has turned out to be the weakest link in real world crypto applications!
So the ideal solution would be a known to be good (over production cycle, product life time, temerature range, voltage range, ...) hardware RNG that is on-die ...
On the other hand XMegas are designed for general purpose and not for high security applications. I guess most of the RNGs described in your document would be ok for typical XMega applications.

Bertolt

Thanks for the feedback! :D

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Random number generation is commonly troublesome as pointed out earlier in the thread.

I would recommend you tie a 7404 in a loop with a tap into an IO pin thus creating a ring-oscillator and then when you need a random number sample this IO pin 8 times using an algorithm for the sampling and use an approved RNG algorithm too inside the AVR.

Getting a random number should take several thousand clock cycles so don't be in a hurry!

This is why the FPSLIC is such a nice platform and sadly, it never took off (a whole different topic relating to propagation delay of their FPGA implementation).

In the FPSLIC, you can have a logic-based RNG inside sampling the 7404 tap and have random numbers ready for the AVR on call :)

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hm, but why use external components if you have real random sources inside an AVR available?

Regards
Sebastian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bit the bullet and downloaded the AVRStudio 4.14 beta, primarily to look at Xmega stuff. There is a .xml for the '128A1 in the Part Description Files area. So far, so good.

Running that XML through xmlconvert to produce a chip include file runs into failure:

Quote:
/* ***** INTERRUPT VECTORS ************************************************ */

#pragma AVRPART CORE INSTRUCTIONS_NOT_SUPPORTED break

#endif /* _ATXMEGA_H_ */

The XML file is quite a bit smaller than for classic AVR parts. Must not be all there.

A trip to the \appnotes directory >>does<< have ATxmega128A1_revDdef.inc so one could translate that into a .h if needed/desired. The top of the file says:

Quote:
; N O T E :
; This is an experimental file autogenerated by an XSL transformation.
; Read more about the purpose of this file and how it was generated here:
; http://avrtools.norway.atmel.com...
;
which is a dead link, at least for me.

The reason for my journey is that the "generic C code" in the app notes has a compiler.h header file--with sections for only two of the AVR compiler flavours. Guessing which ones is left as an exercise for the reader. I was particularly interested to see if I could glean any information on how the compilers will handle relocated I/O port information:

Quote:
12.12 Virtual Registers
Virtual port registers allows for port registers in the extended I/O memory space to be mapped virtually in the I/O memory space. When mapping a port, writing to the virtual port register will be the same as writing to the real port register. This enables use of I/O memory specific instructions for bit-manipulation, and the I/O memory specific instructions IN and OUT on port register that normally resides in the extended I/O memory space. There are four virtual ports, so up to four ports can be mapped virtually at the same time. The registers that are mapped is IN, OUT, DIR, and INTFLAGS.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bmildner wrote:

My concern with random number generators always is that in many cases it has turned out to be the weakest link in real world crypto applications!

That's right and I am reminded of a famous quote: "something as important as random numbers should never be left to chance".

Eric

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S-Sohn wrote:
Hm, but why use external components if you have real random sources inside an AVR available?

Regards
Sebastian

I thought the whole point was the XMEGA was still missing an RNG?

Regards

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Selling a chip with a hardware random number generator sounds like a good idea until you talk to a test engineer. I was formerly employed by a major semiconductor manufacturer, and had an interesting conversation with a test engineer on just such a project. The idea was to create a chip that gave out unique, "uncrackable" keys. 1) every chip had to give a unique key, 2) nobody except the end customer could know what it was, including anybody in test engineering.

Test engineers, of course, are in the business of answering the fundamental question of engineering: "How can you tell if you've got one?". So..... how does he test millions of these chips, sort good'uns to customers and bad'uns to scrap, and meet both of the above two criteria?

You can't sell what you can't test. That's why I think hardware "true random number" generators are somewhat scarce.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbc: You seem to be conflating the two (in my mind separate) ideas: 1. Random Number Generator, and 2. Unique Serial Number. Your problems would apply to #2, but I don't think they would apply to #1. A rng IS testable...no matter how many times you query it, you'll always get a new random number, and just because the test engineers may know the previous random numbers, it gives them absolutely no ability to predict what numbers will be given when the end customer queries it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
dbc: You seem to be conflating the two (in my mind separate) ideas: 1. Random Number Generator, and 2. Unique Serial Number.

Well, yes and no. I was thinking of the key generation problem, which has elements of both. Are you differentiating pseudo-random number generators and true random number generators?
Quote:
no matter how many times you query it, you'll always get a new random number,

Ummmm... well, you'll always get a number. But without infinite precision, they will repeat.

I'll agree that pseudo-random number generators are easily testable for manufacturing faults. And either pseudo-random or true random can be analyzed for autocorrelation to judge their "randomness".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But without infinite precision, they will repeat.

Of course they will since there is a finite number of possibilites. But what is important is that a sequence not repeat. Or to put it another way, knowing any number of previous values will in no way influence what the next value is.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The question is not to have an accurate RNG, but to have an accurate enough RNG. For our concerns, the enginears, there are two keyvalues that is important to an RNG. 1: How accurate the randomnes are, and 2: how fast they are. These two will give the criteria for which teqnique to select.. And, offcourse, what do you really need rng for???

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

Pages