Gen7 20Mhz Crystals Capacitors

I have been looking over the Gen 7 1.4.1 schematic/parts list and
noticed that the capacitors used for the crystal don't match what
the crystal says should be used.

The crystal is listed as 18pF load and the parts list has 22pF instead.

Is there a reason the 22pF was chosen over 18pF?

It seems like the capacitor might have been an after thought change.
They don't fit properly in the spacing on the board and required the
leads to be bent for it to fit.


On another note:
Also, I have noticed that my ATMega644 @ 20Mhz cannot successfully
talk at 115200. I have to reduce this to 38400 for the communication
to work. I never gave it much thought because of having too many
questionable parts to justify it being a Gen7 board issue.

I am currently using the AT90USBKey as a usb2serial adaptor and didn't
know if that could even handle those speeds even though the AT90USB1287
says it could. The board uses an 8Mhz crystal giving it 8.5%/-3.5%
accuracy. So it looked like that was the possible cause but couldn't prove it.

Quote

the capacitors used for the crystal don't match what the crystal says should be used.

So far I didn't manage to talk to by crystals. They just sit on the board and swing. What makes you think a different value should be used?

For communications, you could make a USB-B extension board: [reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

If you don't match the load capacitance of the crystal it gives slightly the wrong frequency as the frequency stated is at the recommended load capacitance.

The capacitor value is not the same as the load capacitance though. IIRC you take the value of the two capacitors in series and add the chip's pin capacitance and the track capacitance to get the load the crystal sees.

---

[www.hydraraptor.blogspot.com]

Quote

If you don't match the load capacitance of the crystal it gives slightly the wrong frequency as the frequency stated is at the recommended load capacitance.

If I could find documentation on how to calculate this capacity, I'd happily follow that. So far I found only pretty vague formulas and 22pF was always in range. A bit too low according to some formulas, a bit too high according to others.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

This is the formula I have always used and a quick Google confirmed it.

1/(1/C1 + 1/C2) + Ci + Cp = Cl

where
C1 and C2 are your capacitors
Ci is your chip's input capacitance (~1pf typically)
Cp is the circuit's parasitic capacitance (~1pf typically)
Cl is your crystal's load capacitance

---

[www.hydraraptor.blogspot.com]

In the data sheet of the 644P, the correct values are listed (http://www.atmel.com/Images/doc8011.pdf page 33, chapter 6.4).
The capacitors must have an equal value and for operation at 20MHz they should be in the range from 12pF to 22pF, so both actual values (22pF and 18pF) are valid

Edited 1 time(s). Last edit at 01/12/2013 04:12PM by z0ttel.

They are valid in the sense that the oscillator will oscillate but it will only give the frequency written on the crystal if you use the formula above. If not it will be slightly off.

---

[www.hydraraptor.blogspot.com]

Yes it may be off, but does it matter at all? Different tempereratures, the age of the crystal, and several other effects will always lead to little tolerances in the actual clock. The microcontroller manufacturer therefore considers this for the design of the clock input stage and gives recommendations for the input capacities. I would rely on the data sheet in this case - because they are proven to work.

If you are using the crystal to drive any other circutry than an uC, then the clock drift might matter and considering the exact load capacitors might become more important.

Edited 1 time(s). Last edit at 01/12/2013 05:33PM by z0ttel.

Quote

I would rely on the data sheet in this case - because they are proven to work.

The datasheet specifies a range 12-22 pF, so yes one should stay within that range but when it comes to choosing a value in that range one should pick one to suit the chosen crystal using the correct formula. Whether it matters or not depends on what you are doing with the processor's timing but its not exactly difficult maths, so why ignore it an use an arbitrary value in a published design? I might do if I was hacking something together from parts I had but not if I was buying them specially or advocating somebody else buy them.

If you are going to pay for a crystal and then throw away the accuracy it gives you might as well use a resonator as they are cheaper. Some have built in load caps, but again you need to select them to be appropriate with the CPU's pin capacitance.

---

[www.hydraraptor.blogspot.com]

I have a feeling that it doesn't make much difference. The parasitic capacitance can add up to a few pF which swallows up the difference between 18pF and 22pF. My view is that the crystal will be accurate down to a tiny fraction of a percent like 30ppm so unless you do something badly wrong, it'll be fine. Tuning the circuit to the nearest pF is not necessary, or even possible unless you control the temperature.

The formula seems straightforward enough, but even if you look at the datasheets they often don't contain enough information to calculate it. It doesn't help that they use different terms in different places.

Thanks for all the feedback guys.

I've been looking into a dual board setup and this exact thing might cause an issue.
Timing will be done with a 644* and display/sd card/usb will be driven with an 8u2.

The idea was to link them via 3 wire spi and buffer between them with 512kb sram. All of which clock differently but the main concern would be the link between them. 644 at 20 mhz and 8u2 at 16 mhz makes timing a bit hard without extra issues.

I might just move them both to 16 mhz but that would slow down retrieval of queued commands in the sram.

Still in the development stage.

Normally, the communication via SPI shouldn't be a problem, so could you please give some details about your setup (which MCU is the SPI-master which MCU is the SPI-slave)?

In the AT90USB64/128's data sheet there's an detailed description about this setup on page 168/169. There's also a note which says that if this MCU is configured to be the SPI-slave, the SPI clock shall not exceed fosc/4. On the AT90 side, this would mean a clock of max 4MHz, so your 644P's SPI clock must be configured to fosc/8, because fosc/4 would still be too high.

First, thanks for the formula, @nophead.

Quote
ItsDrone
The idea was to link them via 3 wire spi and buffer between them with 512kb sram.

Sounds like a good plan, but I wouldn't put SRAM in between. More complexitiy without gain. Perhaps it makes things even worse. Think of the user pressing a button to abort a print ... how do you get that through to the '644 CPU immediately? How about recovering from communications errors (bad CRC checksum)?

Quote
z0ttel
On the AT90 side, this would mean a clock of max 4MHz, so your 644P's SPI clock must be configured to fosc/8, because fosc/4 would still be too high.

True. The solution would be to use the slower chip as the master.

In general, SPI is synchronous, so, except for a maximum clock rate, timing is totally uncritical. There isn't even something like an expected timing, like a baud rate. Bits are read as the clock signal toggles, no matter how much time there is between two toggles.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Good points.

This is how I plan to work it out.

Both are master and both are slave.

The display board (8u2) interfaces the user's inputs either from the keypad/display or via usb connection.
This board passes a request for bus control and then sends the info directly to the 644. (no delay commands, basic communication).
When it comes to G* codes it will request an address from the 644 and then translate the text code into a preformatted data structure and store it in the SRAM. The act of doing this updates the 644 of pending command in the circular buffer ( external SRAM ).

When the 644 is processing one command it will request the bus control and retrieve another command out of the SRAM. This can queue up 4/8 commands internally in the 644 and store a large chunk externally and pull on demand.

The idea behind this is that the commands coming in are processed independently of the time sensitive clocking and queued up for fast retrieval. The SRAM can talk at 20Mhz which won't ever be reached but can be run as fast as the 644 can read/8u2 can write. Which at Fosc/4 would be 51uS plus the overhead of addressing the ram. During such a transfer the 8u2 is not even listening so it can run the bus at its quickest rate.

The SRAM could handle 2,048 commands queued up, which at times, can be a complete file.

All of the CRC checking would be done by the 8u2 during the queue process. So, if the host supports it, it can request the command be sent again to recover a CRC error or even recover a USB connection disruption if the buffer isn't drained in that time period.

Most of this is still in the idea phase and I wanted to reduce any unknown issues before they show up later.

I have worked on multi-processor systems with shared RAM both professionally and personally, so I think this is an interesting idea. It would be a lot of fun to work on. I don't like to deny anyone their fun, but if this is for anything other than an educational exercise I can't see it is going to be cost effective, and will take quite a lot of time to develop.

If there weren't larger chips available which could easily do all of this more simply, then it would make sense, but there are dozens available. However, I assume you will ignore that and carry on regardless

There are some things that need thinking through. For example, the Atmega644 has an external memory interface with a 16 bit address bus, so that can access a max of 64KB. You'll need to do your own interface to handle 512KB (19 address bits). That is something like 30 IO lines to access the SRAM, so you will want to multiplex those up with some external latches. AFAIK the 8u2 doesn't have built in external interface, so you will also need a similar set up for the 8u2.

That adds a bunch of chips and all that bit banging and latching ends up being pretty slow. Now, if you have spare CPU cycles and just a need a big bunch of RAM, that is fine. If however, you are trying to improve performance then all the overhead negates much of the benefit of buffering, and you have added cost and complexity and used up a lot of IO ports.

Then there is the issue of contention for the SRAM. Unless you have genuine dual-port RAM, it is likely to just become a bottleneck. It will probably be more effective to have a fast comms link between the 644 and 8u2 and buffer in those chips.

If you had two independent SRAMs, you could at least do double buffering. So while the 644 is draining one bank, the 8u2 is filling the other, virtually eliminating the bottleneck. However, it would need some extra logic to multiplex the two banks.

It would be simpler hardware-wise to use a third CPU to manage the SRAM, and use a comms link on either side. This SRAM controller could buffer data packets and provide simultaneous access to one or more FIFO buffers.

bobc Wrote:
-------------------------------------------------------
> I have worked on multi-processor systems with
> shared RAM both professionally and personally, so
> I think this is an interesting idea. It would be a
> lot of fun to work on. I don't like to deny anyone
> their fun, but if this is for anything other than
> an educational exercise I can't see it is going to
> be cost effective, and will take quite a lot of
> time to develop.
>
> If there weren't larger chips available which
> could easily do all of this more simply, then it
> would make sense, but there are dozens available.
> However, I assume you will ignore that and carry
> on regardless
>
> There are some things that need thinking through.
> For example, the Atmega644 has an external memory
> interface with a 16 bit address bus, so that can
> access a max of 64KB. You'll need to do your own
> interface to handle 512KB (19 address bits). That
> is something like 30 IO lines to access the SRAM,
> so you will want to multiplex those up with some
> external latches. AFAIK the 8u2 doesn't have built
> in external interface, so you will also need a
> similar set up for the 8u2.
>
> That adds a bunch of chips and all that bit
> banging and latching ends up being pretty slow.
> Now, if you have spare CPU cycles and just a need
> a big bunch of RAM, that is fine. If however, you
> are trying to improve performance then all the
> overhead negates much of the benefit of buffering,
> and you have added cost and complexity and used up
> a lot of IO ports.
>
> Then there is the issue of contention for the
> SRAM. Unless you have genuine dual-port RAM, it is
> likely to just become a bottleneck. It will
> probably be more effective to have a fast comms
> link between the 644 and 8u2 and buffer in those
> chips.
>
> If you had two independent SRAMs, you could at
> least do double buffering. So while the 644 is
> draining one bank, the 8u2 is filling the other,
> virtually eliminating the bottleneck. However, it
> would need some extra logic to multiplex the two
> banks.
>
> It would be simpler hardware-wise to use a third
> CPU to manage the SRAM, and use a comms link on
> either side. This SRAM controller could buffer
> data packets and provide simultaneous access to
> one or more FIFO buffers.

I have found this forum discussion because i was looking for some answers. I am looking for a document that specifies how capacitors connected to cristals efect it's operation..
I am a student at Electrical engineering faculty and i don't know much about crystals and so i am asking for your help.
I found at EPSON web page that load capacitors are tehe because: ensuring frequency stbility, enabling oscilation, negative resistance, reducing the startup time of an crystal.

I am looking for a simple tutorial or explanation how capacittor efect th crystal operation. and i already know why they are there.