Sign in

Search piclist

Subscribe to piclist

piclist by Keywords

12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

Discussion Groups

Discussion Groups | Piclist | Re: [fpga-cpu] Xilinx bitgen problem

A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.

Re: [fpga-cpu] Xilinx bitgen problem - Guil...@h... - Jan 4 20:04:00 2001

Hi! Maybe what I'm going to said is stupid, but "the clk has no source".... What clk is that??? Are you using the fpga external clock??? If you are not, I think you my try it, by using pin 13. That's what I think... sorry if it's dumb... hehe ;P Thanks for listening... Jorge, Guilherme ----- Original Message ----- From: "Bharath Kumar" <bharath.kumar@w...> To: <f...@egroups.com> Sent: Thursday, January 04, 2001 6:58 AM Subject: [fpga-cpu] Xilinx bitgen problem > hi All, > I tried my first design using design manager yesterday... > I was able to succesfully complete the flow upto Place and Route(PAR).... but > "Bitgen" is giving some problem as follows: > **************************************************************************** ********* > Running DRC > ERROR:DesignRules:368 - Netcheck: Sourceless. Net clk has no source. > ERROR:DesignRules:10 - Netcheck: The signal "clk" is completely unrouted. > **************************************************************************** ************* > > I couldnt get the exact meaning of the above message...Please help me. > > thanks and Regards, > Bharath > Bangalore, INDIA > > > [Non-text portions of this message have been removed] > To Post a message, send it to: f...@eGroups.com > To Unsubscribe, send a blank message to: f...@eGroups.com

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: [fpga-cpu] Xilinx bitgen problem - Guil...@h... - Jan 4 20:04:00 2001

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: [fpga-cpu] Xilinx bitgen problem - Guil...@h... - Jan 4 20:04:00 2001

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: [BasicX] New file uploaded to basicx - Rais...@y... - Apr 25 19:40:00 2001

you don't know where i can get a neon sign transformer do you? ----- Original Message ----- From: Westhoff To: b...@yahoogroups.com Sent: Wednesday, April 25, 2001 7:17 PM Subject: Re: [BasicX] New file uploaded to basicx The schematic is labeled as a 20KVolt supply. That is quite high for electrolysis of water and would need a large amount of current. The easiest way to do this is to get an old neon sign transformer the larger the better. They will produce the high voltage at a fairly high current. However, you could easily KILL yourself with a supply of this type. 20KVolts will jump about an inch gap and maintain an arc at an even larger distance. I don't think it is a proper application for electrolysis of water. Raistlin Majere wrote: > do you know where these parts can be purchased from so that i can build it? > ----- Original Message ----- > From: GTBecker@R... > To: b...@yahoogroups.com > Sent: Tuesday, April 24, 2001 2:19 PM > Subject: Re: [BasicX] New file uploaded to basicx > > > a file has been uploaded to the Files area of the basicx group. > > That's a ~10kVDC power supply, powered by 12VDC. Schematic components to the > left of the transformer core are those of a blocking oscillator; on the right, > half-wave rectifier and smoothing capacitor. > > This might be an automobile neon supply or maybe an afterburner ignitor... > > Tom Becker > --... ...-- > GTBecker@R... GTBecker@O... > The RighTime Clock Company, Inc., Cape Coral, Florida USA > www.RighTime.com > > Yahoo! Groups Sponsor Yahoo! Groups Sponsor Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. [Non-text portions of this message have been removed]

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Exceptions occur while debugging thru JTAG - Leig...@y... - Oct 28 10:34:00 2004

While I'm debugging a device running a single EINT as FIQ and timers & uart through IRQ, I tend to get exceptions (undef, swi, prefetch, data) occuring randomly while I'm stepping through the code. Currently, I don't have any code done for these exceptions. I've also experienced data aborts whenever I use the JTAG to download, & debug code. I reverted back to ISP downloading (serial port) because of this. However, the JTAG doesn't seem to be crashing as the JTAG always shows the PC excecuting the undefined exception vectors. So, I'm not sure what could be causing these exceptions to happen. Any ideas/suggestions? best regards, Leighton

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface - rtstofer - Jan 27 21:23:00 2005

It will probably work but remember you are dealing with 50 Hz so the filter needs to be designed for this very low frequency. Sometimes, accuracy isn't important. You would do better to look at http://www.awce.com/pak7.htm and get the values directly using a simple serial protocol. --- In , "Ori" <sbarbut@s...> wrote: > > Hi all, > > I would like to interface an R/C receiver (6 channels, giving servo > pulses) to a PIC, such that I can get some number on the PIC that is > somehow proportional to the position of the joystick on the R/C > transmitter. > > Am I silly to think that the pulses could be 'averaged' with a > capacitor into an analog signal, which could be read by the A2D inputs > of my PIC? > > Thanks in advance, > > Ori

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface - Phil - Jan 28 2:42:00 2005

