search

hackndev / zinc

The bare metal stack for rust
zinc.rs
Apache License 2.0
1k stars 100 forks source link

Expand "pll" in platform tree #178

Open kvark opened 9 years ago

kvark commented 9 years ago

It's surprisingly cryptic, given how led directions are verbose (for example): { direction = "out"; } Googling "pll" gives me the Pretty Little Liars show... not sure it that's what you meant.

All in all, there should be an agreement to not use any abbreviates in the platform configuration, unless they are chip names. Hence, "gpio" may need to be expanded as well.

farcaller commented 9 years ago

"GPIO" is a well-known domain term, so expanding it would make things more confusing. Now, PLL is really the same thing, you cannot really argue about CPU clock without having at least some idea about phase-locked loop, right? I mean, there's those m and n, and you must type in reasonable values, so you must read MCU docs and must know what is PLL.

I did experiment with source_frequency / target_frequency, but it's not really a linear process and it very much depends on specific hardware environment.

It doesn't make much sense to shorten direction to dir on the other hand.

bgamari commented 9 years ago

I agree that PLL is a pretty well accepted term and seems quite appropriate here. Moreover, in general I think that we should keep verbosity to a minimum in platform tree definitions. This is what documentation is for.

bharrisau commented 9 years ago

Maybe something for Zinc 2.0 is to get to the point where you can just specify the clock rate and Zinc works out the best settings to achieve it.

kvark commented 9 years ago

@bharrisau I believe @farcaller started with this approach (according to his public talk) but then switched to manual configuration. Not sure if he has any plans to revisit this decision.

farcaller commented 9 years ago

Yes, as I commented above, there is no one best combination for pll, too many unknowns. The source frequency -> cpu frequency equation has a varying number of solutions, for lpc17xx the number is usually above ten. You need to tweak pll as appropriate for your specific hardware setup.

Disclaimer: I'm not an electronics engineer and I have quite a basic understanding of the process. My knowledge is derived from stackoverflow and NXP forums. If someone out there can give me a good formula to solve the problem, I'm surely going to integrate it into the pll code.

kristofferkoch commented 9 years ago

I'm an electronics engineer, and having previously worked as a designer at a microcontroller company, I really appreaciate that calculating a good clock configuration is indeed a difficult problem. Not only do you have a target output frequency, but what about power consumption, lock time and jitter performance? There are a lot of variables to optimize. Also, some chips have alternate frequency multiplication techniques such as Digital Frequency Locked Loops etc.

I think the current spec of the pll in the platformtree is natural and concise, but maybe it could be nice to have the intent stated explicitly, e.g. target_freqency=50_000_000, and then a compile-time check will verify that indeed the given source_frequency, m, n etc. will give you what you expect?

farcaller commented 9 years ago

@kristofferkoch, thanks for your insight. I already have a check on my TODO list to verify that pll config values are in a valid range, and adding an optional target_freqency is actually a very good idea to confirm the calculations. Filed #179 on this one.