Sorry I have to write it this way, but Atmel will start making 328P with the same problems as 328PB!
The real problem is the full swing crystal osc. don't work, so people that make things approved with a full swing osc have a problem!!!
Add
I just checked for the 324 but it's not changed, (because then I would have a real problem!)
I see an error in your thread title.
That would be "Microchip" ;-)
Presumably they have started the process of fabbing the "popular" chips using their own processes and for some reason cannot duplicate the full-swing osc. circuitry?
I do think it's a little disingenuous of them to try and sweep this under the matter as simply a "silicon revision". When Atmel moved from their own fabs to the far east and it affected the electrical characteristics they redesignated the chips as "A". Microchip should be doing this (and possibly changing the signature bytes).
I do believe that this happened before microchip (mega328pb), and now they make more chips the same way/place (and my guess is that it's cheap, and ok but don't call the new chips the same!)
I have the same concerns : https://www.avrfreaks.net/forum/a...
I know it was your thread that made me check it (thanks).
We've been here before.
https://www.avrfreaks.net/forum/m...
See in particular the PCN linked to in #11. All this before Microchip came along.
Yes but that was when the PB came, so at least they had an other name, but this is 328P that have the changes (by now we all know that the 328PB are different)
That is why I call them fake. you can't replace a 328P 20MHz with a 328P 20MHz !!!!
Or perhaps a Atmel 328P is the old one, and a Microchip 328P is the new! (sorry I know it's not funny), if redesign is needed many will use an other chip.
Hi,
no need to worry, revision K that you are referring to was not released to production due to among other things the errata on the full swing oscillator and the write delay for the NVM. Rev K will be pulled from the datasheet ASAP.
Wow!
Hello Alohre!
It is certainly nice to hear from the company now and then!
It is nice to know that someone in Trondheim, (or Calif, opps! I guess that should be Arizona!), remembers that AVRFreaks exists, and keeps on eye on things once in a while.
Take care,
JC
Thanks for this news Andreas.
Hear, hear!
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
no need to worry, revision K that you are referring to was not released to production due to among other things the errata on the full swing oscillator and the write delay for the NVM. Rev K will be pulled from the datasheet ASAP.
Sounds like good short-term news, but what exactly does that mean, for rev L ?
Will some future revision L have the full swing osc, or not ?
And just to make it 100% clear I'm NOT the one that marked this solved!!!!!!!!!!!
Who did that behind our back ?
+1 to what about L
what about 328PB (still sold as 20MHz which they only can run if you breast feed them)
@sparrow. I marked it as solved because Atmel's Andreas advised in post#8 that the REV K version will not be produced. Don't you believe him?
look at #12 and #13
@Sparrow and Who-me
As Alohre pointed out we realized that we made a mistake and cancelled rev K. We noticed a bit too late that the oscillator had an issue in rev K. Shit happens.
I hope that we learned from the mistake and will not ever again release revisions that introduces such critical erratas.
We do not currently have any plans to introduce new revisions for this device, but in case we e.g. have to move it to a different fab to keep the cost down, a new revision may be introduced. Hopefully without any erratas ;-)
I know that we all make mistake, but sorry I don't buy this :
. We noticed a bit too late that the oscillator had an issue in rev K. Shit happens.
Don't tell me that this aren't the same problem as with the 328PB, but because it's an other chip is was bad but accepted, (I guess because it's cheaper to make, or the fab can make more ).
And on the side line I use 328PB on a design running the internal 8MHz and it works without any problems. (I needed the extra IO's , and in the long run I expect it to be cheaper )
I think the problem with the 328PB is that they called it a 328 instead of giving it a different number. It is in reality a totally different chip.
+1
but that's an other story.
This it about the process the chip is made with, and that seems to have problems with some of the "analog" parts.
My guess is that the 5V make the oxide layer too thick, so the lack of gain is a problem. (like it's a 3V proces they try to tune)
Well, if you develop two products in parallel, using the same process with the same oscillator block...
The ATmega328PB is a new product, with a separate order code (even if you do not like the name): Users that cannot do without a full-swing oscillator can choose to not use that device. For the 328P it is a different story as it was a released as a revision change. It is not possible, in general, to order specific revisions and thereby the oscillator issue became a blocker for many ATmega328P users. We have fixed that now by cancelling the rev K.
Btw, it was our new management that supported the cancellation of rev K; they acknowledged that this was to the benefit of our users. 
Btw, it was our new management that supported the cancellation of rev K; they acknowledged that this was to the benefit of our users.
The sun shines from their very backsides and all is right in the world? 
Thanks for your great work and honesty! I think the 328 is one of the most popular devices. Now, the logical continuation would be to some day create a 648 (not 648B). ;)
I don't know how much space is left on the die and if it is enough for 64kB of flash, but at least a little more RAM and especially EEPROM would be verrry nice. :D
JC
My guess is that they can make a 648PB on the same space as a 328P ;)
Yeah, but it should be backwards compatible, i.e. also run on 5 Volts. That makes all the structures bigger.
A "648PB" would be ok for me, if it included a working 20-MHz-full-swing mode!
Where can we download the old setup of the datasheet, it doesn't have so many errors? (many new people get's confused )
The previous datasheet still exists, but for how long? Better save it if you really want it.
I did mean a real old datasheet , the old format, because there are missing and wrong info (at least confusing) info in the new datasheet format.
I needed the info for an other thread, and I found an old one (2012) on a stk500 DVD, so I could answer.
It's just sad for new people that important info are missing just because everything needs to look nice.
I did mean a real old datasheet , the old format, because there are missing and wrong info (at least confusing) info in the new datasheet format.
I needed the info for an other thread, and I found an old one (2012) on a stk500 DVD, so I could answer.
It's just sad for new people that important info are missing just because everything needs to look nice.
Could you give me the specifics on that - what was missing and confusing ? I'll forward it to the datasheet team and see if we can get a fix in future releases of the DS.
for this the lack of IO addr compared with memory addr for IO's
the old format (when the table have high addr in top ), show both addr. and have a fat divider bar at IO bit end, and IN/OUT end.
It was for this confusion :
Oh, I see the problem. Indeed, some information is missing that can cause confusion.
Thanks for the info
FIY in the datasheets missing this in the table it has been moved to the register descriptions. E.g for PORTB register you have the following information:
Name: PORTB
Offset: 0x25
Reset: 0x00
Property: When addressing as I/O Register: address offset is 0x05
I agree though that it should be in the table as well. I'll see if it is possible to get this restored.
alohre:
What are the technical qualifications of the people responsible for making those regressive changes?
I guess sale!
for xmega's it make sense to look at it in modules, so you point to module n, and the extra code space don't really matter.
then someone (who is the question), wanted the old ones to look like the xmega, it's just don't really make sense for small parts!
if the changes get's made then remember fat lines after 0x1f and 0x3f where IO bit end and IN/OUT end.
And they should have the old direction so the notes is near the first registers.
By the way I looked at the new instruction set manual, where should errors be reported?
RickyB
>What are the technical qualifications of the people responsible for making those regressive changes?
mostly Ms.C but also one Ph.D. :)
We recently changed how datasheets are generated from manually writing each datasheet in Framemaker (hard to do and hard to scale) to a more dynamic system using SDL (this is also what enables the instant datasheet lookups and improved help system in AVR Studio). in this migration we obviously lost some info users find valuable.
As Anlohre says above, let us know the pain points and w'll try to get it added
Andreas
As Anlohre says above, let us know the pain points and w'll try to get it added
Three posts from another thread, starting here:
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
RickyB
>What are the technical qualifications of the people responsible for making those regressive changes?
mostly Ms.C but also one Ph.D. :)
(...)
Since the Bologna process, most kids fresh out of College are Ms.C so...
It's M.Sc.
Leon, they're a funny lot the Norwegians. Bunch of cross-dressers I've heard! Some of them prefer to be known as "Ms C" ;-)
... Some of them prefer to be known as
RickyB > RickB
While on the subject of data sheets, is there a form of protecting the integrity of a pdf while still allowing users to add notes/corrections to a data sheet that are obvious after the fact additions? This sort of thing has come up before.
RickB
is there a form of protecting the integrity of a pdf while still allowing users to add notes/corrections to a data sheet
The Macintosh "Preview" app that is supplied as a standard document viewer in the MacOS will allow annotation of PDFs, out of the box.
Jim
Simple matter to regenerate an Atmel PDF by 'printing' it with the likes of CutePDF under Windows, or even more simply under Ubuntu by using the system default 'print to file' feature. Annotate that.
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
Just tried MacOS Preview annotation on an Atmel spec sheet. I got the message: "The original document can't be changed, so a duplicate with your changes has been created". So, yes, there are "protected" documents but with strategies to get around that protection.
Jim
Thanks. Didn't realize it would be that easy.
Well, if you can see the pdf without inputting any password, the "protection" is just the goodwill of the program reading the file...