Why not have the PIC read the pulses directly? I don't see the need to go to analog and then digital or use some other chip. iirc, it's a very low frequency PWM - the pulse width in the 20 mS window is all you need to know. I'd bet the pulse coprocessor is basically a preprogrammed microcontroller. In fact the pin out looks pretty similar to some of the OTP PICs. Phil --- In , "rtstofer" <rstofer@p...> wrote: > It will probably work but remember you are dealing with 50 Hz so the > filter needs to be designed for this very low frequency. Sometimes, > accuracy isn't important. > > You would do better to look at http://www.awce.com/pak7.htm and get > the values directly using a simple serial protocol. > > --- In , "Ori" <sbarbut@s...> wrote: > > > > Hi all, > > > > I would like to interface an R/C receiver (6 channels, giving servo > > pulses) to a PIC, such that I can get some number on the PIC that > is > > somehow proportional to the position of the joystick on the R/C > > transmitter. > > > > Am I silly to think that the pulses could be 'averaged' with a > > capacitor into an analog signal, which could be read by the A2D > inputs > > of my PIC? > > > > Thanks in advance, > > > > Ori

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface - bengtson - Jan 28 14:44:00 2005

--- In , "dan michaels" <dan@o...> wrote: > > --- In , "Ori" <sbarbut@s...> wrote: > > > > Hi all, > > > > I would like to interface an R/C receiver (6 channels, giving servo > > pulses) to a PIC, such that I can get some number on the PIC that is > > somehow proportional to the position of the joystick on the R/C > > transmitter. > > > > Am I silly to think that the pulses could be 'averaged' with a > > capacitor into an analog signal, which could be read by the A2D > inputs > > of my PIC? > > > > Thanks in advance, > > > > Ori > I've been thinking about various ways to solve this same problem. For > 2 channels, it's not hard to measure the pulsewidths directly on a > PIC. For 6 channels, it's a real problem to get accuracy to 8-bits or > more. > > Regards doing it via an RC-filter, the problem is that the pulses are > 1-2 msec long, sitting on a 20-msec update rate. This means the > effective duty cycle of the RC receiver PWM is only 5-10%, which > means the voltage out of the RC-filter goes only from 0.25-0.5v (for > 5v signal), so your A/D resolution will be very low - values 12-25 > out of 256, or 51-102 out of 1024. On top of that, the voltage out of > the RC-receiver isn't gonna be 5v. You don't really know what it will > be. > > - dan michaels > www.oricomtech.com > ======================= I agree with Dan on the resolution using the A/D approach. I do think that it's possible to read a full 6 channels digitally with a single PIC. Using a timer triggering an interrupt at 20KHz (50uS period), all 6 channels could be read at each interrupt and processed outside the interrupt within the 50uS easily. This allows for each channel to be positioned at one of 400 positions in the 20mS period. More than 8-bits. I've seen software that does this. Not sure that it was running 6 channels but it could adapted. Mike Bengtson

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface - rtstofer - Feb 2 11:11:00 2005

--- In , bengtson <no_reply@y...> wrote: > > > --- In , "dan michaels" <dan@o...> wrote: > > > > --- In , "Ori" <sbarbut@s...> wrote: > > > > > > Hi all, > > > > > > I would like to interface an R/C receiver (6 channels, giving servo > > > pulses) to a PIC, such that I can get some number on the PIC that is > > > somehow proportional to the position of the joystick on the R/C > > > transmitter. > > > > > > Am I silly to think that the pulses could be 'averaged' with a > > > capacitor into an analog signal, which could be read by the A2D > > inputs > > > of my PIC? > > > > > > Thanks in advance, > > > > > > Ori > > > > > > I've been thinking about various ways to solve this same problem. For > > 2 channels, it's not hard to measure the pulsewidths directly on a > > PIC. For 6 channels, it's a real problem to get accuracy to 8- bits or > > more. > > > > Regards doing it via an RC-filter, the problem is that the pulses are > > 1-2 msec long, sitting on a 20-msec update rate. This means the > > effective duty cycle of the RC receiver PWM is only 5-10%, which > > means the voltage out of the RC-filter goes only from 0.25-0.5v (for > > 5v signal), so your A/D resolution will be very low - values 12- 25 > > out of 256, or 51-102 out of 1024. On top of that, the voltage out of > > the RC-receiver isn't gonna be 5v. You don't really know what it will > > be. > > > > - dan michaels > > www.oricomtech.com > > ======================= > > I agree with Dan on the resolution using the A/D approach. I do think > that it's possible to read a full 6 channels digitally with a single > PIC. Using a timer triggering an interrupt at 20KHz (50uS period), > all 6 channels could be read at each interrupt and processed outside > the interrupt within the 50uS easily. This allows for each channel to > be positioned at one of 400 positions in the 20mS period. More than > 8-bits. It seems to me that the 1000uS to 2000uS active pulse, divided by 50 uS only leaves a count between 20 and 40 - more like 6 bits Better than the A2D approach but still requires interrupts at a 20 KHz rate. > I've seen software that does this. Not sure that it was running 6 > channels but it could adapted. > > Mike Bengtson

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface - Phil - Feb 3 3:22:00 2005

