Jump to content


  • Content Count

  • Joined

  • Last visited

Reputation Activity

  1. Like
    pokmo reacted to Clavier in Analog comparator   
    Huh? All MSP430 comparator modules are able to raise an interrupt for this.
  2. Like
    pokmo 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.
  3. Like
    pokmo reacted to energia in Reading data from 3.5mm audio jack   
    This could be possible but totally depends on the characteristics of the audio. Is this something like to modem technology or the audio data tapes that we used to load in our C64's cassette player? It all boils down to the frequency of the audio signal and what sample rate it would take to capture that data.
    Can you post some more info about the specifics of the audio data signal? 
    Out of curiosity, why audio data and not something like SPI/UART/parallel, etc.
  4. Like
    pokmo reacted to enl 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.
  5. Like
    pokmo reacted to abecedarian in Reading data from 3.5mm audio jack   
    That circuit is an emulation of a V.21 modem and its RX and TX would connect to a telephone line and UART on a PC or similar. 
    The MSP430 has no intrinsic ability to "hear" audio. What it does have are analog to digital converters. So what you'd need to do is connect the output from the PI to an ADC on the MSP, sample the ADC and apply some filtering such as a Fast Fourier Transform, so you can convert the audio signal to a digital one based on the frequencies of the audio. That is essentially what a modem does, on the demodulation side, which is what you're trying to accomplish since you said "unidirectional".
    You didn't mention what the MSP430 is going to do with the data, but if it's to offload data to a computer, that would need worked out separately.
  6. Like
    pokmo reacted to enl 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.
  7. Like
    pokmo reacted to enl 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.
  8. Like
    pokmo reacted to roadrunner84 in Reading data from 3.5mm audio jack   
    Easiest way is to use an opamp (there are msp430 with built in comparator/opamp) and use/abuse the opamp as a filter. Then "encode" serial commands (you have to go serial at some point!) by transmitting high bits as one frequency and low bits as another frequency (or no signal at all).
    Then you can use the output from the filter to acquire an analog voltage that is close to the desired levels.
    Essentially you're using discrete amplitude modulation (AM) with a modulation depth of 100%, this is the same as OOK (on-off keying).
    Note that such a system will have a low bandwidth, don't expect any rate in the order of kilobits.
    Also, you can see that this is roughly what the softmodem solution is doing; taking a signal, filtering it and shoving it down the msp's throat.
  9. Like
    pokmo reacted to Rickta59 in Porting Arduino code to MSP   
    Could you provide a link to the sketch you are talking about?
  10. Like
    pokmo reacted to yyrkoon in Porting Arduino code to MSP   
  11. Like
    pokmo reacted to Rei Vilo in Porting Arduino code to MSP   
    As long as a library relies on the Wiring / Arduino framework, a library designed for Arduino should work with Energia with minimal adaptation.
    The Wiring / Arduino framework acts as a hardware abstraction layer, especially for the UART, SPI and I
  12. Like
    pokmo reacted to Fmilburn in Porting Arduino code to MSP   
    Hi @@pokmo
    You will of course get faster and tighter code by rewriting the Arduino sketch for direct access to the underlying hardware regardless of the toolchain / IDE / compiler.
    However, if you are going to port Arduino code, as opposed to rewriting it, then it would be best to use Energia.  The MSP430G5529 is a good choice.  It has lots of resources, runs at 25 MHz, has USB, and the Energia implementation is mature. CCS can be used with Energia on the F5529.  With regards to porting, try compiling the code in the Energia IDE first and see what errors occur.  Often it will work with minimal changes, maybe limited to pins, but if there is a lot of hardware specific stuff in the Arduino code then it is sometimes better just to rewrite it.
    You specifically state the MSP430, but the MSP432 or Tiva could also be used.
  13. Like
    pokmo reacted to yyrkoon in Porting Arduino code to MSP   
    As far as jumping straight into CCS it depends on your priorities. If you're wanting to dive into writing code right away. Then perhaps CCS would be the best way to go. If you do have time to mess around with toolchain setup. You can use the toolchain that comes with Energia, etiher stand alone from the cmdline, or you can plug it into another IDE like code::blocks.
    Personally I do not like CCS, but that's my own hangup. But I've read that TI's compiler is the better at optimization. The gcc toolchain that does come with Energia is also very good for MSP430G2* processors, but I'm not sure if it's solid or not for the rest of the MSP430's or not.
    Another consideration would be to use one of TI's Cortex M4 ARM based launchpads. But you know what the msp430G2* may even be enough "horsepower" for your project.
    Also I suppose another factor to consider would be what exactly do you mean by "optimization" ? CCS' compiler I've read is a bit better at code optimization. But if you mean the fact that Energia seems to have to tendency to pull in everything but the kitchen sink when you compile . . . that can be fixed.
  14. Like
    pokmo reacted to veryalive in Porting Arduino code to MSP   
    Here's a BLDC project that I learned quite a bit from.....    see the cut / paste at the bottom of this message .....
    (author = @lgbeno)
    The project uses CCS, a '2553 at 16MHz, and the code is very modular, the documentation (including use of the async port to annotate the scope traces) is cool.
    Regarding your questions, though :
    My own view is that CCS is a great IDE, has a solid compiler and the memory / HW register / variables mods one can do while the test processor is halted can really save a lot of time during debugging.  
    CCS, along with Energia is a formidable tool for me for doing small projects and actually finishing them.
    Best of luck, 
    ======  search the forum on BLDC  ========
    Posted 10 July 2013 - 05:18 AM
    Cool project, I did something very similar as well!

    https://github.com/lgbeno/BLDC-Booster   ======
  15. Like
    pokmo reacted to NurseBob in Porting Arduino code to MSP   
    Whlie new to Energia, I've coded for the '430 with both IAR and CCS using the "traditional" main() non-OOP approach.  It's fairly straight-forward to write in C, but is a massive departure, conceptually, from using tools like the Arduino or Energia OO libraries, which strive to hide the lower-level implementations.  Both of these tools do a phenomenal job of presenting an high-level, seemingly simple way to control the underlying technology.  If there is a downside, it's that they are so effective at hiding the complexities, and perhaps, the true capabilities of the underlying devices.
    In particular, the '430, with a well-designed and implemented system, can achieve incredible battery life by spending 95 - 99% of its time sleeping, wiating for an interrupt to which it needs to respond. Often, those responses can be handled with comparatively few cpu clock ticks.  However, I don't see a gyro-BLDC system spending much, if any, time in LPM4, though the gyro inputs might meet the needs for a hardware interrupt (required to wake from LPM4).
    As to IDEs, I strongly prefer IAR over CCS. However, the 4K kickstart version from IAR is viable for only small projects (unless you want to dive into assembler, which didn't used to have a code-size limit).  The 16K limited CCS is much more functional, but personally, I hate the UI.  That said, I was able to afford a license for an full version of CCS, which was just not possible to do with IAR.  As a hobbyist I could not justify $thousands, even for a 40% discounted version...
    I'm using a blend of Energia/CCS (probably badly) to do some rapid prototyping/proof of concept work.  However, the final code will use a more traditional main() and while it may "loop" it will be a wake from LPM, do some work, go back to sleep loop, and be object-based if I'm smart enough to get my head wrapped around OOD/OOP again...
    As noted by others, you can do smaller projects, and effectively prototype with Energia/CCS.  At this point I may start with Energia, or import an existing sketch to get a handle on a sensor/430 implementation, but I spend 99% of my time in CCS.  HTH
  16. Like
    pokmo reacted to Rickta59 in Working with MPU6050 on MSP430   
    The other problem seems to be its use of dynamic memory. This is also a major limitation of the msp430 chips (assuming you are talking about the g2 series)
    It seems like the MSP430 implementation is crippled in some way compared to the other platforms. Here it disables some of the DMP functions:
  • Create New...