mbeals

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

Sorry, for some reason i remembered it as bring yours. I just looked back and discovered it was @@RobG 's

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

At least the latest revision of the g launchpad can.

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

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,

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

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.

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.

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

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!

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.

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.

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

Here is my schematic