--- In , "rtstofer" <rstofer@p...> wrote: > > --- In , bengtson <no_reply@y...> wrote: ... > > I agree with Dan on the resolution using the A/D approach. I do > think > > that it's possible to read a full 6 channels digitally with a > single > > PIC. Using a timer triggering an interrupt at 20KHz (50uS period), > > all 6 channels could be read at each interrupt and processed > outside > > the interrupt within the 50uS easily. This allows for each > channel to > > be positioned at one of 400 positions in the 20mS period. More > than > > 8-bits. > > It seems to me that the 1000uS to 2000uS active pulse, divided by 50 > uS only leaves a count between 20 and 40 - more like 6 bits > > Better than the A2D approach but still requires interrupts at a 20 > KHz rate. 20khz interrupt rate is a walk in the park for a PIC, especially at 20 mhz - that's my system timer interrupt rate. BUT 50 uS gets you 20 counts on the proportional pulse width (1 mS) so its really closer to 4 bits of resolution. You need to be able to sample at slightly faster than 4 uS (250 khz) to get 8 bit res. The good news is its not hard and you dont need to melt the poor PIC. I'm not sure why 8 bit resolution is required but its acheivable. Use timer 1 - 16 bit timer, free running. Use a prescalar to make sure the full timer period is > 20 mS (2:1 or better at a 20 mhz clock). Use interrupt on change logic (see below). signals go into input pins. When you get an interrupt: figure out which pin and transition, read the timer, save the value, exit interrupt. on the falling transition, get the timer value and subtract (er add, I guess) start time (handle timer wrap around and adjust for the 1 mS dead time), store the value and exit the interrupt. Main loop handles communications. Some fussing is needed for IOC race conditions but its understood. You can get better than 8 bit resolution using 4:1 prescale on timer 1 this way. To make things easy, use a 4 Mhz Fosc and a 2:1 prescaler to give you 250 timer counts for a 2 mS pulse - (2mS - 1mS)/4uS The key to this is interrupt on change logic. Many PICs have 4 pins with IOC so we're 2/3 the way there. If there are 2 external int pins, you can use those (reprogram the edge sense on each int). Or create external IOC logic. Also, I think the parallel slave port can be used with some effort. Kind of a fun exercise. Phil

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface - dan michaels - Feb 3 16:42:00 2005

--- In , "Phil" <phil1960us@y...> wrote: > 20khz interrupt rate is a walk in the park for a PIC, especially at 20 > mhz - that's my system timer interrupt rate. BUT 50 uS gets you 20 > counts on the proportional pulse width (1 mS) so its really closer to > 4 bits of resolution. You need to be able to sample at slightly > faster than 4 uS (250 khz) to get 8 bit res. > > The good news is its not hard and you dont need to melt the poor PIC. > I'm not sure why 8 bit resolution is required but its acheivable. > > Use timer 1 - 16 bit timer, free running. Use a prescalar to make > sure the full timer period is > 20 mS (2:1 or better at a 20 mhz > clock). Use interrupt on change logic (see below). signals go into > input pins. When you get an interrupt: figure out which pin and > transition, read the timer, save the value, exit interrupt. on the > falling transition, get the timer value and subtract (er add, I guess) > start time (handle timer wrap around and adjust for the 1 mS dead > time), store the value and exit the interrupt. Main loop handles > communications. Some fussing is needed for IOC race conditions but > its understood. You can get better than 8 bit resolution using 4:1 > prescale on timer 1 this way. To make things easy, use a 4 Mhz Fosc > and a 2:1 prescaler to give you 250 timer counts for a 2 mS pulse - > (2mS - 1mS)/4uS > > The key to this is interrupt on change logic. Many PICs have 4 pins > with IOC so we're 2/3 the way there. If there are 2 external int pins, > you can use those (reprogram the edge sense on each int). Or create > external IOC logic. Also, I think the parallel slave port can be used > with some effort. > > Kind of a fun exercise. > > Phil Hi Phil, this "almost" works. You're 5/6 of the way there. The problem is, I don't think you have that 6th interrupt pin available, at least on the PIC16' series. Maybe on some of the 18F' chips. On PIC16' you have the 4 IOC pins plus the INT/RB0 pin, but where's the 6th pin? You do have CCP1+CCP2 capture, but if you use those I'm not sure you can still use timer1 effectively for the other IRQs. For this kind of timing, timer0 and timer2 are not gonna work well, since they're really 8-bit res. Seems like 5 channels can be done ok. Interrupts seems like the natural way to go, in general, but maybe the last channel or 2 could be done using polled I/O. Problem is, for "general" measurement of r/c receiver pulses, you probably do want 8-bit res [at least I did on my project], which means you do have only 4 usec to conduct all the business. That's only 20 clocks @ 20 Mhz xtal, and just the overhead on the interrupts will burn most of this. - dan michaels www.oricomtech.com ======================

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: Re: R/C Receiver Interface KISS - Robert Rolf - Feb 3 17:52:00 2005

