PWM Conversion to "________" <---- Insert data

Eddie, Robot dude.

Thanks,

I’m not an electronics wiz but there has got to be a way of converting pwm signals from rc transmitters into a usable format that is somewhat easy to code with so we don’t run into situations where we have to use gobs of code to interpret the pwm signals…

It would be nice if there was a electronic circuit we could build that would do this, and convert it to something that the BB2 can get a numerical value from with the least amount of wasted cpu cycles.

–Aaron

Personally I’d go for a small CPLD with a 12-bit counter, 12-bit PI-SO shift register, and 8 channel mux to do the conversion. It would take maybe 4 wires from the controller to interface using an SPI style protocol. It’d be like 3 parts. :wink:

Sounds great :confused: , All you got to do is write the logic code for the CPLD to make it work?

Eddie … haha draw up a schematic and ill build it, but was thinking more of the lines of something really simple CPLD already sounds complicated… :slight_smile:

If I were to only have my stupid 50x servo extension wires I ordered off ebay about a month ago from china, I would be able to try all these methods to see if I can get away with using Kurte’s or Xans code on this issue, or at least make my own and see what happens with it.

By the way a bit off topic, how do you run code off the BB2 with the serial port linked to it to view live values or debug it?

Sure… straight forward enough in even the old HDL languages like CUPL or ABEL. Verilog and VHDL make my head hurt usually but then again I’m older so it’s probably the pain of thinking how to make the new fangled way of expressing logic do what I can do in only a few straight forward lines of the afore-mentioned HDLs. :smiley:

… OK you officially lost me…

Can ugh someone decode that for me ?

:open_mouth:

Wow , funny stuff…

ok a quick overview, although admittedly off topic so I’ll keep it sort of short.

Digital logic can be expressed as a form of mathematical equations. there are ICs called programmable logic devices (PLDs) that allow their output functions to be written in a programming language as a form of equations combining their input pins and feedback from their output pins. such a programming language is called a hardware description language (HDL). ABEL, CuPL, and PALASM are examples of early HDLs and their syntax resembled very closely the actual matematical equations used to represent the logic. Verilog and VHDL are examples of more modern HDLs and have a much more structured approach that resembles C more than straight equations. Verilog in partcular is used heavily both for coding devices as well as writing test procedures to validate the logic programmed to the devices.

The simplest PLDs were based on an array of fuses much like an EPROM and called PALs for programmable array logic. they had simple output functions like, for instance an or 8-input OR gate where each input was tied to an AND gate that could access every input pin to the device as well as a feedback from each output pin. the programmable part was which of the inputs to the AND gate were actually connected to a signal. there might be 8, 10, or 12 of these (OR + 8 AND) channels in a single package and upwards of 24 inputs depending on the device package size (i.e. number of pins available.) There were more options, the OR gate could drive a D-type flip-flop for making shift registers or state machines, or migh be replaced by an XOR gate to make building addition or CRC circuits simple. The next generation of these devices were called GALs, G for generic, as they replaced a single type of output with an output macrocell which had one or more registers and XOR gates or other specific logic functions which could be selected by programming… very flexible. The next generation is called complex programmable logic device, CPLD, and has multiple GAL devices in a single package which are, in addition to having a programmable array in each GAL, connected internally through yet another programmable fuse array that allows the different GALs to share input signals and pass outputs to other GALs. CPLDs can get quite large, I’ve used parts with as many as 16 GAL sections. Lattice and Xiinx are probably two of the biggest active CPLD developers but there are many others.

CPLD, GAL, PAL is implemented in silicon using EEPROM cell technology. therefore it has some of the same benefits as well as limitations. One of the biggest benefits is you turn on the power and it’s there… vs something called an FPGA (field programmable gate array) which is based on an SRAM cell and requires its arrays be re-loaded from a PROM device every time power is applied. This tends to make smaller CPLDs more cost effective than FPGAs with similar logic capability. Of the disadvantages of EEPROM cell are it’s slower and takes more transistors to implement when compared to SRAM… which is why very large FPGA devices are often comparable in cost to moderately large CPLDs. Many FPGA architectures are also considerably more flexible than the interconnected GAL sturcture of a CPLD. In the end you need to balance all of the factors of capability, complexity, re-programmability (FPGA are generally easier to manage in this regard), and cost when selecting a programmable logic device.

For the project you have been discussing, capturing lots of servo inputs efficiently into the BAP, I would probably lean towards a Lattice Mach 4 or Xilinx XC9500 series CPLD, with somewhere between 48 and 96 macrocells. This is like a $3-5 range part in USD.

Well… I said sort of short anyway. :unamused:

It has been a long long time for me since I had to look at a hardware description language. Probably back in the ice age at school. I think the language they used back then was AHPL, which was based on APL…

Thanks Eddie for the overview as you said you could probably make a cost effective way of offloading the work from the BAP. I am not sure that it would make it easier for non-hardware programmers to understand.
It would possibly have the added advantage of maybe using fewer of the BAPs IO pins.

quite right of course in it not being much of an at home type solution… really would need to be sold as a breakout PCB with programmed part installed.

ya know I wonder if there is an option there… one of those generic breakout footprint patterns like on a vectorboard or surfboard but on a SSC-32 / BB2 stackable footprint. Could run some through BatchPCB and find something similar for sale on sparkfun a couple months later. :stuck_out_tongue: :laughing: Sry, my bad. :smiling_imp: :smiley:

