Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by mbeals

  1. I'm using timer B to generate a fixed width, variable frequency pulse train (timer up mode, timer1 in set/reset, ccr1 fixed to 10 cycles and ccr0 adjusted between 500 and 65535 counts). I need to generate a software triggered, single pulse on timer 2 that is in phase with this pulse train. So basically some event happens and the next time the timer rolls over it generates a single pulse on the timer 2 pin. The "obvious" thing I tried was to: 1. Enable interrupt on ccr2 2. Use the software trigger to change timer 2 from outmod_0 to outmod_7. 3. Let the timer generate the pulse a
  2. Sorry, for some reason i remembered it as bring yours. I just looked back and discovered it was @@RobG 's
  3. Nothing embedded related really, although I have been tinkering with migrating @@spirilis 's TFT code into c++ objects with some classes to make drawing and manipulating text boxes and menu structures easier. Most of my time has been spent fighting with allied vision's gige camera API. The documentation is absolutely horrendous
  4. At least the latest revision of the g launchpad can.
  5. Yes you can. That's what I'm doing with mine. I just made the icsp programming header for the MCU match the pinout on the launchpad. As for a single sided board, in sure it's possible but it's going to be tough. The QFN footprint would not be fun to home etch
  6. I'm working with a 3M microSD card holder (mainly because the footprint already exists in the AdaFruit libraries)....but I'm having some issues making sense out of it. The footprint is setup with the two tabs on the back labeled as "card detect". However, these tabs just connect to the metal case, which then connect directly to ground elsewhere. So as it sits, the card detect line is just a direct connection to ground. I pulled the data sheet and the only piece of info it has is a cryptic diagram saying when the card is in, pin #2 is connected to pad #2 (card). So when the card is in,
  7. So I finally soldered up the board with the encoder and the hardware debounce circuit. That seems to have done the trick....no more oddball behavior
  8. It's a work project, so I can't go into a ton of detail, but it is going into a larger setup to do basic beam steering.
  9. I'm starting to build up a driver for a fast steering mirror... Basically just a 2 channel DAC that outputs -10 -> 10 V except with the hardware to load and playback pre-defined sequences (stored on an SD card). It also has a TFT display to let it work as a stand alone unit.
  10. So... I made an attempt with limited success. My code looked something like this (I'm on my phone so I can't copy the actual code): Port 1, interrupt on encoder channel A; Timer A 0 in up mode, interrupt off; Ta0ccr0 = 40ms; Port 1 Isr: Disable port 1 interrupt; Check state of B to determine direction; Reset timer to 0 and enable interrupt; Timer isr: Disable timer interrupt; Enable port 1 interrupt; It seems to have cleaned things up quite a bit, but I'm still getting random spurious counts. The scope shows the edges can get really messy, so I'm hoping the hardware filter can stab
  11. Yea, my board design does have an RC filter on those lines very similar to what you drew up (pulled it from the encoder's data sheet, so I'm assuming it will work well). I was just prototyping with some jumpers and a launchpad while I wait for parts to arrive. I will give the software debounce a shot though. The detents are small and deep enough that it is pretty tough to get the encoder to half-step. thanks!
  12. I tried the counter too, and was getting oddball results (which is why I set the breakpoint). It might just be my current lack of debounce on the lines though.
  13. I tried basically that (just backwards... Pull ups on the two pins and common grounded. When I put a breakpoint in the isr, it would halt when I clicked it over, but both flags were set and the two pins always showed high.... I suppose that could just be a quirk of the debugger though.
  14. I have some quadrature encoders I'm working to interface with. The issue is that they have detents that are aligned with the "open" state on both lines (so you can idle them with zero current draw). During a single "click", both channels will experience a full pulse, with one channel leading the other to indicate direction. I'm curious what is considered the best way to handle this. Do I need to use timer capture and figure out which pulse was first, or is there something simpler I can do with just standard interrupts? I did try it out with just interrupts, but when I put a breakpoin
  15. @greeeg, that's probably what happened. The connector I used was 'upside down' compared to what is on my launchpad. Didn't know that option existed... Now I do. I don't have the passives to wire up a new board, so it would take a lot of rework to do a full transfer. Looking at my design, with it wired backwards, power was shorting directly into the shielding (which was grounded) so I'm wondering if the other components even received much reverse voltage. I will convert the files to PDF in a little bit
  16. Does anyone have any thoughts about what would keep the mcu from booting? I have dumped the boot loader and main flash and diffed it against the firmware provided by TI, and it is an exact match.
  17. so it appears I somehow reversed the USB connector.... which is odd since I don't even remember modifying the connector used in the TI reference docs. I've flipped it back around and am no longer having the same issue with current draw, but I think running it reversed might have blown out the USB transceiver on the micro, as I can't get any computer to recognize it as a USB device. On another odd note... I programmed a simple "LED blink" script to test if I could program the MCU. It works when I run it in the debugger, but if I just apply power, the firmware doesn't load. I'm wondering
  18. I built up a programmer based on the ezFET reference design but am having problems getting it to work. I've run through all the debugging steps I know of, and nothing seems to help...so I'm turning to you guys to show me the obvious thing I'm missing. So here's the problem: Every time I plug the board in over USB, it acts as if there is a dead short. The light on my hub starts to flicker/go off and my linux box just hard freezes and becomes completely unresponsive until I unplug it. My windows machine doesn't complain, but it also does not see the device plugged in. I cut a USB cable
  19. I won't get to any serious development this week, but I'm at least thinking about how I want to approach it. This is a LFM (linear fm) TDM (time division multiplex) MIMO (multiple input/output) S-band phased array radar that I built as part of an MIT summer course. The current iteration is using an ATmega dev board to drive the transmitter, process the return and transmit it over USB to the host processing software. The problem is that the MCU is somewhat under powered which is impacting the PRF. The data transmission operation is blocking, so there is a fair amount of dead time that co
  20. Okay, thanks. That makes sense.
  21. quick question for you. I've been comparing schematics and noticed that you have a SBW_NC net (that is in the TI schematic too), but it is not connected to anything. Is that net really not connected, or am I overlooking something?
  22. I'm building up an asynchronous buck regulator that uses an MSP430 as the base. I'm using the micro to drive a P-channel mosfet through a small gate drive circuit made up of a handful of transistors. I based my design on this app note from ATMEL: http://www.atmel.com/Images/Atmel-42183-Design-a-Buck-Converter-with-XMEGA-E_AP-Note_AT04204.pdf The goal of the project is to be able to have a zero drop out regulator to supply some DC motors with up to 4A of current. Input voltages can range from 6V up to 12.6V (2 to 3 cell lipo) and I want to be able to regulate from ~1V up to Vbat.
  23. sorry, the part was UTC2837, and it is a high side, N-MOSFET controller. Reading more into it, it appears to have an onboard charge pump it uses to drive the gate....so it looks like standard 3v logic won't cut it. However, after doing some research, it appears something like an LM2745 can work. It has enough range (drops out at 1V) that I shouldn't need to bypass it. thanks
  24. I am using an external FET driver (VCC2837) with a power mosfet to create a regulated, high current (~4A) voltage rail to feed some DC motors. However, I would like to be able to manually bypass the regulator to supply the bus with raw battery voltage. Since I'm using an external FET, can I simply tie the gate of the fet to a gpio pin on the mcu and manually control the fet that way (after disabling the regulator)....or will this likely muck up the stability of the regulator?
  • Create New...