Unless things have changed significantly, the R/C world still transmits servo pulse widths as a serial stream of PWM, where each pulse is 0.5 to 2.0 msec or so, and separated by 0.5 msec, give or take a bit. The long time interval between the last pulse and the frame time (>5 msec) resets the receiver multiplexer. There is no need to handle all the servo signals in parallel since the receiver usually just demultiplexes the pulse stream and ships it out sequentially among the available channels. Even if the system is "digital", the data stream is still serialized pulse widths since it makes sense to distribute the power load of the servos slewing over the full frame time. http://www.futaba-rc.com/faq/faq-bots.html "Information on receiver/servo operation with and without radio control: The signals that go from the receiver to the servo are in the same format whether using AM, FM or PCM. The signals may differ in the length of the frame, number of channels, etc, but the FORMAT is the same. These are ANALOG signals in PULSE-POSITION modulation. Each CHANNEL within every frame may vary in length anywhere from about 1000 microseconds to 2000 microseconds, with center usually being around 1500 microseconds. " This is true even for 'digital' servos. http://www.multiplexusa.com/Support/manuals/servos/SUPER_FL_manual.pdf Angular travel (UNI signal format)3 � 40� at 1.5 � 0.5 ms Angular travel (MPX signal format)3 � 40� at 1.6 �0.55 ms http://www.futaba-rc.com/servos/digitalservos.pdf "Where a digital servo differs, is in the way it processes the incoming receiver information, and in turn controls the initial power to the servomotor, reducing the deadband, increasing the resolution and generating tremendous holding power." SO, the data from the receiver WILL BE SERIALIZED PULSES and so one would only need to wire-or the several pulses into ONE pin (diodes and a pulldown work well) and measure the individual periods as they happen, then detect the longer frame gap to reset the software channel counter. As an aside, in a particular application where we needed higher performance from an ANALOG servo (C-Leg computer leg prosthesis prototypes) I upped the refresh rate to 200Hz, and the Futaba servos we used were happy to slew much faster, much like the digital ones do (but which didn't exist back we did the development). Robert dan michaels wrote: > > --- In , "Phil" <phil1960us@y...> wrote: >>20khz interrupt rate is a walk in the park for a PIC, especially at > > 20 > >>mhz - that's my system timer interrupt rate. BUT 50 uS gets you 20 >>counts on the proportional pulse width (1 mS) so its really closer > > to > >>4 bits of resolution. You need to be able to sample at slightly >>faster than 4 uS (250 khz) to get 8 bit res. >> >>The good news is its not hard and you dont need to melt the poor > > PIC. > >> I'm not sure why 8 bit resolution is required but its acheivable. >> >>Use timer 1 - 16 bit timer, free running. Use a prescalar to make >>sure the full timer period is > 20 mS (2:1 or better at a 20 mhz >>clock). Use interrupt on change logic (see below). signals go into >>input pins. When you get an interrupt: figure out which pin and >>transition, read the timer, save the value, exit interrupt. on the >>falling transition, get the timer value and subtract (er add, I > > guess) > >>start time (handle timer wrap around and adjust for the 1 mS dead >>time), store the value and exit the interrupt. Main loop handles >>communications. Some fussing is needed for IOC race conditions but >>its understood. You can get better than 8 bit resolution using 4:1 >>prescale on timer 1 this way. To make things easy, use a 4 Mhz Fosc >>and a 2:1 prescaler to give you 250 timer counts for a 2 mS pulse - >>(2mS - 1mS)/4uS >> >>The key to this is interrupt on change logic. Many PICs have 4 pins >>with IOC so we're 2/3 the way there. If there are 2 external int > > pins, > >>you can use those (reprogram the edge sense on each int). Or create >>external IOC logic. Also, I think the parallel slave port can be > > used > >>with some effort. >> >>Kind of a fun exercise. >> >>Phil > > Hi Phil, this "almost" works. You're 5/6 of the way there. The > problem is, I don't think you have that 6th interrupt pin available, > at least on the PIC16' series. Maybe on some of the 18F' chips. > > On PIC16' you have the 4 IOC pins plus the INT/RB0 pin, but where's > the 6th pin? You do have CCP1+CCP2 capture, but if you use those I'm > not sure you can still use timer1 effectively for the other IRQs. For > this kind of timing, timer0 and timer2 are not gonna work well, since > they're really 8-bit res. Seems like 5 channels can be done ok. > > Interrupts seems like the natural way to go, in general, but maybe > the last channel or 2 could be done using polled I/O. Problem is, > for "general" measurement of r/c receiver pulses, you probably do > want 8-bit res [at least I did on my project], which means you do > have only 4 usec to conduct all the business. That's only 20 clocks @ > 20 Mhz xtal, and just the overhead on the interrupts will burn most > of this. > - dan michaels > www.oricomtech.com > ======================

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - rtstofer - Feb 3 18:35:00 2005