well 3-5 bucks aint bad!

Although I think programming one of these with the knowledge I have is probably going to be pretty challenging!

Although I’m kinda leaning more towards code :stuck_out_tongue:

how do you run code off the BB2 with the serial port linked to it to view live values off variables to debug??

Put this in your program.

serout s_out,i57600,[dec my_variable,13]

This will send whatever is in that variable to the DB9 so you can open a terminal window to see the results. Make sure the baud rate in the terminal connect is set the same.

Thanks Jim,

Is this feature in the atom pro software under debug?
I thought I saw something in the atom pro software that was for debugging… this the same kinda thing?

Or was the only way to do this was to use the Lynxterm software as you mentioned.

… Kinda tempted to get a small lcd for debug and mount it…somewhere…

–Aaron

There is also a debug mode, that you can compile the program in a special mode by clicking the Debug button. There are some special commands that only work in debug mode (debug, debugin). In this mode you can step through your program set breakpoints, view variables and the like. This works great some of the time. However if your program is a little more advanced and includes things like assembly language or interrupts or timing loops, etc, the debug mode causes the program to run different enough that you may not be able to debug your actual issue. That is where the serout S_OUT is very nice. I use this a lot. Likewise I quite often have serial LCDS connected to my bot and I use serouts to its IO port as well to output variable contents and the like.

Other times I use the LEDS on the BB2 to help me debug. If you are not sure if your code gets to a certain point, you can set it up to turn on one of the LEDS if the code gets there. On one program I ended up blinking a couple of the LEDS with the value (one led for 10s one for ones…).

So there are lots of ways debug.

Kurt

Hey thanks kurte,

I was going to try and write my own plusin command for this pwm conversion to I can understand the math and convert the pwm signal into usable numbers I tend to think the code I write is pretty simple … alt least when I did VB…

It’s also pretty tempting to order that logic analyzer you have from the website thing looks pretty legit and easy to use might consider buying that, I can see how you would use that to determine which inputs to read in what order on your receiver! quite handy

I find it quite tempting to order another bb2 and Atom pro just for experimenting rather then keep reloading the code on my Phoenix…

I might have to look into one of these serial lcds I wish there was a way to run the code by emulating the atom processor but do it over the serial cable and still able to use its input/output pins and all… ā€œOH WELLā€

I like your interesting ways of debugging code I assumed the led’s were not usable with the phoenix code because of those jumpers… I think I’m going to display which gate your currently on in binary with the A B C led’s that would help me quite a bit ā€œon xan’s ps2 code 1.3ā€

anyway GOOD ideas!

I keep ranting on and on about this silly pwm thing been talking about it 2 weeks and I still have not got my 50 150mm futaba ends I baught off ebay for 1.99 from china! ERRR should have bought 500 if I knew it was going to take this long hahaha SIGH…

Thank’s again kurte

  1. I never use debug for the reasons Kurt mentioned. Using the built in terminal works better for me.

  2. I never mentioned LynxTerm. The programming IDE has built in terminals that are at the bottom of the screen.

  3. Yes a serial LCD is another good way for getting info out of your running program.

You know you could have got these a lot faster and cheaper. :wink:

lynxmotion.com/Product.aspx? … egoryID=44
lynxmotion.com/Product.aspx? … egoryID=44
lynxmotion.com/Product.aspx? … egoryID=44
lynxmotion.com/Product.aspx? … egoryID=44

You are welcome.

Yes the logic analyzer helps out. For $150 mine works great. It does have it’s limitiations. For example it does not give me a live view. I say capture now and it captures the data and displays the results. It does have trigger settings so this is not all bad. Also it only has 8 inputs, which again for me gets me 99% there.

The LEDs work well for simple logic testing. You can still use them with the PS2 connected, by first removing the PS2 jumpers (you probably should have anyway to make it more likely that the PS2 worked. You then use a 3 pin (or 1 or 2…) jumper cable and jumper lets say the IO pins 4-6 to the LED sides of where the ps2 jumpers were. Then you can now use IO pins 4-6 to use the LEDS and buttons…

As for jumper wires I think each 2 or 3 pin jumper wire is less than $2 from Lynxmotion and you can also buy a kit that allows you to crimp your own for $23 as well. And yes it is very handly to have a spare board and processor to experiment on without having to tear appart your bot…

Good Luck
Kurt

Jim, Kurte,

I bought 50x 150mm servo ends for 1.99 :stuck_out_tongue: so no not cheaper…

As for your logic analyzer Live view would be very handy atleast for monitoring pulse widths without scrolling endlessly… ā€œmaybe they will fix that in the futureā€

as for crimping I was just going to solder the ends together and heat shrink them all, I wont be doing 50 of them but around 8 - 16 of them so no big deal.

I’ll fiddle around with using those led’s I have a good idea how to jump the connections it seems pretty straight forward.

–Aaron

if you are actually saying you bought (50) count of 6" long servo ends for a total of $2… good luck with that and I hope they don’t fall apart in your hands or melt apart when you stall a servo and have to supply more than a few hundred mA. :frowning:

Hey direct from china :stuck_out_tongue: why not Its not like they are made out of 50 gauge wire and thinner then a human hair, and yes 50 count… i could have spent 12 bucks and got 500 of them :stuck_out_tongue:

plus everything’s made in china anyway

Just twiddling my silly thumbs waiting for them to arrive in the mail! this is horrible.