Jump to content
43oh

jpnorair

Members
  • Content Count

    718
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by jpnorair

  1. Why are you passing longs in a system where the hardware has 16 bit registers? That is, CCR1 is 16 bits.
  2. If the 74-series part you want is not available in an LV series (3.3V), it's probably not easy to procure, anyway. Case in point, the 74c922 itself: https://forum.sparkf...hp?f=32&t=31170 Apparently this part is nearly $10. Just get a bigger MSP: a few more pins will cost you relatively little, and there will be one less chip. Less is more.
  3. What you're buying for $500 is the compiler. You might want to check if Free, code-limited CCS for Stellaris has an acceptable code limit. For MSP430, I remember that it was 16KB, which is more KB than MSP430 launchpads even have.
  4. I'm finishing the latest version of my USB CDC subsystem. It is written in C and now compiles quite small: about 1.4KB -- I have made hundreds of architectural improvements and optimizations over the basic TI USB library, mostly for the purpose of reducing code size. I will benchmark it on 256 byte transfer size soon. My system is not intended for streaming transfers, so in normal usage there is protocol parsing latency. I will write a special benchmark app, though, which does no protocol parsing and uses none of the task-based controls. I am pretty busy with some other things, so I'll pr
  5. I think CDC uses bulk transfers, also. Are you using LPMx and an interrupt? TI uses a busywait loop in their demos, so they are not having any interrupt latency. That would make the difference. Of course, it also makes their demo worthless as a real-world piece of software.
  6. What MCLK speed are you using? I see your results have 491KB/s, and their's have 511KB/s.
  7. OK: That's easier. I recall TI makes a simple MSP430F1xxx + PaLFI chip as well as the more sophisticated RF430 (CC430F514x + PaLFI). It is small (limited resources), but it is probably sufficient for your needs. Here they are: http://www.ti.com/product/tms37f128 http://www.ti.com/product/tms37f158
  8. OK, I understand. I have tested on OS X & Linux, which use the same basic CDC driver I think -- it works fine. I should also mention that I needed to fix many issues in the TI USB library interrupt service routine. I also had to fix the initialization routine: the TI USB library examples do not disconnect. If you are building your CDC stack open source, I can try to link in into my initialization and ISR code. If you are not, my work is on the net: https://github.com/jpnorair/OpenTag/tre ... m/msp430f5 If you are building your CDC stack to be proprietary, please still contact m
  9. LF RFID (like PaLFI) is ideal for this. The fall-off is 1/r^2 (in some designs 1/r^3), so you can keep the range limited to a precise "bubble." It is even better in cars with steel bodies, because the LF field will be conduced by the ferromagnetic steel, and you can very easily tune the range to work only within about 1-2m of the car. Most vehicle immobilizers and keyless entry systems (there are others, not just PaLFI, and they all use LF RFID), include some sort of event. Otherwise, the energy cost of strobing the LF reader can be a problem. For keyless entry, the event is touching t
  10. Hey: You might be interested in the RF430F5978. It combines the TI TMS37157 PaLFI chip with a CC430 (4/32) in a single package. There is a user's guide on ti.com, but the marketing seems to be so far nonexistent. http://www.ti.com/lit/ug/slau378/slau378.pdf You can use it together with an RI-ACC-ADR2 kit from TI, for the PaLFI part. For the UHF part, this chip is supported by my project OpenTag (http://www.github.com/jpnorair/opentag). I have been able to use the LF field to power & charge the device, enough so that it can be battery-less. Anyway, TI already uses parts from th
  11. I don't understand exactly what you mean -- maybe it's the nomenclature you are using. A packet is fragmented into one or more frames. Therefore, a frame is part of a packet. - Do you mean that you cannot use packets smaller than 64 bytes? RX or TX? - Do you mean that you cannot use packets bigger than 64 bytes? RX or TX? If you understand this, and the issue is truly that you cannot transfer more than one packet per frame, there is no problem -- this is the way USB-CDC works. Also: Did you use the TI USB Library C code as a starting point, or did you do it from the beginning in a
  12. To close the loop on this, some time ago I managed to get a generally stable & workable CDC-only implementation of the MSP430 USB firmware working. I've tested mostly on Mac & Linux. It's also trimmed-down to under 3.5KB, and I expect I could get it down to maybe 2.7KB if I really tried. The team that coded the MSP USB library has __atrocious__ coding style. The code is on GitHub as part of my OpenTag project. The platform is a 5509-based stick.
  13. Years ago I used a CC2510 with Smart RF Studio and a larger antenna to achieve ~150m outdoor line-of-sight. I don't actually remember what modulation I was using, but a good guess is 28kbps FSK +/- 50kHz, given some of the things I work with. If you want range, you can develop your software on the 2500 and then switch to the CC430, CC11xx, or another sub-1GHz transceiver. If you can build a decent antenna, you can get insane range from the 433 MHz band. I have achieved reliable 1km outdoor NLOS with a CC1101 using 28 kbps GFSK +/- 50kHz @ 433 MHz, -3dBm. In the USA you can use the 900
  14. 5529 has built-in USB. Hopefully there is a way to use it on this launchpad.
  15. Stellaris launchpad is one hell of a deal. Dare I say, it's an even better deal than the MSP430 Launchpad is. Cortex M4F is a beast. There is a fair amount of work from the guys at leaflabs (leaflabs.com) on Maple, which is for STM32 what Energia-Stellaris appears to be for, well, Stellaris. Both Stellaris and STM32 use Cortex M3 and M4 cores, and some peripherals are the same (but not all). So, there is likely to be a lot of potential for cross-platforming Maple and Engeria-Stellaris modules. That's cool. You might also find it possible to load ChibiOS, which supports a lot of ne
  16. I have a board that I'd like to support with Energia. Honestly, I don't know much about wiring/arduino, but I do know *a lot* about drivers as well as MSP430. For now, what I'm interested in is the LaunchpadCDC driver moreso than the rest. My board uses a CC430F5137/5147 in addition to a MSP430F5503. The 5503 provides the USB interface. Energia could run on either, or both. Indeed, there is a WSN RTOS on the CC430, but it is small enough that Energia could be used productively to make user sketches for all kinds of things. That is another task for me, to port the C API. First, th
  17. I assume you have seen the Chronos CC430 watch evaluator. I think your screen is much superior to the segmented screen on the Chronos, but maybe you could retrofit? The CC430 is a pretty good chip, and the Chronos watch design is pretty nice apart from the display. In any case, I would check it out.
  18. Soldering the package might be a breeze, but getting the USB working can be difficult. TI has a Windows-based configurator program that can dump out a mostly-working driver to your specifications, but I've found the CDC (i.e. virtual COM port) to be a giant pain to implement. In my tests, sometimes it works, sometimes it doesn't -- although I will admit that the USB port is hooked up to a Linux host, which has not been TI's forte in past USB device driver attempts. When it doesn't work, it will also crash your firmware because it will get stuck in a Suspend-Reset loop. I'm hoping that
×
×
  • Create New...