So, the trick would be to get the receiver signal before it is demultiplexed to the multiple servos rather than grabbing individual servo signals. Even it this couldn't be done, a 6 input OR gate should do the job as the signals don't overlap. This might be as simple as 6 diodes and a pull-down resistor (assuming positive going signals). Makes sense. It wouldn't be overly difficult to use the IOC and just keep track of which part of the frame you are in as you count up the pulse widths. Find a gap of about 5mS and the next leading edge is the beginning of the first servo pulse. Count time until the falling edge, update the value and get ready for the second servo pulse that will probably start in about 500 uS. And so on... Maybe I'll get an R/C setup one day just to see what I can do with it. Right now I am working on a project where I threw out the R/C bits (it wasn't proportional anyway), kept the motor and steering and am driving it with a uC. --- In , Robert Rolf <robert.rolf@u...> wrote: > Unless things have changed significantly, the R/C world still > transmits servo pulse widths as a serial stream of PWM, where > each pulse is 0.5 to 2.0 msec or so, and separated by 0.5 msec, > give or take a bit. The long time interval between the last > pulse and the frame time (>5 msec) resets the receiver > multiplexer. > > There is no need to handle all the servo signals in parallel > since the receiver usually just demultiplexes > the pulse stream and ships it out sequentially among the > available channels. > > Even if the system is "digital", the data stream is still > serialized pulse widths since it makes sense to distribute > the power load of the servos slewing over the full frame time. > > http://www.futaba-rc.com/faq/faq-bots.html > "Information on receiver/servo operation with and without radio control: > The signals that go from the receiver to the servo are in the same > format whether using AM, FM or PCM. The signals may differ in the length > of the frame, number of channels, etc, but the FORMAT is the same. These > are ANALOG signals in PULSE-POSITION modulation. Each CHANNEL within > every frame may vary in length anywhere from about 1000 microseconds to > 2000 microseconds, with center usually being around 1500 microseconds. " > > This is true even for 'digital' servos. > http://www.multiplexusa.com/Support/manuals/servos/SUPER_FL_manual.pd f > Angular travel (UNI signal format)3 � 40� at 1.5 � 0.5 ms > Angular travel (MPX signal format)3 � 40� at 1.6 �0.55 ms > > http://www.futaba-rc.com/servos/digitalservos.pdf > "Where a digital servo differs, is in the way it processes the incoming > receiver > information, and in turn controls the initial power to the servomotor, > reducing > the deadband, increasing the resolution and generating tremendous holding > power." > > SO, the data from the receiver WILL BE SERIALIZED PULSES and so one > would only need to wire-or the several pulses into ONE pin > (diodes and a pulldown work well) > and measure the individual periods as they happen, then > detect the longer frame gap to reset the software channel counter. > > As an aside, > in a particular application where we needed higher performance > from an ANALOG servo (C-Leg computer leg prosthesis prototypes) > I upped the refresh rate to 200Hz, and the Futaba servos we > used were happy to slew much faster, much like the digital > ones do (but which didn't exist back we did the development). > > Robert > dan michaels wrote: > > > > --- In , "Phil" <phil1960us@y...> wrote: > > > > > >>20khz interrupt rate is a walk in the park for a PIC, especially at > > > > 20 > > > >>mhz - that's my system timer interrupt rate. BUT 50 uS gets you 20 > >>counts on the proportional pulse width (1 mS) so its really closer > > > > to > > > >>4 bits of resolution. You need to be able to sample at slightly > >>faster than 4 uS (250 khz) to get 8 bit res. > >> > >>The good news is its not hard and you dont need to melt the poor > > > > PIC. > > > >> I'm not sure why 8 bit resolution is required but its acheivable. > >> > >>Use timer 1 - 16 bit timer, free running. Use a prescalar to make > >>sure the full timer period is > 20 mS (2:1 or better at a 20 mhz > >>clock). Use interrupt on change logic (see below). signals go into > >>input pins. When you get an interrupt: figure out which pin and > >>transition, read the timer, save the value, exit interrupt. on the > >>falling transition, get the timer value and subtract (er add, I > > > > guess) > > > >>start time (handle timer wrap around and adjust for the 1 mS dead > >>time), store the value and exit the interrupt. Main loop handles > >>communications. Some fussing is needed for IOC race conditions but > >>its understood. You can get better than 8 bit resolution using 4:1 > >>prescale on timer 1 this way. To make things easy, use a 4 Mhz Fosc > >>and a 2:1 prescaler to give you 250 timer counts for a 2 mS pulse - > >>(2mS - 1mS)/4uS > >> > >>The key to this is interrupt on change logic. Many PICs have 4 pins > >>with IOC so we're 2/3 the way there. If there are 2 external int > > > > pins, > > > >>you can use those (reprogram the edge sense on each int). Or create > >>external IOC logic. Also, I think the parallel slave port can be > > > > used > > > >>with some effort. > >> > >>Kind of a fun exercise. > >> > >>Phil > > > > > > > > Hi Phil, this "almost" works. You're 5/6 of the way there. The > > problem is, I don't think you have that 6th interrupt pin available, > > at least on the PIC16' series. Maybe on some of the 18F' chips. > > > > On PIC16' you have the 4 IOC pins plus the INT/RB0 pin, but where's > > the 6th pin? You do have CCP1+CCP2 capture, but if you use those I'm > > not sure you can still use timer1 effectively for the other IRQs. For > > this kind of timing, timer0 and timer2 are not gonna work well, since > > they're really 8-bit res. Seems like 5 channels can be done ok. > > > > Interrupts seems like the natural way to go, in general, but maybe > > the last channel or 2 could be done using polled I/O. Problem is, > > for "general" measurement of r/c receiver pulses, you probably do > > want 8-bit res [at least I did on my project], which means you do > > have only 4 usec to conduct all the business. That's only 20 clocks @ > > 20 Mhz xtal, and just the overhead on the interrupts will burn most > > of this. > > > > > > - dan michaels > > www.oricomtech.com > > ======================

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - dan michaels - Feb 4 13:46:00 2005

--- In , Robert Rolf <robert.rolf@u...> wrote: > Unless things have changed significantly, the R/C world still > transmits servo pulse widths as a serial stream of PWM, where > each pulse is 0.5 to 2.0 msec or so, and separated by 0.5 msec, > give or take a bit. The long time interval between the last > pulse and the frame time (>5 msec) resets the receiver > multiplexer. > > There is no need to handle all the servo signals in parallel > since the receiver usually just demultiplexes > the pulse stream and ships it out sequentially among the > available channels. Yeah, the problem is a lot easier if you are "gauranteed" that all pulses go in sequence, and there is no overlap and at least a bit of space between successive pulses. Someone mentioned that this might not always be the case. Is it guaranteed ?????

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - bazling - Feb 4 17:25:00 2005

