Stabilizing the Trinket M0 CPU Clock Speed

Adafruit's tiny microcontroller platform. Please tell us which board you are using.
For CircuitPython issues, ask in the Adafruit CircuitPython forum.

Moderators: adafruit_support_bill, adafruit

Please be positive and constructive with your questions and comments.
Locked
User avatar
Govner
 
Posts: 175
Joined: Wed Sep 14, 2016 4:42 pm

Stabilizing the Trinket M0 CPU Clock Speed

Post by Govner »

Hi Adafruit Customer Support,

Happy Friday -- a positive thought. We'll keep it light today. I have edited this a number of times to try making it clearer at the expense of adding length. I sincerely apologize for repeating myself and I promise that on subsequent posts, I will use an external editor so I can see the entire page instead of just the next paragraph. I'm sure my post here exceeds norms in terms of lengths but, for the most part excluding repetition, the facts offered here are pertinent to reducing the back-and-forth Q&A that forum moderators must suffer to get all the information needed to affect a solution. At least I have provided you with that I hope. Again, sorry for the length.

Before I submit my questions about stabilizing the Trinket M0 clock, let me say that I get it. No crystal. So, why would we use a device needing a stabilized clock when the device has no frequency standard (other than RC) from which to reference internally? Great question. Our answer is simple. We thoroughly tested the Trinket M0 for our purposes, designed around them, and it has been happy Fridays ever since. Until it wasn't. That sounds like a downer but, really, I am totally confident that the CPU clock variation issues we have have a specific cause. We want to figure out what that is. It's NOT random. It's a fixed deviation. Experience tells us that fixed deviations have fixed, consistent causes. THAT's what we need help to solve. We have lots of M0s on order and are committed to using them as planned if we can just drill down on the CPU clock variation issue. Let's get started:


I have an idea/question that, hopefully, we can work together to solve the issues. In an earlier, similar but unrelated post, we discussed the reasons that the USB connection 'torqued' the CPU clock module(s). We work around that issue with little impact upon us. I say this to be clear that the following discussion is a completely NEW development - unrelated in any way to USB connections since all the data gathered upon which we base our questions was obtained by running the same FFT calculations. As you know, FFT calculations in real-time frequency analysis are totally dependent upon CPU speed - both are connected at the hip, so to speak. I mention that our test results are mathematical, unchanging, and stable so that we don't get deflected onto some tangential issue related to test methods. This fact was our highest priority so that conclusions could be made upon which we/you might base a solution.

First, thanks for the earlier ideas of product substitutions in my post of the USB-connection-induced CPU clock freq deviation issues.

I am sure the same product suggestions would be repeated here but we are past the point of substitution. However, just FYI, I did purchase a couple of your suggested products (sans Feathers) and evaluated them along with the Trinket M0. But the fact remains that, in the initial samplings of Trinkets, performance from the product line did not vary significantly. It also bodes well for Adafruit that we transitioned to the M0 for its speed and consistent footprint with other products. We tested a few M0s and were completely satisfied with performance (excluding solvable USB connectivity issues). We carefully tested everything and as a result, we actually use MULTIPLE M0s in each project. It's a modular approach that simplifies troubleshooting and increases functionality and flexibility. We committed to the Adafruit products and have a significant quantity of M0s on hand, assembled and ready.

