spellcheck

README.md

@@ -616,7 +616,7 @@ In general you should expect the following about library compatibility:
 * Libraries that work on other AVR-based arduino devices will work as long as:
   * They do not directly interact with hardware registers,
   * They do not make assumptions about what pins are associated with their peripheral (ex "Okay, now my library has included Wire.h, now I'm going to attachInterrupt() on SDA: attachInterrupt(A4,myInterrupt);) - that fails except on an '328, because it assumes that SDA is on the same pin as analog input 4 - for example);
-* Libraries that make use of only Arduino API calls without assumotions about the underlying hardware are virtually guaranteed to work.
+* Libraries that make use of only Arduino API calls without assumptions about the underlying hardware are virtually guaranteed to work.
 
 The amount of effort required to port a given library will vary widely depending on the library. Some are almost trivial, while others require deep knowledge. The fact that many libraries can be ported without much effort again underlines the need for reports from users about incompatible libraries so we can pick this lowhanging fruit,
 
@@ -772,7 +772,7 @@ There are a number of macros for determining what (if any) features the core sup
 * `ADC_NATIVE_RESOLUTION` (10 or 12)- This is the maximum resolution, in bits, of the ADC without using oversampling.
 * `ADC_NATIVE_RESOLUTION_LOW` (8 or 10) - The ADC has a resolution setting that chooses between ADC_NATIVE_RESOLUTION, and a lower resolution.
 * `ADC_DIFFERENTIAL` (0 or 2) - This is defined as 1 if the part has a basic differential ADC (no gain, and V<sub>analog_in</sub> constrained to between Gnd and V<sub>Ref</sub>), and 2 if it has a full-featured one. *It does not indicate whether said differential capability is exposed by the core* - see `CORE_HAS_ANALOG_DIFF`
-* `SUPPORT_LONG_TONES` (0 or 1, depending on flash size)  - On some modern AVR cores, an intermediate value in the tone duration calculation can overflow; this occurs becasue the tone duration is timed by counting the number of times the pin is flipped; the conversion between seconds and milliseconds results in a value being multiplied by 1000. This effect is worst at high frequencies, and can manifest at durations as short as 65 seconds worst case. Working around this is straightfoward, but comes at the cost of some flash. Cores may or may not choose to address it - either because their author is unaware of the issue, or feels that the flash cost is not justified (megaTinyCore only supports long tones on parts with more than 8k of flash).  If `SUPPORT_LONG_TONES` is defined as 1, as long as (duration * frequency)/500 < 4.294 billion, the duration will not be truncated. If it is defined as 0, the issue is not worked around, though the author or maintainer of the core was aware of the issue and chose not to fully correct it (ex, to save flash) but took an obvious step to reduce the impact; the duration will be truncated if (duration * frequency) exceeds 4.294 billion. If `SUPPORT_LONG_TONES` is not defined at all that suggests that the issue was not mitigated at all, and the issue may be present in its original form, in which case the duration will likely be truncated if (duration * frequency) exceeds 2.14 billion. In any event, if this issue is relevant to your application (that is, you are generating a high-pitched tone for over a minute at a time) your sketch may be annoying to others.
+* `SUPPORT_LONG_TONES` (0 or 1, depending on flash size)  - On some modern AVR cores, an intermediate value in the tone duration calculation can overflow; this occurs because the tone duration is timed by counting the number of times the pin is flipped; the conversion between seconds and milliseconds results in a value being multiplied by 1000. This effect is worst at high frequencies, and can manifest at durations as short as 65 seconds worst case. Working around this is straightforward, but comes at the cost of some flash. Cores may or may not choose to address it - either because their author is unaware of the issue, or feels that the flash cost is not justified (megaTinyCore only supports long tones on parts with more than 8k of flash).  If `SUPPORT_LONG_TONES` is defined as 1, as long as (duration * frequency)/500 < 4.294 billion, the duration will not be truncated. If it is defined as 0, the issue is not worked around, though the author or maintainer of the core was aware of the issue and chose not to fully correct it (ex, to save flash) but took an obvious step to reduce the impact; the duration will be truncated if (duration * frequency) exceeds 4.294 billion. If `SUPPORT_LONG_TONES` is not defined at all that suggests that the issue was not mitigated at all, and the issue may be present in its original form, in which case the duration will likely be truncated if (duration * frequency) exceeds 2.14 billion. In any event, if this issue is relevant to your application (that is, you are generating a high-pitched tone for over a minute at a time) your sketch may be annoying to others.
 * `CORE_HAS_ANALOG_ENH` (1)  - If defined as 1, analogReadEnh() (enhanced analogRead) is available. Otherwise, it is not.
 * `CORE_HAS_ANALOG_DIFF` (0 or 1)  - If defined as 1, analogReadDiff() (differential enhanced analogRead) is available. Otherwise, it is not. This is available on the 2-series parts only, as those are the only modern tinyAVR devices which feature a differential ADC.
 * `ADC_MAX_OVERSAMPLED_RESOLUTION` (13 or 17) - If either `CORE_HAS_ANALOG_ENH` or `CORE_HAS_ANALOG_DIFF` is 1, this is defined as the maximum resolution obtainable automatically via oversampling and decimation using those functions.