--- In , "dan michaels" <dan@o...> wrote: > > --- In , Robert Rolf <robert.rolf@u...> wrote: > > Unless things have changed significantly, the R/C world still > > transmits servo pulse widths as a serial stream of PWM, where > > each pulse is 0.5 to 2.0 msec or so, and separated by 0.5 msec, > > give or take a bit. The long time interval between the last > > pulse and the frame time (>5 msec) resets the receiver > > multiplexer. > > > > There is no need to handle all the servo signals in parallel > > since the receiver usually just demultiplexes > > the pulse stream and ships it out sequentially among the > > available channels. > > Yeah, the problem is a lot easier if you are "gauranteed" that all > pulses go in sequence, and there is no overlap and at least a bit of > space between successive pulses. Someone mentioned that this might > not always be the case. Is it guaranteed ????? Just jumping in here: At the risk of disappointing you... In my experience - yes they are in sequence, but NO, I cannot measure any space between the pulses from the RC receiver consequtive channel outputs - using 50MHz 'scope.

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - bazling - Feb 4 17:25:00 2005

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - dan michaels - Feb 4 18:51:00 2005

--- In , "bazling" <Barry@k...> wrote: > > --- In , "dan michaels" <dan@o...> wrote: > > > > --- In , Robert Rolf <robert.rolf@u...> > wrote: > > > Unless things have changed significantly, the R/C world still > > > transmits servo pulse widths as a serial stream of PWM, where > > > each pulse is 0.5 to 2.0 msec or so, and separated by 0.5 msec, > > > give or take a bit. The long time interval between the last > > > pulse and the frame time (>5 msec) resets the receiver > > > multiplexer. > > > > > > There is no need to handle all the servo signals in parallel > > > since the receiver usually just demultiplexes > > > the pulse stream and ships it out sequentially among the > > > available channels. > > > > > > > > > Yeah, the problem is a lot easier if you are "gauranteed" that all > > pulses go in sequence, and there is no overlap and at least a bit > of > > space between successive pulses. Someone mentioned that this might > > not always be the case. Is it guaranteed ????? > > Just jumping in here: > At the risk of disappointing you... > In my experience - yes they are in sequence, but NO, I cannot > measure any space between the pulses from the RC receiver > consequtive channel outputs - using 50MHz 'scope. I'm not disappointed. I was interesetd in how to solve the problem in a general enough way that it would still work if the assumptions were not met. I was assuming sequence, but also leaving open the possiblity for some overlap. - dan michaels www.oricomtech.com =====================

Re: R/C Receiver Interface KISS

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - rtstofer - Feb 4 19:17:00 2005

--- In , "dan michaels" <dan@o...> wrote: > > --- In , "bazling" <Barry@k...> wrote: > > > > --- In , "dan michaels" <dan@o...> wrote: > > > > > > --- In , Robert Rolf <robert.rolf@u...> > > wrote: > > > > Unless things have changed significantly, the R/C world still > > > > transmits servo pulse widths as a serial stream of PWM, where > > > > each pulse is 0.5 to 2.0 msec or so, and separated by 0.5 msec, > > > > give or take a bit. The long time interval between the last > > > > pulse and the frame time (>5 msec) resets the receiver > > > > multiplexer. > > > > > > > > There is no need to handle all the servo signals in parallel > > > > since the receiver usually just demultiplexes > > > > the pulse stream and ships it out sequentially among the > > > > available channels. > > > > > > > > > > > > > Yeah, the problem is a lot easier if you are "gauranteed" that > all > > > pulses go in sequence, and there is no overlap and at least a bit > > of > > > space between successive pulses. Someone mentioned that this > might > > > not always be the case. Is it guaranteed ????? > > > > Just jumping in here: > > At the risk of disappointing you... > > In my experience - yes they are in sequence, but NO, I cannot > > measure any space between the pulses from the RC receiver > > consequtive channel outputs - using 50MHz 'scope. There must be a gap. Otherwise how could the receiver distinguish between pulses. Futaba has said that there is a 500 uS gap in the transmitted signal and I would certainly start looking in that direction. There would be no reason for the receiver to retime the signals before demultiplexing. I could see some reason to retime after demultiplexing so that all servos are synchronized but I wouldn't expect to see anyone actually do that. If you set your scope to 2 mS per division to see then entire string of pulses the gap would be 1/4 division. However, since the signal is continuously being drawn it may be difficult to see the gap. This is why I just have to get my logic analyzer finished! > I'm not disappointed. I was interesetd in how to solve the problem in > a general enough way that it would still work if the assumptions were > not met. I was assuming sequence, but also leaving open the > possiblity for some overlap. > - dan michaels > www.oricomtech.com > =====================

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: Re: R/C Receiver Interface KISS - Robert Rolf - Feb 4 20:17:00 2005

>>I'm not disappointed. I was interesetd in how to solve the problem > in a general enough way that it would still work if the assumptions > were not met. I was assuming sequence, but also leaving open the >>possiblity for some overlap. Then assuming the worst case, you need to add a multiplexer that would allow you select each pulse source in turn. A 4051 would work well, give you eight channels and is readily available. Y output to CCP pin, ABC to whatever 3 output pins you have to spare as channel selects. You read the pulse width on a channel, change the channel and then measure the pulse width on the next one. (remember to NOT measure a pulse if it is high immediately after a channel change ) The down side is that you would only measure a given channel every 1/n pulses but with slow servos, this many not be an issue. Robert

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - bergweed - Feb 5 9:37:00 2005

