- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This could apply equally to PSoC 3 as well as PSoC 5.
There is no doubt that the clock and timing systems in the PSoC 3 and 5 are impressive in their range of features and options. This flexibility comes at a price, though, because you need to configure a complex system correctly. Design descisions yout make at the outset might have implications down the road. You might also need some good fortune and a bit of clairvoyence to get it right first time!
Yes, I'm joking a little bit, but I thought I'd pose the question - whats the best practise for configuring the clock system?
For instance, do you just leave everything at the default and hope for the best?
When do you decide to use an external crystal, or oscillator, rather then the internal oscillator?
Application note AN54439 gives some great information on configuring PSOC3 and 5 for external crystal or ceramic resonator.
If your clients are anything like mine, you may not even know at the original design stage what options you'll need. You may initially think that the internal oscillator will be good enough, but then later the client asks you to add a USB HID interface, or a UART with low tolerance, or maybe add some requirement for precise timing of incoming signals. This happened to me recently when the cllient decided that the product which was already near production stage should suddenly have a requirment for a USB HIB interface. Fortunately in this instance I had already specified an external 24MHz crystal.
So, how do you do yours? And have you ever been caught out by using an internal oscillator and wished you'd used a crystal, (in any architecture - not just PSoC)?
- Labels:
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well. Yes it is very common for a late change of specification where the client would say that it is not an option, has to be included or else....
I think the best way to do this is to reserve the pins for the XTAL and use the inernal clock. I'll also put the Xtal and capacitor on the PCB just not fitting the component. This would give you option for such a late change and no need to redo the PCB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As usual: it depends. There are rewquirements for x-tals as usb or rtc oj even just precision. What are the costs for a pcb-area where two Cs and an xtal can be mounted? If space and and additional mm² pcb to pay for allows, I would suggest to develop the boards with a x-tal and put it on the bom when needed. So, as I would say, extending the flexibility of PSoCs to the board.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I typically go for an external crystal. It makes anything depending on proper (external) timing more reliable. Especially UART and USB require this.
After that, I look for the frequencies my components need. For example, if you want to get a specific sample rate for and (SAR) ADC, you need a specific clock (e.g. for 500ksps you need 9.5MHz). This creates the need for a specific main clock. And if you have multiple needs like that, you need to balance this out with the different clocks. For that I separate sometimes the PLL and the master clock. If I don't need that, I go with the highest clock for the PLL which suits my needs, and which compiles withour warnings (I have a design right now which goes only up to about 55MHz because of the digital logic. I ended up with a master clock of 38MHz which is 4 times what I need for the ADC).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Some great suggestions there.
I think it actually highlights the flexibility of the PSoC system - the internal clocks and PLLs etc are all very flexible.
When it comes to design I would agree - best to layout for a crystal and a couple of caps, which can be stuffed or not stuffed depending on requirments as they unfold in the product lifecycle.
Best wishes,
Kenny.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You might add pads for one of the canned oscillators, as they have more
defined specs than a simple xtal - C network solution. Especially since
a xtal solutions accuracy, drift, does not include the active element issue
in the osc loop, hence is only a partial predictor of accuracy/drift. So if you
are asked for a 5 ppm solution that won't come from a bare xtal implementation.
You should be able to lay those pads out so that either xtal or canned osc
fit pretty much in same board area.
Just a thought.
Regards, dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes - thats another great solution. In the PSoC 5 design that I mentioned earlier that has a PIC doing the ethernet tasks, I use a canned oscillator for that chip.