Skip to content

Latest commit

 

History

History
71 lines (58 loc) · 13.3 KB

Ref_Microchip.md

File metadata and controls

71 lines (58 loc) · 13.3 KB
Raw

Some technical notes from Microchip

Many of the technical briefs from Microchip are... maybe not the most helpful documents. Some of them aren't totally worthless however, and these are some that look like the might be more useful than average. Obviously, the official titles of these documents are different from the titles of the links in almost every case. These are but a few of many. Dont bother with the app note section, find the product page, and scroll down

CCL

Microchip has in the past demonstrated a complete lack of creativity in the use of the CCL. Thankfully, they've been waking up to the power of the CCL - though sadly there's no indicaion that the functionality might be expanded any time soon. I've got over a dozen features on my wish-list for the CCL ranging from specific inputs (no way to get TCA WO3-5? No TCB 3 or 4?), to a shift register that doesn't involve taking over an SPI, to a one or more CCL++ blocks on a chip that have a 16-bit truth table and a fourth input (that's about the largest that the truth table doesn't become awkwardly large for. )

TCD - there ain't so much here

Let's be fair, the TCD IS the most complicated peripheral on any 8-bit AVR that isn't called an xMega (over on those parts, a peripheral like the TCD would stand out for its simplicity and ease of use... xMega didn't seem to take off like they hoped. It's not entirely clear whether that had anything to do with the steep learning curve of all those whackjob peripherals, which achieved little gain in capability for a great deal of complexityh, or if it was some other reason. There is no shortage of other objections to the design principles at work: they couldn't be run at 5v, they cost a damned fortune, and they were basically trying to move up the compute-power/memory ladder but met fierce resistance from numerous well ARMed natives). Anyway, the TCD is the most complex peripheral measured by length of documentation, and as someone who has worked with every peripheral on these parts in some capacity, I would opine that that quantization understates it's complexity: between the synchronization-related effects and the rogues gallery of strange features, this one is a real doozy. If you can figure out how to use it though, it is an incredibly powerful timer. Their documentation group has attempted to make sense out of the TCD for people with this largely useless docucuemnt:

  • "Getting started with the TCD" (an accurate name - it won't get you anywhere near the finish line)
  • I'm not even sure what documentation I would want to see out of them. What bothers me isn't anything in specific, it's just that there seems to be no rhyme or reason to this timer... I think more than anything what the TCD needs is a rationalization of all it's features, how they come together and how they were envisioned to be used. Like those fault actions? What what the intended use case? Something that said "This is how you might make it control a DC-DC converter and here's how the fault inputs would be useful there, here's how you'd control a BLDC motor, and this type of feedback might be used with this sort of fault input scheme"

OPAMPs for the DB-series

These are probably the most useful of the documents, because the OPAMPs are so novel, and many of us (us being the denizens of Ardino-land) aren't as familiar with analog stuff.

ADC tips and tricks

There are tips and tricks for running the ADC. They appear to have been written under strict orders not to provide any quantitative recommendations. The things I was most hoping for (things like "The latest parts have lika a million tunables - which ones should I pick if I want to best measure an analog signal of ____ impedance that changes at ___ Hz (or ___ V/s)? " amd "When I accumulte values on 2-series or Ex, how many of the low bits are signal, and how many are noise, and what can I do to maximize that ratio?", "Is the theoretical 17-bit accuracy from 1024x oversampling and decimation anything other than marketing hype?", "Can you make any quantitative recommendation whatsoever on selection of any of these 'tunable' options?") are not covered - at all. . It's a bit like reading a non-classified summary of some highly classified document.

EA-series and 2-series only

These don't give very useful answers to the several "tunables" on the 2-series which may or may not be present on the EA-series (they seem to not be listed in the ATPACK headers, which is strange)

Other

When all else fails, read the documentation

When I refer to the actual documentation, I refer to three critical documents. Two of them are essential reading for anyone stepping an inch outside of the Arduino API, and is specific to the chip, and one far more general, esoteric, and enlightening (this is not the same as being useful for programming tasks)

  • Be sure to read the datasheet. Then, read the relevant chapters a few more times. They don't just write those things for fun, and frankly thee datasheets aren't about to win any awards for good technical writing. They're not bad (which in and of itself is unfortunately unusual), but they're not great, amd it takes a few passes to truly grok the concepts that guided these designs (The designers took instructions from the managers, designed the product, and then told the technical writing team how it worked (and if they're anything like the engineers I know, they did a lousy job of explaining it). Product briefs on the other hand (like the clothing of the same name) cover only the most important elements: The pinout, feature list, and I/O Multiplexing and Considerations chart - which is, far and away, the part you will most often refer to while working with the modern AVRs.

  • The headers are an incredible resource The [core documentation gives a general description] In fact, because of the great consistency between modern AVRs this has proven to leave very little to the imagination. In the case of the DD, by the time the datasheets were released, there were basically no surprises left - all the peripherals were known from the DB. The only new information in the datasheet was the fact that all the pins are fully async. In the case of the EA thus far, there are a few clear, straightforward changes in the event system, and a couple of new mappings for TCA1, and 1 new mapping for TCD0... and that's about it. We know the ADC pretty well from the 2-series. At least one of the annoying tunables that they won't tell us how to use correctly is gone, replaced with "sign chopping".

  • AVR Instruction Set Reference If working with assembly you should make a rigorous study of the insruction set reference. One of the great strengths of AVR is the simplicity of the instruction set. You should know all the mneumonics, what arguments they take and what constraints apply - and this does not take a terribly great deal of effort, as there are not that many instructions. This is the Bible of the AVR architecture. Much like any other tome of the sort, it is packed with insight and wisdom from the creators, and describe in detail considerations you must observe, and some parts are not readily applicable to the present day*, and reading it is a long slog through obtuse verbiage and grammar. Unlike other more famous scriptures, you won't suffer eternal damnation for not reading this - but if you're writing assembly without it you may not be able to tell the difference. Even those who merely write C should try to make time for a cursory study of this, because this is what the compiler is turning your C into, and you can sometimes make choices that lead to the compiler being able to make better code.

The datasheets giveth

I gave up trying to keep track of them all. The part-specific docs here now link to the Micochip product page.

And the errata taketh away

Notice that while datasheet information can be generalized across the whole family of parts The datasheets typically differ only in the header and footer (excepting the 1-series, which is effectively two part families, the 16k+ and the 2-8k parts). But because they use different dies, and dies are designed at discrete points in time, flash sizes released later have fewer bugs, because they've been spending the intervening months stomping out errata. On the 0 and 1 series tinyAVRs, there is a mindboggling amount of errata and a terrible shortage of die revisions. The 2-series tinyAVR by contrast has very little and the DD even less, though the EA's new RWW flash system is pretty janky.

See also Errata.md.