One easy way to see the actual gap would be to put all the channels on the transmitter to maximum pulse width (about 2 mS each) depending on polarity, you'll see a high or low going transition between each channel. The only possible exception would be the newer digital transmitters. I'm not up on how they work, but assume it's data vs older PWM. Mike B

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - bazling - Feb 5 10:02:00 2005

--- In , "rtstofer" <rstofer@p...> wrote: > > --- In , "dan michaels" <dan@o...> wrote: > > > > --- In , "bazling" <Barry@k...> wrote: > > > > > > --- In , "dan michaels" <dan@o...> wrote: > > > > > > > > --- In , Robert Rolf <robert.rolf@u...> > > > wrote: > > > > > Unless things have changed significantly, the R/C world still > > > > > transmits servo pulse widths as a serial stream of PWM, where > > > > > each pulse is 0.5 to 2.0 msec or so, and separated by 0.5 > msec, > > > > > give or take a bit. The long time interval between the last > > > > > pulse and the frame time (>5 msec) resets the receiver > > > > > multiplexer. > > > > > > > > > > There is no need to handle all the servo signals in parallel > > > > > since the receiver usually just demultiplexes > > > > > the pulse stream and ships it out sequentially among the > > > > > available channels. > > > > > > > > > > > > > > > > > Yeah, the problem is a lot easier if you are "gauranteed" that > > all > > > > pulses go in sequence, and there is no overlap and at least a > bit > > > of > > > > space between successive pulses. Someone mentioned that this > > might > > > > not always be the case. Is it guaranteed ????? > > > > > > Just jumping in here: > > > At the risk of disappointing you... > > > In my experience - yes they are in sequence, but NO, I cannot > > > measure any space between the pulses from the RC receiver > > > consequtive channel outputs - using 50MHz 'scope. > > > > There must be a gap. Otherwise how could the receiver distinguish > between pulses. Futaba has said that there is a 500 uS gap in the > transmitted signal and I would certainly start looking in that > direction. There would be no reason for the receiver to retime the > signals before demultiplexing. I could see some reason to retime > after demultiplexing so that all servos are synchronized but I > wouldn't expect to see anyone actually do that. > > If you set your scope to 2 mS per division to see then entire string > of pulses the gap would be 1/4 division. However, since the signal > is continuously being drawn it may be difficult to see the gap. > > This is why I just have to get my logic analyzer finished! > I appreciate your disbelief, that's why I did not want to disappoint you! However, let me say, my scope set to 0.05us per division does NOT show a gap between channels - using dual channel (chop or alt) to align the end of CH1 & start of CH2 I live with this by reminding my self that this is LEAVING the receiver AFTER the receiver has done the work of "distinguish between pulses" so does not need gaps any more. Also PICs are logical step by step processors, not immediate. Whereas discrete logic happens immediately at all points (to all intents & purposes)

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: Re: R/C Receiver Interface KISS - Robert Rolf - Feb 5 18:51:00 2005

> I appreciate your disbelief, that's why I did not want to disappoint > you! > However, let me say, my scope set to 0.05us per division does NOT > show a gap between channels - using dual channel (chop or alt) to > align the end of CH1 & start of CH2 Ah yes, but what triggering mode did you use? You would have had to use either CH1 or CH2 trigger and NOT alt triggering. If you used "Norm" on a Tek scope the trigger source would be changed with each sweep (alt) or whichever came first (chop) and in both cases the sweeps would APPEAR to be aligned in time, but in fact they would not be, particularly at the high sweep rates you reported using where you eye could not possibly distinguish a single chopped sweep from two sweeps. It is quite likely that you did not see the baseline under the CH2 pulse if you were in chop mode and using a high sweep rate. Single sweep mode, with chop, with repeated reset would show you if the pulses were indeed synchronized. Use CH1 trigger, chop mode, and a slowish 0.5 msec/div sweep to see if the pulses truly ARE aligned in time. I am 95% certain that they will NOT be. IF they are, please tell use what receiver is being used so we learn something new. > I live with this by reminding my self that this is LEAVING the > receiver AFTER the receiver has done the work of > "distinguish between pulses" so does not need gaps any more. So why would the receiver bother to align the pulses? It is much simpler to just fire off the pulses as they are serially received. Even a digital transmitter, where PCM data bytes are sent instead of PWM would have to decode the bytes sequentially so there would LIKELY be some separation in the pulse start times, unless the software was resyncing them to have a common start time, which is possible. This has a BIG disadvantage in that this introduces a minimum 20msec delay in responding to control inputs, not something an R/C flyer would want. > Also PICs are logical step by step processors, not immediate. > Whereas discrete logic happens immediately at all points (to all > intents & purposes). Yes, but you DO NOT have the DATA available immediately and simultaneously since it MUST be transmitted serially over a SINGLE RF channel. If the pulses are indeed starting simultaneously, then a damn fast scan (loop) of the N channels could be done since one does not have more than 2 channels of CCP on a PIC. Robert

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - bazling - Feb 6 5:43:00 2005