Now, for the problem: In about 5% of the Trinket M0s we receive, the CPU clock frequency runs at a slightly different (though constant delta variation). (Again, it's unrelated to any USB connection or external stimuli.) This subset of products all have nearly the exact same deviation in CPU clock speed. We can only measure it indirectly, obviously, using clock-speed-dependent math (FFT) but in doing so, it's also very interesting that the same deviation (let's call is CLOCK_DELTA) occurs in not only the same magnitude but also in the same direction. I can't tell you precisely which side of normal the CLOCK_DELTA is (HIGH or LOW) but because the resulting FFT calculations reveal a constant deviation, whichever it is HIGH freq or LOW freq deviation, the FACT is that the deviation is ALWAYS the same among this 5% group. That say a lot, wouldn't you agree. That's not something that fits into chip manufacturing specs. There is some identifiable reason for this CPU CLOCK_DELTA and we haven't the inside track on the product to run down an answer.

The first thought that pops into mind is that, of course, without a 32.767 khz crystal standard, one would expect slight deviations. Not so fast. We actually focused on product stability in our initial testing. We tested 4 or 5 M0s initially and variations were hardly even noticeable and certainly any normal osc variants were totally usable in our FFT applications. We allowed for the normal behavior deviations + a slight tolerance above that. However, this set of facts has now changed. We are kind of dead in the water because without access to certain details of manufacture, we cannot help much and must yield to you for advice here.

When we test each Trinket M0 that arrives, we find that 99% of the time, there are two distinct behaviors: The first, most dominant group of Trinket M0s is the one where the CPU clock runs at the typical speed of the 'average product' purchased. This is the standard we came to expect and was that of Trinkets used during the R&D phases or our projects. The second group of Trinket M0s represents roughly 4-5% of the units received. What's interesting is that the deviation in CPU clock freq that they are running is a CONSISTENT deviation. There's nothing random about it. This is NOT a normal, random drifting tolerance of an oscillator's internal RC components -- it's predictable. The test results of any given M0 will fall into one of these two categories 99% of the time.

Since facts we would need to help resolve this issue are not available to us, would you mind taking a look to see what might explain this? Perhaps there is a remedy. We researched the data sheets relative to the internal clock modules used by the SAMD21 but most of the time, without the information that you have pertaining to any code affecting the CPU clock, we can only offer consumer-level input for this and appreciate anything you can share that might provide a route to a solution.

The simplest solution might appear to be just abandon the Trinket M0 implementation in favor of other 'crystalized' products. We are past the point where we can shift to other Adafruit products, and, since we use 2 of these in each project, moving from using 2 x $8.95 devices to using 2 x $18.95 USD devices would break the bank of feasibility to use Adafruit items. Against the proverbial wall, we have another suggestions/question and our hope lies with your response.
--------------------------------------------------------------------------------------------------------

1. Is there anything in the code that comes with the units which might affect any 'pre-scaling' or otherwise set the CPU clocks in any way? I suggest this because it's a fact that changes have been made to the firmware of these. We have one batch that has a previous set of file complements and another batch that has another. With the second ones, we encountered more difficulty with USB connections.

NOTE:
We already placed another sizable order of units and while we await their arrival, we have some time. Clearly, we are open to any solution. One good thing is that because we use multiple M0s in each project, we single out the 5% bad actors and use them where no FFT calculations are needed. We really don't like having to do that from a configuration aspect -- it creates a potential nightmare when trouble-shooting down the line.

One solution might be to add a crystal. So, please help us with the information to add the 32.767 Khz crystal externally to the board.
If we're correlating your schematic and the SAMD21 data sheet correctly, you have assigned the DotStar LED to the pins ordinarily used by the 32.767 Khz crystal. If that's true, then perhaps it's possible to R&R the DotStar with a ceramic osc? But, then, your code would have to be modified slightly. Might the motivation for this be an upscale version of the MO? We buy lots of these but that would certainly remove doubts that our projects, in view of the recent downturns, are unsustainable. Your help here would do wonders in that arena. Thanks.

If no solution comes to mind to this point, please address this set of conditions:

What explains the CONSISTENT speed deviation in CPU clock speed M0-to-M0? I am 99.999% certain that this is NOT result of MicroChip manufacturing deviations. If it is, it would be a first in my experience. A more likely scenario is that there is an SMD component variation, either tolerance or design value change/installation during local manufacturing of the Trinket M0s. We can float that theory here in search of variants between the 5% units and the others but it requires destructive testing -- not something we want to do when you have access to those answers directly. The initial inspection of the data sheet doesn't yield much except that perhaps there is some validity of the variations resulting from the DotStar scenario mentioned previously. We are grabbing at straws on that one but that's what this all amounts to when lacking all the whats, whens, and wheres. So, before we head off in that direction, what insight can you offer please?

As I mentioned, we are committed to using these great devices. And, because the variations have a constant value, there MUST be a very specific reason why the CPU clock runs a fixed amount differently in roughly 5% of the units we receive. By the way, we looked microscopically at markings/layouts/etc -- not forensically but for anything that might jump out as a causal factor. Are the silkscreen markings ( 4 1 1 7 for example in segmented font) related to manufacture date?

THANK YOU very much for the usual great Adafruit customer support. Your input is critical to decisions we make. We have great faith in Adafruit as a potential supplier for needed components and need to be confident that when we use them we can maintain our projects by replacing a potentially failed Trinket M0 with one of like kind and performance. Thanks again.

Best,
Gov

PS:

User avatar
Govner
 
Posts: 175
Joined: Wed Sep 14, 2016 4:42 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by Govner »

Sorry, I was thinking about the facts of my post.. I had said 5% of the units were deviants but it is actually 5 of 20 units that performed in this precise way. 25% not 5%. On delivery of the next order, we will test each one and report back to you. I only make the correction to the earlier posting's data to perhaps provide a link to the production as clue for IDing where the problem might be just in case some production variation can be identified. Not an accusation -- just a way of solving issues though process of elimination. All good.

User avatar
adafruit_support_mike
 
Posts: 67454
Joined: Thu Feb 11, 2010 2:51 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by adafruit_support_mike »

I agree that consistent behavior suggests a consistent cause. My guess for the cause would be a difference in the PLL prescaler settings when the chips are configured during the manufacturing process.

There are a lot of potentially related issues though.

For the sake of vocabulary, the PLL is a circuit called a Phase-Locked Loop. In loose terms, it's a self-adjusting oscillator. Specifically, it adjusts its frequency so the beginning of every Nth pulse has a well-defined phase offset from an external reference signal.. usually 90 degrees. Microcontrollers use a PLL with a fast-but-unstable core oscillator, then derive the external control signal from a divide-by-N circuit. That arrangement tends to self-correct drift in the core oscillator by forcing it to maintain a fixed phase relationship with itself N ticks ago. The PLL's ability to keep the core frequency stable is limited by the value of N, for exactly the same reasons an FFT's frequency resolution is limited by the width of the sampling window.

The PLL's relative stability doesn't imply oscillation at any particular frequency, so microcontrollers send the PLL's output through a 'fractional prescaler'.

Instead of doing 'N input ticks produce 1 output tick' like a logical prescaler, a fractional prescaler uses the scheme 'every M input ticks equal N output ticks'. That makes it possible to do fine adjustment of the ratios. For even finer tuning, there's an 'ignore 1 input tick every O output ticks'.

While the microcontroller is being tested at the factory, the system compares its native PLL frequency to a reference frequency and programs the fractional prescaler to tick at a known rate.. 48MHz for the SAMD21 family.

That's great as far as it goes, but in metrology you quickly learn that nothing stands still unless you take measures to keep it that way.

The biggest source of frequency instability all classes of oscillator is temperature variation, and semiconductors are especially sensitive.. you can turn any diode or transistor into a thermometer with 0.1C resolution across the -40C to 125C industrial range. The oscillators that form the core of a PLL will vary by a few percent across a +/-10C span.

That's a secondary reason for using crystals: the AT cut that's most common only varies about 50ppm across the -20C to 70C range, and does that in a predictable way. You can temperature-control or -compensate them down into the 1e-12 range.


So.. with most of what I said about the PLL being little more than context, did you control for temperature when you did your tests? Doing them under controlled temperature would be ideal, but testing new boards in parallel with a group of three control boards would provide a decent baseline.


At a more practical level, you can change the values in the fractional prescaler to adjust the clock speed. This thread at Github discusses it:

https://github.com/adafruit/circuitpython/pull/785

Changing the prescaler settings won't fix the thermal sensitivity or other sources of drift inherent in the built-in clock, but at least you can get boards into the same neighborhood under similar conditions.

User avatar
MizeSoundGuy
 
Posts: 25
Joined: Sun Apr 05, 2015 4:09 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by MizeSoundGuy »

I have read all of this as well as the previous (brief) conversation on why being connected to USB causes the Trinket M0 to run at a different clock speed than when not connected (powered from a wall wart). I am not using Circuit Python in my application, perhaps only because I need an accurate clock... Which brings me to this thread.

I am also an actual engineer and know what a PLL is (although it's been decades since I used one) and have successfully done 95% of what I need to do on the TM0. I have a timer interrupt that triggers an ISR every 129us which sets a variable that tells a bit of code in the loop() to make one pass through and clock 4 values out to an MCP4728 DAC. My problem is that I develop the code connected to my Mac and will run the thing off of wall wart when I am done. When I run off the wall wart, I get an interrupt every ~132us rather than every ~129us. That is enough to change the period of the sine wave I'm "generating" (reading out of an array) and hence the frequency. When connected to USB, I get 60Hz, when on the wall wart I get 58Hz.

Is there a way to tweak the prescaler in C++ to get the clock closer to what it has when sync'd to USB?
I have tried to introduce a scaled interrupt time so that when I am not on USB the timing is close to correct, but that seems like a kludge.

And Mr. @Govner, did you ever resolve your clock calibration issue?

I love the Trinket and want to use it in everything but may need to jump to a crystal-bearing board for this. I am not as cost-sensitive as some because I'm probably only going to build 3 or 4 and the other system components DWARF the cost of the processor board. But there is something very satisfying about making this little guy do what I want it to do.

Thanks.

User avatar
Govner
 
Posts: 175
Joined: Wed Sep 14, 2016 4:42 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by Govner »

Hi MizeSoundGuy,

Your post was VERY interesting and mirrors some my own experiences. Thanks for sharing all the specific details often missing.

To answer your question as to whether or not I'd solved my issues, I'd have to say "yes" and "no". 'Yes' in the sense that my objectives were met but only because I labored to produce a workaround. But, I never could figure out a way to resolve the clocking variations.

I do recall discovering that even if I have power supplied simultaneously by both the USB and a DC source, the USB rules the day and 'sets' the clock speed. And, even if I subsequently disconnect the USB and default to the DC power supply, the clock speed remains as determined by having had the USB connected. Adafruit's support explained why that was happening but it's above my paygrade to figure out it it's possible to manipulate the timebase once the USB has caused the TMO to 'lock in' a given value. I did consider adding an external crystal to completely eliminate this issue entirely but, as I said, it was easier to create a workaround in software, although I doubt it would be useful to you. My application used audio FFT processing and as with your issues, the clock frequency impacts the results. I attempted an "auto-calibrate" feature bye adding an off-board audio-frequency standard alongside the TMO. At the beginning of the Arduino sketch, I apply the TMO's FFT analysis to that 1000 hz standard and the resulting value is compared to expected. The result of that is used to select correction arrays containing non-linear correction factors that I generated empiracally. It was a tedious process and, in the end, though the project was completely successful, I should have worked harder to find a clever way to modify the hardware instead of implementing the not-so-clever (albeit effective) workaround. The saving grace was the SAMD21's large memory capacity to hold the correction factor arrays.

So, I guess the conclusion is that while "to save space" seemed a good idea to eliminate the crystal, it limits the implementation of the TMO to time domains - and even there - I'd be double-checking data impact. All-in-all, the TMO was the absolute best choice of available BO boards for use in my project. I ended up with 30-40 of the little jewels and every single one of them (excluding clocking tolerances) worked 100%. I built eleven, full-scale PCB units with each one containing dual TMO uProcessors. The project was as a special application and gift to my niece who carted them all away last weekend.

If you do come up with a solution (and, I sense that you will) I would be very fascinated and entertained to read about it. I'm sorry that I couldn't have been more help. Are you inclined to modify the hardware with a piggy-back crystal osc clock?

Thanks,
Gov

User avatar
XRAD
 
Posts: 754
Joined: Sat Nov 19, 2016 3:28 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by XRAD »

The USB clock difference is interesting. Some open/closed loop clock changes....

from:
https://community.atmel.com/forum/samd2 ... -frequency


Code: Select all

To just set the main clock to 8MHz you can configure the OSC8M prescaler to divide by 1


SYSCTRL->OSC8M.bit.PRESC = 0;		// Set OSC8M prescaler to 1
To run at 48MHz you will need to set the flash wait states according to Table 37-39. (Maximum Operating Frequency):

	NVMCTRL->CTRLB.bit.RWS = 1;			// Set Flash Wait States to 1 for 3.3V operation


Then allow for an errata in accessing the DFLL register:

	SYSCTRL->DFLLCTRL.reg = 0;			// See Errata 9905
	while ((SYSCTRL->PCLKSR.reg & SYSCTRL_PCLKSR_DFLLRDY) == 0);	// Wait for DFLL synchronization complete


Then set the DFLL calibration register and configure the DFLL:

	coarse = NVM_READ_CAL (NVM_DFLL48M_COARSE_CAL);	// Load DFLL calibration from "NVM Software Calibration Row"
	fine = NVM_READ_CAL (NVM_DFLL48M_FINE_CAL);

	// DFLL default is open loop mode:

	SYSCTRL->DFLLMUL.reg = SYSCTRL_DFLLMUL_MUL (48000);		// Set to multiply USB SOF frequency (when USB attached)
	SYSCTRL->DFLLVAL.reg = SYSCTRL_DFLLVAL_COARSE (coarse) | SYSCTRL_DFLLVAL_FINE (fine);	// Set calibration (for when no USB)

	// Set DFLL for USB Clock Recovery Mode, Bypass Coarse Lock, Disable Chill Cycle,
	//   Fine calibration register locks (stable) after fine lock
	SYSCTRL->DFLLCTRL.reg = SYSCTRL_DFLLCTRL_ENABLE | SYSCTRL_DFLLCTRL_USBCRM |
	                        SYSCTRL_DFLLCTRL_BPLCKC | SYSCTRL_DFLLCTRL_CCDIS | SYSCTRL_DFLLCTRL_STABLE;
	while ((SYSCTRL->PCLKSR.reg & SYSCTRL_PCLKSR_DFLLRDY) == 0);	// Wait for DFLL synchronization complete

Setup Generic Clock Generator 0 with DFLL48M as source:

	GCLK->GENDIV.reg = GCLK_GENDIV_ID (0) | GCLK_GENDIV_DIV (1);
	GCLK->GENCTRL.reg = GCLK_GENCTRL_ID (0) | GCLK_GENCTRL_SRC (GCLK_SOURCE_DFLL48M) |
	                    GCLK_GENCTRL_RUNSTDBY | GCLK_GENCTRL_GENEN;
	while (GCLK->STATUS.reg & GCLK_STATUS_SYNCBUSY);	// Wait till synchronization is complete


User avatar
Govner
 
Posts: 175
Joined: Wed Sep 14, 2016 4:42 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by Govner »

Interesting reading. I had seen that before but it reminded me of the one hair in the soup that I had concluded back when I began a workaround. That is, absent a crystal osc to use as a reference from which to scale everything, RC tolerances govern everything.

I concluded that any reference to absolute frequencies being used, scaled, clocked etc are only as accurate as the hardware/PLL oscillators (minus a 'rock' standard for reference). That's why, it seems to me, that the device can be 'driven' off frequency enough to notice. In any case, I relied on tech support which indicated to me that the "torquing" of the clock frequency was related to the USB/bootloader interface. I don't recall the specifics but they are contained in the earlier segments of these posts. I don't pretend to understand that but others may find the information helpful. Hope so.

Regards,
Gov

User avatar
MizeSoundGuy
 
Posts: 25
Joined: Sun Apr 05, 2015 4:09 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by MizeSoundGuy »

My skills are probably not up to fiddling with prescalers and doing what XRAD quotes, but it's worth looking at. Not sure where I put that code, but maybe I'll learn something in the process. I had hoped to do my project in Python (because I want to get better at it) but it's not fast enough for my project and I'm not good enough to write a library for the I2C DAC I'm using.

I've only tried one TM0, and I have two others. Maybe the one I am using now is something of an outlier and the others will have a no-USB clock closer to the yes-USB clock. I also have a couple of other M0 boards I can try, but the TM0 is so "cute" and small that I can hardly resist using it. I don't think I will be space-constrained, but I'll know how much room I have for a larger board next week. Having limited GPIO pins forces you to focus on what you really need and not on what you can do because you have so many IO pins.

I'm fascinated by the thought of running an FFT on a processor board that's only as big as a TM0.

Thanks to all, if I come up with a wizz-bang solution, I'll post it here.

Cheers!

User avatar
Govner
 
Posts: 175
Joined: Wed Sep 14, 2016 4:42 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by Govner »

Hi MizeSoundGuy,

We have similar enthusiasm for the TMO. I must admit, though, that I didn't resist "expanding" the pinouts with a MCP20008 via I2C. I also added external EEPROM (64kbit) via I2C. The final PC board that interconnects everything is shown in the photo. With all the "assets" at risk for damage by a misbehaving power sources, I added a very effective voltage monitoring circuit following the BUCK converter. This over-voltage protection is stable, not reactive to cheap wall warts and the (OVP) triggers if the BUCK power supply rises above - precisely - 5.3V. (Those BUCK converters have a notorious V-adj pot that, when it fails open, sends the BUCK to max output). YIKES ! That's why I designed the OVP circuit to protect my TMOs and other components. I didn't care for the standard "crowbar" circuit so this design uses a TRIAC which resets automatically with the over-voltage condition is removed - no blown fuses to replace. There is an LED on the board that illuminates anytime the OVP circuit has been activated. The circuit disables the BUCK in that condition. It works extremely well and takes the worry out of using those $1.25 Buck down-converters (which I like). Any wall wart from about 6V to 16V works just fine. The PCB supports interfacing for NEOPIXELS and includes a SOP23, 1-bit 3-to-5v logic converter since the TMOs and other logic is 3V. I found that I could operate the interface chips, including the Schmidt Trigger buffers at TMO levels. So, only the Neopixels actually use the 5.0 V level used for Vin that comes from the power supply after the OVP.

If you'd like to try this board, I have a few extras from my project. I now use these as my GO-TO foundation anytime I want to interface two TMOs via I2C. The boards cost me $25 and I could make arrangements for you but I before I do, I need to check with the Adafruit folks to see if this is allowed via the forum. If not, I guess Ebay is a way or PMsg. I'd just give it to you but the cost is just outside the circular threshold beyond friends/family discounts. (TIC). That's not my goal here anyway -- you can breadboard my schematic if it's something useful. It works flawlessly and has many options for re-purposing beyond just Neopixel projects. Check it out. Too bad you don't live in the neighborhood here -- you could just drop by.

Good luck with your own work there. I'm on to accelerometers and have been fighting with noisey output on the LIS3DH. It does work great for click detection and as a "wake-up" motion detector.

Regards,
Gov

PS: On the PCB images, in the power supply section, there is silkscreen labeling for a 7805, 5v linear regulator. Ordinarily, this is not installed but is an option when appropriate. For example, when the board is supplied with 5v-9v DC and low current requirement applications are implemented (no Neopixels). The cheaper 7805 option is there and if the power conversion keeps it sufficiently cool, then it's a good option. Generally, even if the OVP components are not used, the BUCK is a better choice for me. 99.99% of the time, I use the complete compliment of BUCK & OVP. I sleep more soundly that way, you know.
Attachments
Brian_FFT_V25_PCB.png
Brian_FFT_V25_PCB.png (558.65 KiB) Viewed 302 times
IMG_4161_400x533.png
IMG_4161_400x533.png (383.03 KiB) Viewed 302 times

User avatar
MizeSoundGuy
 
Posts: 25
Joined: Sun Apr 05, 2015 4:09 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by MizeSoundGuy »

Wow. I love new gadgets but I think I love them too much and I am positively elbow deep in the little boards with microprocessors on them. The TM0 is just the latest.
As far as the boards go, I'm tempted to say "take my money!" but I think I need to have a better understanding of what they do first. I keep reading about your use of FFTs and that sounds cool. I have more than a little bit of exposure to FFTs having specialized in 1- & 2-D signal processing for many years before making a sharp turn into power system protection (as in utility, industrial and commercial power systems, >=480V). If you'd like to take the discussion of your boards off of the public forum, let me know.

For my less cost sensitive application, I am looking at the ItsyBitsy M4 Express for $15. It does not have a crystal but it does have a 120MHz clock, perhaps that will mitigate the difference in clock between on and off USB. There's the Feather M0 Basic Proto, 48MHz and a crystal, but $20. And if that doesn't work, there's always the Feather M4 Express with 120MHz, a crystal and floating point for $23.

Thanks!

--Jeff

User avatar
Govner
 
Posts: 175
Joined: Wed Sep 14, 2016 4:42 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by Govner »

Hi Jeff,

Interesting reading about the options for boards. I considered some of them but could never get away from having to have full-time FFT processing. My reality is that 500 Mhz wouldn't be too fast if I had my wishes. The cool thing about using the dual M0s was that an uninterrupted (no pun intended), dedicated FFT TMO and a separate 'admin' TMO is just fast enough to be useable. Smarter people than me could probably code a state machine that might do what my board does and use a single 120 Mhz board but I sure don't have the 'brain power' for that.

Your suggestion to go offline for discussions into the details of my design is fine with me if you're wanting to know more about it. I'm not a salesman in this regard but I would be happy to answer questions to clarify the description I provided. To answer the question as to 'what it does' , I'd have to say that it does just about anything you want to code that uses two TMOs, 64Kbits EEPROM, Audio Amp w/AGC, 8-bit port expander, 3-to-5V 1-bit level shifter for driving data for Neopixels, with of course an onboard regulated 5V supply w/OVP) and two sets of pads for 1-wire devices (like IR, Hall, Temp, Humidity, etc devices) . I just happen to design the PC board because I needed to build about 15 separate units. Because everything is on the I2C bus (except the audio analog output), "what it does" is obviously a function of what one wants it to do with onboard hardware. It has headers for digital /inputs/outputs ( I connect 3 external LEDs and a rotary, digital encoder.) I do have the schematic available as well. As I write this, I'm thinking that GitHub may be where this discussion/content should be. A ReadMe file and all supporting docs would be something to put there. I'll look into how difficult that is to do and if it's within reason, I'll learn how to upload files for public use ASAP and announce the GitHub availability right here on this great forum. That way, I won't step on any toes here. I'll share anything/everything. A project of this magnitude took several hundreds of hours (almost 1000) and get my project done, it was several 'hunge' $$ just for the TMOs. (I still have about a half-dozen or so still laying around here.) Fortunately, I have lots of projects in mind and they'll get used, I'm sure. Some of your own descriptions have given me ideas. Thank you for that.

Thanks for comments. I'll follow any posted content about your projects.

Regards,

Gov

PS: Couldn't resist the GT Yellow Jacket image ( Class of '72). The PC board photo is not really focused and complete but you get the idea.
Attachments
GT_buzz.png
GT_buzz.png (53.71 KiB) Viewed 269 times
Project_After.jpg
Project_After.jpg (133.09 KiB) Viewed 269 times

User avatar
42volts
 
Posts: 106
Joined: Sat Jan 19, 2019 11:20 am

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by 42volts »

So I have a question for you about your boards... given that your project includes design/build of a custom board, why haven't you integrated the SAMD's directly onto your board rather than sticking on the trinket? If you were to include the SAMD's on your board, then you could easily (and very very cheaply) incorporate crystals for clock stability.

User avatar
Govner
 
Posts: 175
Joined: Wed Sep 14, 2016 4:42 pm

Re: Stabilizing the Trinket M0 CPU Clock Speed

Post by Govner »

Hi,

>> "... given that your project includes design/build of a custom board.." why haven't you just integrated the SAMD directly. "
----------------------
That is certainly a good question -- EXCEPT -- in this case, it's really not a finalized "custom board" yet. It's a prototype.


Also, I may not have mentioned earlier that the clock frequency variation caused by the USB clock bias was solved with a work-a-round. As a result, "crystalizing" the SAMD became a non-event. The flexibility of having dual socketed Trinkets has been very helpful. Keeping in mind that these PCBs are for my own experimentation -- to share, not market -- , folks are welcome to make their own changes, of course.

One cool aspect is that Adafruit's original ATTiny85 Trinkets have 100% pin compatibility with the SAMD21 Trinket M0. Havinb lots of Trinket ATTiny85 laying around from 'back when' , I find that that many projects when the 85s are substituted get the job done nicely, reviving the unused assets. Also, hot-swapping to pre-programmed versions is both fast and convenient. No code editing and uploading, etc. Easy-Peasy-Lemon-Squeezy. The flexibility is terrific.

Coincidentally, answering your question (thank you) gave me a great idea for a fun experiment. A couple years ago, I'd developed a Arduino UNO controlled DDS-based (0-100 Mhz) frequency generator with 10 Hz resolution and now I can't wait to play around with it in conjunction with some of these topics. So many fun things; so little time.

Thanks again,
Gov

Locked
Please be positive and constructive with your questions and comments.

Return to “Trinket ATTiny, Trinket M0”