Jump to content

enl

Members
  • Content Count

    341
  • Joined

  • Last visited

  • Days Won

    22

Reputation Activity

  1. Like
    enl got a reaction from yyrkoon in Basic MSP430 GPIO Macros   
    I tend to use this style for many things, in particular single thread embedded applications like one tends to have on the smaller MSP430's, but it isn't always my preference.
     
    The code tends to be more readable if done reasonably well, with full optimization available since it is expanded by the preprocessor, but inline functions can be just as efficient and are often less likely to lead to debugging issues, making them generally preferable when available, but with the drawback that expansion is not mandatory, so timing is not guaranteed. If forced, you lose some space optimization features.
  2. Like
    enl got a reaction from chicken in Basic MSP430 GPIO Macros   
    I tend to use this style for many things, in particular single thread embedded applications like one tends to have on the smaller MSP430's, but it isn't always my preference.
     
    The code tends to be more readable if done reasonably well, with full optimization available since it is expanded by the preprocessor, but inline functions can be just as efficient and are often less likely to lead to debugging issues, making them generally preferable when available, but with the drawback that expansion is not mandatory, so timing is not guaranteed. If forced, you lose some space optimization features.
  3. Like
    enl reacted to chicken in Basic MSP430 GPIO Macros   
    In my project, I use a few basic macros for GPIO. The goal is, that I can easily redefine pin assignment in a central location without compromising performance or code size.
     
    The macros (gpiomacros.h):
    // MSP430 gpio macros #define GPIO_SEL(port) P ## port ## SEL #define GPIO_DIR(port) P ## port ## DIR #define GPIO_OUT(port) P ## port ## OUT #define GPIO_IN(port) P ## port ## IN #define GPIO_IS_INPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_OUTPUT(port,pin) { GPIO_SEL(port) &= ~(pin); GPIO_DIR(port) |= (pin); } #define GPIO_IS_PERIPHERAL_IN(port,pin) { GPIO_SEL(port) |= (pin); GPIO_DIR(port) &= ~(pin); } #define GPIO_IS_PERIPHERAL_OUT(port,pin) { GPIO_SEL(port) |= (pin); GPIO_DIR(port) |= (pin); } #define GPIO_SET(port,pin) { GPIO_OUT(port) |= (pin); } #define GPIO_CLEAR(port,pin) { GPIO_OUT(port) &= ~(pin); } #define GPIO_READ(port,pin)  ( GPIO_IN(port) & (pin) ) In a central configuration file (e.g. hardware.h) I assign pins like this:
    // Pin assignment #define LED1_PIN BIT1 #define LED1_PORT 6 #define LED2_PIN BIT0 #define LED2_PORT 1 And then in the code I interact with GPIO like this:
    // Setup LEDs GPIO_IS_OUTPUT(LED1_PORT, LED1_PIN); GPIO_IS_OUTPUT(LED2_PORT, LED2_PIN); // Turn off LEDs GPIO_CLEAR(LED1_PORT, LED1_PIN); GPIO_CLEAR(LED2_PORT, LED2_PIN); The macros are resolved in two steps:
    1. Higher level "functions" define the commands. E.g. GPIO_SET(), GPIO_IS_OUTPUT(), ..
    2. Lower level macros used within those functions translate port, pin to a register. E.g. GPIO_IN(), GPIO_SEL(), ..
     
    The end result is code like you would write when directly working with the GPIO registers. E.g. P2OUT &= ~BIT0; Note that this translation is done by the C pre-processor before the code is compiled.
     
    This all works fine and dandy, with the exception of port J. Port J doesn't have a SEL register, which breaks the 1st half of the GPIO_IS_OUTPUT and GPIO_IS_INPUT macros. I currently work around this by adding special GPIO_IS_OUTPUT/INPUT_J macros, but then the main code needs to include some logic to invoke the proper macro.
    #if (LED2_PORT == J) GPIO_IS_OUTPUT_J(LED2_PORT, LED2_PIN); #else GPIO_IS_OUTPUT(LED2_PORT, LED2_PIN); #endif Any ideas, how I could include a condition inside macros, that checks whether the port is J, and if so excludes the GPIO_SEL command?
     
    And yes, I could probably use C++ templates with identical results and an easy workaround for port J, but I'd like to avoid migrating my plain old C project.
     
    Edit: Added a few missing parentheses, thanks to Rickta59 for spotting that
  4. Like
    enl reacted to yyrkoon in Logic Analyzers   
    @@Fred @@zeke @@enl
     
    I went ahead and ordered the one from the video off Amazon. As for cost and blowing my budget . . . the money for this is coming out of my own pocket.  For something I may never even use again. You guys may have an actual use for the Saleae products, that's fine, I get that. But, I don't So spending ~$500 is really not acceptable.
     
    It's kind of like the ole serial debug cable "debate" for the beaglebone black. You can buy from a well known "trusted" name brand FTDI for $20 usd. *Or* You can buy a Prolific PL2303HX Cable that performs the exact same functionality for less than 1/10th the cost. Granted, I'm all for dealing with trusted name brands. But not just for the sake of spending more money. There has to be a compelling reason.
     
    Anyway, it won't be here for around a month . . . I will try to remember to relate to everyone what I personally feel about this once I get some serious time using it.
  5. Like
    enl got a reaction from yyrkoon in Logic Analyzers   
    I have and use a Saleae logic-8, and have a logic-8pro at work. The lowest end is logic-4 at about $110. For what you are looking at (sub-100KHz) the logic-4 would do well as the sample rate is 12MHz. The logic-8 is 100MHz sample, which is reasonable to about 10MHz systems. There software has several protocol analyzers (I2C, SPI, RS232/standard serial, USB, and about 20 others) and I think it is possible to write your own. I have nothing but good things to say about the unit, and would only give the standard cautions that the units are most useful on a laptop running on battery power to avoid ground issues. A number of the far east import units are near clones, but I can not speak for the quality of them. (one I was looking at had a link to Saleae for the software. I thought that was a bit.... scummy)
     
    The reason I went for this is that the reviews were good, the sample rate was sufficient for most of what I need, low V to 5V logic compatible, protocol decoders for things I need are not extra cost, and the software is a good match for what I have used in standalone units for many common features. You can pull the software and play with it without the unit. If there is no unit on the computer, the software fakes it for you for demo.
     
    Learning curve is good enough that I have had students using it to debug I2C and SPI in less than 15 minutes. Not experienced students, but first time with anything more involved than blink an LED level students.
     
    Edit: watched the video you linked. Looks like a Saleae clone. I don't like the plastic case (shielding issues), but at sub-mhz it is likely not a problem. I haven't used the software he uses. I have a windows machine for such things (due to Autodesk, oscilloscope remote UI, and the microscope cameras), so it isn't a hassle.
  6. Like
    enl got a reaction from yyrkoon in Logic Analyzers   
    @yyrkoon
    They are not cheap, but keep in mind that they developed the software, and, unlike some of the clones (by the magic of google) actually perform as advertised
     
    I may be biased, having spent several thousand dollars for significantly less performance during the present millennium for a dedicated device, but I see it as a real deal.
     
    With the USB units, buffering is a concern, but none of them (as far as I can tell) are over endowed with memory. They need a USB channel that can suck up data and a host that can do something with it. I have had no issues at 500MHz with a saleae pro on a netbook, but I am not streaming netflix when I am using it. You are looking at low speed UART work, and I would bet a ZX81, or bottom end saleae clone, would be capable of dealing with it.
     
    If you are in a time pinch, at those speeds, an MSP430G can split the bits and ram them up the USB line from a launchpad. A 13$ msp432 can do a lot better than that.
     
    Given what you are looking at, you are likely to need to write your own protocol analyzer, or see if one is available for a standard device. The Saleae has the advantage of a reasonable dev environment for rolling your own protocol analyzer.
     
    The only things showing up in a quick google search that do DALI are pretty far up in price and are locked up against building your own.
     
    If it were me, and a deadline was up, I'd call saleae and grab the logic-4 or logic-8 on fast shipping.
     
    If $100 is a killer, then you already blew too much time on the project.
  7. Like
    enl reacted to bluehash in NewHaven displays 15% off on OLED boards   
    http://archive.pbsc2.com/csb/Public/show/d84wq--9ybn8-4k509sy2
     
    For the entire month of November, all OLED display products are on sale. Use the below coupon code during online checkout and recieve 15% off your OLED purchases. Discount is available for online orders only.   COUPON CODE: Nov2016OLEDs
     
    http://www.newhavendisplay.com/oled-c-119.html
  8. Like
    enl got a reaction from artium in Any Unique MSP432 Project Ideas?   
    What orientation do you have for a project? The capabilities of the processors differ so much that it is difficult to answer your question without knowing where you are going. No sarcasm is intended in the following suggestions:
     
    Robotics? You can do multiaxis control in real time.
     
    Audio? You can do signal processing within the limits of the ADC resolution.
     
    Video? I would guess that you could produce VGA output to run 640X480 VGA at 8 color (one bit per color), or possibly better with some careful programming, and have no major issue producing a videogame. Certainly 320X240 should be straightforward. Using R-2R chains, you could easily produce interesting video output, though anything requiring a frame buffer would likely be out due to RAM limitations. It would probably not be too hard to produce NTSC in the same vein as an Apple II.
     
    The gains you get with the 432 include speed, memory, and processing per cycle. With a 430, serious audio isn't really practical. Real video is superstar territory. With the 432, both are straightforward, though not necessarily trivial.
     
    Specific ideas in audio: A guitar multi effect, maybe distortion, Wah (a pot on an ADC for bandsweep), flange, and reverb. All are moderately straightforward, but explore different algorithms.
     
    Video: One of the coolest thins I saw at a trade show in the late 70's was a video dazzler. Just cool patterns, but really, really cool. An audio input to control an arithmetically produced pattern as VGA output?
     
    Robotics: An 8 channel, I2C command servo controller?
     
    Do you ride? One of the things I did years ago with a PIC was an electronic ignition for a 1975 Honda CB400F (4 cylinder). Maxed out at about 12000RPM. The unit was tight to about 8000, but had a bit of jitter above that. Drove an output for the tach as well. The 432 can cover other things at the same time, and not lose it's place for the ignition timing.
     
    Got a cat? Using the ADC and DSP capability, an ultimate class cat toy? Detect appropriate stimulus (Meow, scratching, othe r) using a microphone, and do something interesting, like turn on a laser pointer mounted on servo's to entertain the cat, and when it gets to a certain point, release a treat?
     
    Ok... my mind runneth over. Several of these are things I don't have the time to do. There are many, many more. All of these take more than the 430 can reasonably do (except ignition timing), but none fully explore the capability of the 432.
  9. Like
    enl got a reaction from tripwire in Any Unique MSP432 Project Ideas?   
    What orientation do you have for a project? The capabilities of the processors differ so much that it is difficult to answer your question without knowing where you are going. No sarcasm is intended in the following suggestions:
     
    Robotics? You can do multiaxis control in real time.
     
    Audio? You can do signal processing within the limits of the ADC resolution.
     
    Video? I would guess that you could produce VGA output to run 640X480 VGA at 8 color (one bit per color), or possibly better with some careful programming, and have no major issue producing a videogame. Certainly 320X240 should be straightforward. Using R-2R chains, you could easily produce interesting video output, though anything requiring a frame buffer would likely be out due to RAM limitations. It would probably not be too hard to produce NTSC in the same vein as an Apple II.
     
    The gains you get with the 432 include speed, memory, and processing per cycle. With a 430, serious audio isn't really practical. Real video is superstar territory. With the 432, both are straightforward, though not necessarily trivial.
     
    Specific ideas in audio: A guitar multi effect, maybe distortion, Wah (a pot on an ADC for bandsweep), flange, and reverb. All are moderately straightforward, but explore different algorithms.
     
    Video: One of the coolest thins I saw at a trade show in the late 70's was a video dazzler. Just cool patterns, but really, really cool. An audio input to control an arithmetically produced pattern as VGA output?
     
    Robotics: An 8 channel, I2C command servo controller?
     
    Do you ride? One of the things I did years ago with a PIC was an electronic ignition for a 1975 Honda CB400F (4 cylinder). Maxed out at about 12000RPM. The unit was tight to about 8000, but had a bit of jitter above that. Drove an output for the tach as well. The 432 can cover other things at the same time, and not lose it's place for the ignition timing.
     
    Got a cat? Using the ADC and DSP capability, an ultimate class cat toy? Detect appropriate stimulus (Meow, scratching, othe r) using a microphone, and do something interesting, like turn on a laser pointer mounted on servo's to entertain the cat, and when it gets to a certain point, release a treat?
     
    Ok... my mind runneth over. Several of these are things I don't have the time to do. There are many, many more. All of these take more than the 430 can reasonably do (except ignition timing), but none fully explore the capability of the 432.
  10. Like
    enl got a reaction from Fmilburn in Any Unique MSP432 Project Ideas?   
    What orientation do you have for a project? The capabilities of the processors differ so much that it is difficult to answer your question without knowing where you are going. No sarcasm is intended in the following suggestions:
     
    Robotics? You can do multiaxis control in real time.
     
    Audio? You can do signal processing within the limits of the ADC resolution.
     
    Video? I would guess that you could produce VGA output to run 640X480 VGA at 8 color (one bit per color), or possibly better with some careful programming, and have no major issue producing a videogame. Certainly 320X240 should be straightforward. Using R-2R chains, you could easily produce interesting video output, though anything requiring a frame buffer would likely be out due to RAM limitations. It would probably not be too hard to produce NTSC in the same vein as an Apple II.
     
    The gains you get with the 432 include speed, memory, and processing per cycle. With a 430, serious audio isn't really practical. Real video is superstar territory. With the 432, both are straightforward, though not necessarily trivial.
     
    Specific ideas in audio: A guitar multi effect, maybe distortion, Wah (a pot on an ADC for bandsweep), flange, and reverb. All are moderately straightforward, but explore different algorithms.
     
    Video: One of the coolest thins I saw at a trade show in the late 70's was a video dazzler. Just cool patterns, but really, really cool. An audio input to control an arithmetically produced pattern as VGA output?
     
    Robotics: An 8 channel, I2C command servo controller?
     
    Do you ride? One of the things I did years ago with a PIC was an electronic ignition for a 1975 Honda CB400F (4 cylinder). Maxed out at about 12000RPM. The unit was tight to about 8000, but had a bit of jitter above that. Drove an output for the tach as well. The 432 can cover other things at the same time, and not lose it's place for the ignition timing.
     
    Got a cat? Using the ADC and DSP capability, an ultimate class cat toy? Detect appropriate stimulus (Meow, scratching, othe r) using a microphone, and do something interesting, like turn on a laser pointer mounted on servo's to entertain the cat, and when it gets to a certain point, release a treat?
     
    Ok... my mind runneth over. Several of these are things I don't have the time to do. There are many, many more. All of these take more than the 430 can reasonably do (except ignition timing), but none fully explore the capability of the 432.
  11. Like
    enl got a reaction from spirilis in Any Unique MSP432 Project Ideas?   
    What orientation do you have for a project? The capabilities of the processors differ so much that it is difficult to answer your question without knowing where you are going. No sarcasm is intended in the following suggestions:
     
    Robotics? You can do multiaxis control in real time.
     
    Audio? You can do signal processing within the limits of the ADC resolution.
     
    Video? I would guess that you could produce VGA output to run 640X480 VGA at 8 color (one bit per color), or possibly better with some careful programming, and have no major issue producing a videogame. Certainly 320X240 should be straightforward. Using R-2R chains, you could easily produce interesting video output, though anything requiring a frame buffer would likely be out due to RAM limitations. It would probably not be too hard to produce NTSC in the same vein as an Apple II.
     
    The gains you get with the 432 include speed, memory, and processing per cycle. With a 430, serious audio isn't really practical. Real video is superstar territory. With the 432, both are straightforward, though not necessarily trivial.
     
    Specific ideas in audio: A guitar multi effect, maybe distortion, Wah (a pot on an ADC for bandsweep), flange, and reverb. All are moderately straightforward, but explore different algorithms.
     
    Video: One of the coolest thins I saw at a trade show in the late 70's was a video dazzler. Just cool patterns, but really, really cool. An audio input to control an arithmetically produced pattern as VGA output?
     
    Robotics: An 8 channel, I2C command servo controller?
     
    Do you ride? One of the things I did years ago with a PIC was an electronic ignition for a 1975 Honda CB400F (4 cylinder). Maxed out at about 12000RPM. The unit was tight to about 8000, but had a bit of jitter above that. Drove an output for the tach as well. The 432 can cover other things at the same time, and not lose it's place for the ignition timing.
     
    Got a cat? Using the ADC and DSP capability, an ultimate class cat toy? Detect appropriate stimulus (Meow, scratching, othe r) using a microphone, and do something interesting, like turn on a laser pointer mounted on servo's to entertain the cat, and when it gets to a certain point, release a treat?
     
    Ok... my mind runneth over. Several of these are things I don't have the time to do. There are many, many more. All of these take more than the 430 can reasonably do (except ignition timing), but none fully explore the capability of the 432.
  12. Like
    enl reacted to vinicius.jlantunes in TI has free shipping through Oct-23   
    TI store is having another free shipping promotion through October 23 - https://store.ti.com.
     
    No coupon required.
  13. Like
    enl got a reaction from energia in MPS430F5529L reading multiple potentiometer   
    Starting point is you have an off by one eror on the loop counter: the test should be "<5", not "<6" as you are trying to do it.
     
    But, I think the main issue is that A0, A1, etc are aliases for pin identities, not channel values. You might try:
    const int analogpins[]={A0, A1, A2, A3, A4}; . . . . for (int i=0; i<5; i++) { sensorValue=analogRead(analogpins[i]); . . .
  14. Like
    enl got a reaction from morelius21 in MPS430F5529L reading multiple potentiometer   
    Starting point is you have an off by one eror on the loop counter: the test should be "<5", not "<6" as you are trying to do it.
     
    But, I think the main issue is that A0, A1, etc are aliases for pin identities, not channel values. You might try:
    const int analogpins[]={A0, A1, A2, A3, A4}; . . . . for (int i=0; i<5; i++) { sensorValue=analogRead(analogpins[i]); . . .
  15. Like
    enl got a reaction from dubnet in MPS430F5529L reading multiple potentiometer   
    Starting point is you have an off by one eror on the loop counter: the test should be "<5", not "<6" as you are trying to do it.
     
    But, I think the main issue is that A0, A1, etc are aliases for pin identities, not channel values. You might try:
    const int analogpins[]={A0, A1, A2, A3, A4}; . . . . for (int i=0; i<5; i++) { sensorValue=analogRead(analogpins[i]); . . .
  16. Like
    enl reacted to roadrunner84 in Reading data from 3.5mm audio jack   
    I was talking about OOK (on-off keying), while your latest schematic is talking about FSK (frequency shift keying).
     
    The difference is that FSK will send one frequency for high bits and another for low bits, while OOK will send one frequency for high bits and no frequency (DC, 0Hz) for low bits (or the other way around).
     
    So FSK has the added value of distinguishing high/low bits from an idle line. In the case of UART serial, you don't need this detection per se, because a high bit and an idle line are not distinguishable anyway.
     
    Then again, if you have the software to do FSK, just use it. If you make things from scratch, OOK might prove simpler to implement.
  17. Like
    enl got a reaction from abecedarian in Reading data from 3.5mm audio jack   
    That is what I was describing. The upper section is your minimum (FSKIN side). This is, again, presuming that the MSP430 will do timing of state changes to get frequency. This is presented essentially as an analog connection, but, with a Schmidt trigger input pin, you get zero crossing detection.
  18. Like
    enl got a reaction from pokmo in Reading data from 3.5mm audio jack   
    That is what I was describing. The upper section is your minimum (FSKIN side). This is, again, presuming that the MSP430 will do timing of state changes to get frequency. This is presented essentially as an analog connection, but, with a Schmidt trigger input pin, you get zero crossing detection.
  19. Like
    enl got a reaction from pokmo in Reading data from 3.5mm audio jack   
    You haven't make clear what you mean by audio commands. Do you mean something like tones as used in touch tone telephones? Or are you just interested in getting useable information from the pi to the MSP430 via the audio output in any format at all? or are you just interested in getting data from one to the other and selected the audio output by default?
     
    If the first or second, single tone detection isn't that hard. I would use capacitive isolation and protection diodes to limit the signal. Bias with a voltage divider to the middle of the power supply range, and then, using a digital input and timer, time the period. Different frequencies to differentiate commands/states.
     
    If you aren't tied to the audio line, using straight digital lines would be preferable. You could use a standard serial, or use SPI, or I2C, or... Straight serial is likely easiest, as that is the least setup from the PI end, and easy to handle from the MSP430 end, since there are a minimum of protocol issues.
     
    As you move to an old laptop, it will almost certainly have a serial port available (though it will need level conversion for interface with the MSP430). Audio may be unreliable, especially on older hardware, due to timing issues, etc. Many older devices (post soundblaster) didn't have any audio hardware to speak of. All software driven, like the modems. This led to some, um, interesting, issues during sound production, including poor timing, unpredictable skips from the buffer, and dropped intervals.  Serial was was hardware all the way, other than a few cases with 8-bit systems, since so little hardware is involved. By the mid-1980's (80286 era), it was generally included as an integrated part of the system chipset.
  20. Like
    enl got a reaction from pokmo in Reading data from 3.5mm audio jack   
    Probably not, but the key thing are that a) the signal should center around Vcc/2 (1.5V in a 3V system), teh level should not go outside power supply bounds, and c) the swing should be more that 2/3 Vcc p-p. Additionally, fast transitions are nice, but may not be achievable with audio output device. Using a Schmidt trigger input (available for the timer inputs) makes this less critical.
     
    The need for an op-amp would be due to insufficient level from the audio output. A line level output will be about 2.2Vp-p into 50Kohm, but headphone outputs may or may not meet this, and a line level output may drive much higher voltage open circuit. My design would be 5K in series with a 100nF cap (or larger), feeding the center of a voltage divider made with a pair of 100K resistors for biasing. If the input is Schmidt trigger, no issues with biasing to mid range. (For an input htat is NOT Schmidt trigger, do not do this, as the input may enter a state that leads to internal high current and damage.)
     
    If the output level into 50K is much less than this (I would be surprised), then a gain stage (op-amp) would be needed.
     
    This is not the greatest scheme in the world, but is pretty much what the most reliable cassette tape storage schemes in the late 1970s used. Again, I would tend to stay away from the audio hardware, but if you gotta, you gotta.
  21. Like
    enl got a reaction from energia in Reading data from 3.5mm audio jack   
    That is what I was describing. The upper section is your minimum (FSKIN side). This is, again, presuming that the MSP430 will do timing of state changes to get frequency. This is presented essentially as an analog connection, but, with a Schmidt trigger input pin, you get zero crossing detection.
  22. Like
    enl got a reaction from yyrkoon in Personal CNC PCB routers   
    pcb-gcode for use with Eagle would by my first suggestion.
  23. Like
    enl got a reaction from roadrunner84 in What's more precise: UART via crystal or DCO?   
    The guideline for picking a clock source and the required accuracy and stability is pretty straightforward, but in general, using the DCO is what you want. If you have the crystal in system, the DCO frequency can be compared to it and the bit rate divisor can be adjusted for best approximation.
     
    The error rate given describes the accumulated timing error, NOT the unreliability of the line, and can be used to determine whether there is likely to be data errors in transmition due to timing issues.
     
    To add a little background, the bits are sent and received in nominally identical time slices. The first edge of the start bit is used to synchronize the process, and, from then on, the receiver examines the line at the middle of each bits allotted time slice. For 8 bit data, with a start and a stop, the total time used is 9.5 bit times, and if the timing slips more than 0.5 bit times in that, then the receiver may lose synchronization on the later bits and the stop bit. This will trigger an error state if the receiver expects the bits faster than the sender provides them, and the bit the receiver sees as the stop isn't the appropriate stop state, and confusion will result from a number of possible ways for the synchronization to fail leading to bits being read as the wrong position in the data.
     
    THis 0.5/9.5 ratio means that the maximum difference in bit rate , for reliable operation, is 5.5%.  THis isn't bad, but does require a decent clock  at both ends. If both clocks are off by 3% in different directions, then there will probably be loss of synchronization. This is the total difference, and, if one clock is very close, the other tan take substantially all of the error (this is not an unusual case, but is not always the case)
     
    The clocks for the MSP430 that make sense here are, as you said, the DCO and a 32KHz crystal. The Crystal is accurate to about 0.01% worst case. The DCO is accurate to maybe 3% typical. On the other hand, as you noted, due to the need to produce the serial clock by dividing the control clock, at bit rates that are greater than about 5% of the clock rate, there will be bit rates that can not be generated to meet the requirement. For historical reasons, the standard bit rates don't play well with power-of-two frequencies like 32768Hz.
     
    The situation is improved (and this is where the more favourable looking that expected error bound for the crystal comes from) by dithering the clock when you can't get an exact match: The basic rate is higher than needed, and some bits are stretched by a clock to minimize the accumulated error. This works well, but, if done at both ends of the line, can fail when the bitrate is about 1/5 of the clock rate (6Kbs with the 32KHz crystal). This is a rough number, not exact, since it depends on the details of how the bit time adjustment is done. If one end is dead stable, and an extra stop bit is thrown in, it works quite well up to  maybe 1/3 of the clock rate (9600bps with a 32KHz crystal).
     
    All of that said, I usually just use the factory calibrated DCO frequency and have no problem. I don't even bother with checking the exact frequency.
  24. Like
    enl got a reaction from bluehash in What's more precise: UART via crystal or DCO?   
    The guideline for picking a clock source and the required accuracy and stability is pretty straightforward, but in general, using the DCO is what you want. If you have the crystal in system, the DCO frequency can be compared to it and the bit rate divisor can be adjusted for best approximation.
     
    The error rate given describes the accumulated timing error, NOT the unreliability of the line, and can be used to determine whether there is likely to be data errors in transmition due to timing issues.
     
    To add a little background, the bits are sent and received in nominally identical time slices. The first edge of the start bit is used to synchronize the process, and, from then on, the receiver examines the line at the middle of each bits allotted time slice. For 8 bit data, with a start and a stop, the total time used is 9.5 bit times, and if the timing slips more than 0.5 bit times in that, then the receiver may lose synchronization on the later bits and the stop bit. This will trigger an error state if the receiver expects the bits faster than the sender provides them, and the bit the receiver sees as the stop isn't the appropriate stop state, and confusion will result from a number of possible ways for the synchronization to fail leading to bits being read as the wrong position in the data.
     
    THis 0.5/9.5 ratio means that the maximum difference in bit rate , for reliable operation, is 5.5%.  THis isn't bad, but does require a decent clock  at both ends. If both clocks are off by 3% in different directions, then there will probably be loss of synchronization. This is the total difference, and, if one clock is very close, the other tan take substantially all of the error (this is not an unusual case, but is not always the case)
     
    The clocks for the MSP430 that make sense here are, as you said, the DCO and a 32KHz crystal. The Crystal is accurate to about 0.01% worst case. The DCO is accurate to maybe 3% typical. On the other hand, as you noted, due to the need to produce the serial clock by dividing the control clock, at bit rates that are greater than about 5% of the clock rate, there will be bit rates that can not be generated to meet the requirement. For historical reasons, the standard bit rates don't play well with power-of-two frequencies like 32768Hz.
     
    The situation is improved (and this is where the more favourable looking that expected error bound for the crystal comes from) by dithering the clock when you can't get an exact match: The basic rate is higher than needed, and some bits are stretched by a clock to minimize the accumulated error. This works well, but, if done at both ends of the line, can fail when the bitrate is about 1/5 of the clock rate (6Kbs with the 32KHz crystal). This is a rough number, not exact, since it depends on the details of how the bit time adjustment is done. If one end is dead stable, and an extra stop bit is thrown in, it works quite well up to  maybe 1/3 of the clock rate (9600bps with a 32KHz crystal).
     
    All of that said, I usually just use the factory calibrated DCO frequency and have no problem. I don't even bother with checking the exact frequency.
  25. Like
    enl got a reaction from Apr30 in What's more precise: UART via crystal or DCO?   
    The guideline for picking a clock source and the required accuracy and stability is pretty straightforward, but in general, using the DCO is what you want. If you have the crystal in system, the DCO frequency can be compared to it and the bit rate divisor can be adjusted for best approximation.
     
    The error rate given describes the accumulated timing error, NOT the unreliability of the line, and can be used to determine whether there is likely to be data errors in transmition due to timing issues.
     
    To add a little background, the bits are sent and received in nominally identical time slices. The first edge of the start bit is used to synchronize the process, and, from then on, the receiver examines the line at the middle of each bits allotted time slice. For 8 bit data, with a start and a stop, the total time used is 9.5 bit times, and if the timing slips more than 0.5 bit times in that, then the receiver may lose synchronization on the later bits and the stop bit. This will trigger an error state if the receiver expects the bits faster than the sender provides them, and the bit the receiver sees as the stop isn't the appropriate stop state, and confusion will result from a number of possible ways for the synchronization to fail leading to bits being read as the wrong position in the data.
     
    THis 0.5/9.5 ratio means that the maximum difference in bit rate , for reliable operation, is 5.5%.  THis isn't bad, but does require a decent clock  at both ends. If both clocks are off by 3% in different directions, then there will probably be loss of synchronization. This is the total difference, and, if one clock is very close, the other tan take substantially all of the error (this is not an unusual case, but is not always the case)
     
    The clocks for the MSP430 that make sense here are, as you said, the DCO and a 32KHz crystal. The Crystal is accurate to about 0.01% worst case. The DCO is accurate to maybe 3% typical. On the other hand, as you noted, due to the need to produce the serial clock by dividing the control clock, at bit rates that are greater than about 5% of the clock rate, there will be bit rates that can not be generated to meet the requirement. For historical reasons, the standard bit rates don't play well with power-of-two frequencies like 32768Hz.
     
    The situation is improved (and this is where the more favourable looking that expected error bound for the crystal comes from) by dithering the clock when you can't get an exact match: The basic rate is higher than needed, and some bits are stretched by a clock to minimize the accumulated error. This works well, but, if done at both ends of the line, can fail when the bitrate is about 1/5 of the clock rate (6Kbs with the 32KHz crystal). This is a rough number, not exact, since it depends on the details of how the bit time adjustment is done. If one end is dead stable, and an extra stop bit is thrown in, it works quite well up to  maybe 1/3 of the clock rate (9600bps with a 32KHz crystal).
     
    All of that said, I usually just use the factory calibrated DCO frequency and have no problem. I don't even bother with checking the exact frequency.
×
×
  • Create New...