--- In , Robert Rolf <robert.rolf@u...> wrote: > > I appreciate your disbelief, that's why I did not want to disappoint > > you! > > However, let me say, my scope set to 0.05us per division does NOT > > show a gap between channels - using dual channel (chop or alt) to > > align the end of CH1 & start of CH2 > > Ah yes, but what triggering mode did you use? You would have > had to use either CH1 or CH2 trigger and NOT alt triggering. > If you used "Norm" on a Tek scope the trigger source would > be changed with each sweep (alt) or whichever came first > (chop) and in both cases the sweeps would APPEAR to be aligned > in time, but in fact they would not be, particularly at > the high sweep rates you reported using where you eye could > not possibly distinguish a single chopped sweep from two > sweeps. > It is quite likely that you did not see the baseline > under the CH2 pulse if you were in chop mode and using a high > sweep rate. Single sweep mode, with chop, with repeated reset > would show you if the pulses were indeed synchronized. > > Use CH1 trigger, chop mode, and a slowish 0.5 msec/div > sweep to see if the pulses truly ARE aligned in time. > I am 95% certain that they will NOT be. IF they are, > please tell use what receiver is being used so we > learn something new. > > > I live with this by reminding my self that this is LEAVING the > > receiver AFTER the receiver has done the work of > > "distinguish between pulses" so does not need gaps any more. > > So why would the receiver bother to align the pulses? > It is much simpler to just fire off the pulses as they > are serially received. Even a digital transmitter, where > PCM data bytes are sent instead of PWM would have to > decode the bytes sequentially so there would LIKELY be > some separation in the pulse start times, unless the > software was resyncing them to have a common start time, > which is possible. > This has a BIG disadvantage in that this introduces a minimum > 20msec delay in responding to control inputs, not something > an R/C flyer would want. > > > Also PICs are logical step by step processors, not immediate. > > Whereas discrete logic happens immediately at all points (to all > > intents & purposes). > > Yes, but you DO NOT have the DATA available immediately > and simultaneously since it MUST be transmitted serially > over a SINGLE RF channel. > > If the pulses are indeed starting simultaneously, then > a damn fast scan (loop) of the N channels could be done since > one does not have more than 2 channels of CCP on a PIC. > > Robert I agree with what you say and am aware that of the trigger used could mask the difference. I did not say the pulses are "starting simultaneously", I said "to align the end of CH1 & start of CH2" i.e they are consecutive without any discernible gap. As it has been a year or 2 since I discovered this, I have just tested again in case my advancing years are causing brain problems! Still the same result. Checked with Futaba Skysport 6 and R147f receiver Surely there is someone else out there with a 'scope to give further input to this discussion? Barry

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: R/C Receiver Interface KISS - dan michaels - Feb 6 13:00:00 2005

--- In , "bazling" <Barry@k...> wrote: > > I agree with what you say and am aware that of the trigger used > could mask the difference. > I did not say the pulses are "starting simultaneously", I said "to > align the end of CH1 & start of CH2" i.e they are consecutive > without any discernible gap. > > As it has been a year or 2 since I discovered this, I have just > tested again in case my advancing years are causing brain problems! > Still the same result. > Checked with Futaba Skysport 6 and R147f receiver > Surely there is someone else out there with a 'scope to give further > input to this discussion? > Barry One suspects that each given transmitter-receiver pair might give at least slightly different results. In some cases there may be less/more of a gap than in others. Therefore, it comes back to my original comment about making as few assumptions as possible and writing the PIC software to be able to handle the general case, which would be little or no gap. Then, if there is no gap or even some overlap, the software is less likely to crash. If you could run every pulse into its own interrupt pin, that would help the general case, but just the same, servicing interrupts on a 20-mhz PIC still requires upwards to 15+ clocks of overhead alone, so your accuracy is still only on the order of 4-usec or so. One trick I have used for dealing with the issue of overlapping interrupts is to pass through the check of interrupt flags at least twice when inside the ISR. This way, if another flag gets set while you're processing the first flag, then you can catch it too. - dan michaels www.oricomtech.com =======================

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Re: Re: R/C Receiver Interface KISS - Robert Rolf - Feb 6 14:15:00 2005

bazling wrote: > I agree with what you say and am aware that of the trigger used > could mask the difference. > I did not say the pulses are "starting simultaneously", I said "to > align the end of CH1 & start of CH2" i.e they are consecutive > without any discernible gap. Interesting. That does suggest that the pulses are being generated in software using a 'move to port' instruction to change the bits. You'd need nsec resolution to see any skew in the bit change. So with TWO CCP channels, one having the odd servo channels wire or'd and the second having the even channels, my previous suggestion would still work since you would have the period of the intervening channel to process the measurement on alternating CCP interrupts. > As it has been a year or 2 since I discovered this, I have just > tested again in case my advancing years are causing brain problems! > Still the same result. OK. Thanks for taking the time to do this. Most interesting and unexpected. > Checked with Futaba Skysport 6 and R147f receiver > Surely there is someone else out there with a 'scope to give further > input to this discussion? http://staffi.lboro.ac.uk/~copal/pal/play/radio_control/futaba.htm clearly shows that the transmitter is producing a 'normal' pulse train. So this suggests that the receiver is buffering the pulses before outputing them, causing additional delay in the process of reading an input, transmitting it, then outputting to the servo. It's not much, but good musicians can detect the delay in a MIDI transmit and echo back (2 character times @ 31.25 kbaud). Robert

(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )