Jump to content
43oh

moonshadow

Members
  • Content Count

    9
  • Joined

  • Last visited

  1. Oooh, didn't know about Hackaday. So much win on that site!
  2. @GeekDoc: thanks It wasn't clear to me how to make the motor able to reverse direction, so I went for the component that solved the problem instead. However, it's not really so much of a waste - I want to have a go making a logo turtle next, so I will be reusing the controller in that (it's mounted via headers/sockets so I can unplug it); at that point being able to arbitrarily control two motors, and their speeds, easily will be very useful.
  3. Sorry, link wasn't very obvious Edited to add a thumbnail.
  4. Click for larger photo The two voltage regulators at the front provide 3.3v and 5v from a 12v wall wart I had lying around. A gearmotor is driven by a TB6612FNG (the red breakout board in the photo; PWMA is tied high, A0IN/A1IN are tied to P1.6/P1.7 on the msp430, vcc/vmotor/gnd/reset are connected as appropriate). The IR receiver demodulates at 38khz (it was surprisingly difficult to find one that operates at 3.3v, 5v seems to be standard); it is connected to P1.5 on the MSP430. The circuit was built on a breadboard initially, with the launchpad attached and reporting infrared samples to
  5. I get that occasionally here. Shut down your comms software, pull out the USB cable, reattach and restart. It'll take a minute or two for the port to come back up. Make sure the software on the launchpad configures the RX pin to input and leaves the TX pin high when idle, otherwise cdc-acm will refuse to recognise the UART.
  6. GCC's asm() directive takes assembly code, followed by lists of outputs, inputs and things that the compiler is to assume have become dirty. The statement asm("":::"memory") generates no code, but tells the compiler to assume that any state held in memory may have been mutated as a side effect. This leaves GCC unable to make assumptions about the contents of variables following this statement, preventing optimisations that rely on such assumptions. A for loop with that statement in the body generates assembly very similar to that in your post - the appropriate increment / decrement, a
  7. I usually use #define GCC_BARRIER asm("":::"memory") GCC will not reorder reads and writes across GCC_BARRIER, will not retain values in registers across GCC_BARRIER (so globals etc. will be refetched), and will not optimise away loops containing a GCC_BARRIER, so int i; for (i = 0; i < 1000; i++) GCC_BARRIER; is a nice concise delay loop.
  8. Here's the state it's currently in. The code is for the mspgcc toolchain. The sensor is attached to 1.7 and ground. It's moved on a little since my last post: the signals I am analysing are pulse width modulated, so all the 0s are the same width so I discard those samples; given that, 16 pulses' worth of input buffer is enough for the longest code the remote transmits, so I scrapped the logic that dealt with the buffer filling to reduce the time spent in the port ISR. Also since I am only reporting logic 1 pulse widths I no longer need to keep track of the idle time in main(). I now a
  9. For the record, I've just written code to use the launchpad as a logic analyzer to reverse engineer an infrared remote control protocol. I wired the sensor to a pin set to trigger an interrupt on a low->high edge and also started a clock counting at 1MHz. The ISR stores the current TAR value in a ring buffer and flips which edge triggers the next interrupt. After initial configuration, main() enters an infinite loop waiting for data to arrive in the ring buffer; when it does, the difference between successive timestamps is emitted through the UART (I convert it to hex digits so it's readabl
×
×
  • Create New...