Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by oPossum

  1. Looks good. 74AHC164 may be a better choice for this application - it doesn't have the output latch that is not needed and just adds more latency. The delay per stage is 62.5 nS - everything is on the same clock. tpd is simply one limiting factor for max clock rate.
  2. Not suggesting an implicit volatile. Also not suggesting that a for() loop should be used as a delay - no matter how the loop var is declared. So... int x; // global void foo(void) { ++x; } Should ++x be optimized away? When foo() is called it is expected that x will increment. How would the compiler know that the delay loop (in the code in the first post) isn't doing something important with the global variable?
  3. Neither method is portable - they both rely upon undefined behavior of the C compiler. As a practical matter they are equally portable. The only popular big endian microcontoller was the M68k series, and it is essentially dead. If you think there is a small difference in code size and speed - just look at the asm code generated by the compiler...
  4. The variable used is a non-static global, so the compiler won't optimize it away because it could be referenced in other object files (created from other source files that the compiler has no immediate knowledge of).
  5. aa = (byte) (cast >> 24); bb = (byte) (cast >> 16); cc = (byte) (cast >> 8); dd = (byte) cast; faster code: byte *p = (byte *)&cast; dd = *p++; cc = *p++; bb = *p++; aa = *p;
  6. This is a quick test of playback of vintage drum machine sounds. In the 80's there where several popular drum machines that used samples of real drums stored in 27xx series EPROMs. They would simply sequentially address the EPROM and the data was sent to a companding DAC (Am6070). Some sounds also had a filter or envelope applied - this code does not do that. These old machines had numerous EPROM chips to store the samples. With modern flash technology it is possible to put a complete sample set right in the microcontroller itself. Right now this just loops through all the samples in a set
  7. The old ones had no chip at all - just a mag head.
  8. The ESD protection of USB data lines is often omitted because it is an uncommon failure mode and many products are very price sensitive. Using external diode clamps with modern CMOS chips is often ineffective because the internal diodes between the inputs and supply rails will have lower Vf, so the current will still flow through them and not the external diodes. Any scheme using resistors and/or Zener diodes will tend to slow the edges and present a rather ugly load to the source. Using a 5V tolerant buffer will present a normal CMOS input to the source and have an output that alw
  9. Use timer capture to determine exactly when the source pulse occurred and then use timer compare to recreate the pulse some exact time later. There will be a minimum delay due to ISR latency and the time it takes to setup the timer compare, probably less than 50 cycles. The max delay would be aprox 65480 cycles.
  10. I want to find a way to reprogram the eZ430 that anyone could use - BSL, Launchpad or something. First step is to actually get it to work by any means - not there yet.
  11. Yes, they have to be matched - EEPROM and F1216 firmware. Know all that and a lot more. I wrote F1216 code to read/write the EEPROM. Have firmware images of EEPROM and F1216 for several eZ430 versions and the LP - seem to be good. Was trying to do it using BSL and coulndn't make it work. Have a real MSP-FET430UIF now.
  12. Yea, you would think so. Right now I have a few dead eZ430 and LP Got a new plan that I think will work.
  13. Yes, looks like all the MSP430 dev hardware has gone up in price. eZ430-F2013 20 -> 24 eZ430-Chronos 50 -> 56 MSP-FET430UIF 100 -> 115
  14. Yes, device support is limited. I am working on a fix for that. The price for the F2013 kit is $24 on the order page.
  15. Abandoned eZ430? All four versions are still available, and a fifth target board will be soon. http://www.ti.com/lsds/ti/microcontroller/16-bit_msp430/hardware_and_software.page?DCMP=MSP430&HQS=Tools+OT+ez430#eZ430
  16. http://forum.43oh.com/topic/2481-launchpad-mini-revision-3/ http://forum.43oh.com/topic/2482-3-way-50x50mm-proto-board/ Have been working on a low cost FET for use with those. Couldn't touch the $4.30 price point, but that has ended.
  17. Three ways to do software RTC: http://forum.43oh.com/topic/1957-software-real-time-clock-rtc-two-methods/
  18. First post updated with improved assembly code. Forgot to mention that the when 0 is passed to the second or third argument of muldiv() it is interpreted as 2^16 (65536, 0x10000). This allows the full 16 bit range to be used as in and/or out ranges with scale().
  19. One of the limitations of the C language is that multiplication truncates the result to match the size of the multiplicands. So if you multiply two 16 bit numbers, the result is limited to 16 bits despite 32 bits being needed to represent all possible results. The fix for this is to cast one of the multiplicands to a larger type. Unfortunately this results in the use of a multiply library routine that is larger and slower than necessary. Division has a similar problem - the quotient, dividend, and divisor are all the same size. The way I fix these limitations is to write assembly code that
  20. This code can use polling or sleep with interrupt as determined by the #define ADC_SLEEP http://forum.43oh.com/topic/1954-using-the-internal-temperature-sensor/
  21. CCSv4 (what I use) doesn't support 64 bit integers. Using CCSv5 with -O 4 -mf 5... Well, at least it inlined the mul824() function. I will take on any MSP430 compiler. Guaranteed faster code or your money back. LOL #include <msp430.h> #include <stdint.h> uint32_t mul824(uint32_t a, uint32_t { // Multiply 8.24 fixed point in a by b // Return is same type as b return (((uint64_t)a * >> 24) & 0xFFFFFFFF; } void main(void) { volatile uint32_t a = 0x01000000; volatile uint32_t b = 0x12345678; volatile uint32_t x = mul824(a, ; volatile uint32_t
  22. When working with electronic music (MIDI synth and such) it is sometimes necessary to adjust pitch by units of octaves, semitones, or cents. An octave is a 2:1 ratio. So the ratio between any number of octaves is 2^N. This is a simple bit shift. Easy. A semitone is 1/12 of an octave (typically), so the ratio for that is 2^(N/12). A cent is 1/1200 of an octave, so the ratio for that is 2^(N/1200). Can't use bit shifting for that! The C stdlib provides the pow() function that can be used for these calculations, but it uses rather slow floating point math. This code will do it wit
  23. This code will multiply an unsigned 8.24 fixed point number by a unsigned 32 bit value (any binary point). The returned result is adjusted for the binary point (right shift 24 bits). It could be done like this: uint32_t mul824(uint32_t a, uint32_t { // Multiply 8.24 fixed point in a by b // Return is same type as b return ((uint64_t(a) * >> 24) & 0xFFFFFFFF; } Unfortunately C uses a product accumulator with the same number of bits as the multiplicands, so this requires casts and is not as efficient as it could be. There are several optimizations done in
  24. Sleeping during ADC conversion can sometimes help.
  25. It is. One of many reasons I use CCS - easy to mix asm with C, better documentation, usually faster code, and overall just much more productive. Try this, Think in asm, write in C. if(--fade_shifts_counter) { fade_shifts_counter = FADE_SHIFTS_STEP; ++fade_shift; }
  • Create New...