Simple Digital io

Technical Programming
#1

I see in the default code, in the User Initialization function, that digital_io_17 is set up as an unused output.

It is then set to 0.

I added a couple lines to set it to 1 then to 0 then to 1 then to 0:

rc_digout_17 = 0;
rc_digout_17 = 1;
rc_digout_17 = 0;
rc_digout_17 = 1;
rc_digout_17 = 0;

No other changes have been made to the 2007 default code.
I compiled, and downloaded to the rc.

I connected a Logic analyzer and expected to see the digital line toggle a few times at startup.

Instead it simply takes on the value of the last stament I entered (a ‘0’ in this example).

Doesn’t rc_digout_17 directly drive the io pin?

What am I missing here …

#2

Not quite directly. The values for all the PWM’s and digital io’s are only outputted to their respective pins after the Putdata(&txdata) statement. That’s why it’s at the end of Process_Data_From_Master_uP. :slight_smile:

#3

Those statements are executed almost instantaneously… 100us each, in fact. This is likely too quick for you to notice. If you’d like something you’ll be able to see, try putting the statement rc_digout_17 = !rc_digout_17; in your main user control loop, and that pin will toggle every 26.4ms, which is something you’ll actually be able to see.

#4

Both of these statements are incorrect. The digital I/Os on the RC are directly connected to the hardware pins. In the old PBASIC days, it was true that everything went through the master. This is not the case anymore. You should be able to toggle them as many times as you want and see the change. Are you sure you configured the pin for an output first?

Guys, please take the time to make sure the things you are saying are correct. Spreading misinformation like this is only going to further confuse people who are probably already overwhelmed.

#5

Ditto Dave’s post. The reason you’re not seeing it is that it’s toggling so fast at the startup. If you don’t have your O-Scope set up properly for triggering and compensation, then it’s probably just shooting by too fast to see.

For the record, here’s a selection of the pins off the user processor:
All Relay pins
All digital IOs
All Serial ports
All analog inputs
PWMs 13-16

Actually I think that’s it, but someone can correct me if I’m mistaken.

#6

Hi Guys,

The ‘putdata’ answer seems to be the way the system is behaving, but doesn’t seem right because ‘putdata’ is only executed in User_Initialization and Process_Data_From_Master_uP().

That means anything you do in the fast routine (process data from local IO) will only be updated every 26ms, so what is the point behind having a fast routnine?

It also doesn’t seem to follow the documentation (Control System Overview, Figure 1.1) which says:

Master uP
- PWMs 1-12
User Processor
- PWMs 13-16
- Analog
- Digital
- relay

I assumed that meant I had direct access/control over everything but PWMs 13-16 and had to do the ‘putdata’ to update PWMs 1-12 only.

I still feel like I am missing something simple here …

#7

My mistake; I apologize for the error and will try to be more careful from now on. I didn’t mean to cause any problems.

#8

In response to the “too fast to be seen replies” we are using a Logic Analyzer with 5 ns of resolution and a 150 MHz O-Scope - I feel very confident that that we’re not missing anything …

#9

There’s filter circuitry on the digital pins. It limits the rate at which the signal voltage can change. You’re trying to change it much more rapidly than it will physically respond.

#10

As Dave Flowerday pointed out, the problem is probably due to the RC filtering, but you may also want to double check that the I/O line is actually setup as an output. The default code in the User_Initialization() function does set user I/O 17 as an output, but if your code changed that to an input, it could account for the problem you are seeing.

In a separate discussion on using the I/O lines to build a SPI interface http://www.chiefdelphi.com/forums/showthread.php?t=49204, I calculated that when using user I/O lines 7-18, limiting the transition rates to about 140kHz would be appropriate. I/O lines 1-6 are less heavily filtered and could support transition rates up to about 1.45MHz.

Due to how the RC components are configured, the input transition rates would be about 40kHz and 300kHz respectively.

IFI’s I/O RC filtering schematic can be found here: http://www.ifirobotics.com/docs/analog-digital–i-o-rc.pdf.

#11

Hi Guys,

Everyone that said RC filtering gets the prize (find me at nationals and I’ll give it to you …)

I put the following code in to vary the width of the pulse I was sending out:

rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;

rc_digout_17 = 0;
rc_digout_17 = 1;

rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 1;
rc_digout_17 = 1;

rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;

rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;

rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 0;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;
rc_digout_17 = 1;

And guess what - Only the 1st and last pulse came out regularly, and sometimes I would get the next to last pulse.

Also - the 1st pulse was narrower than the last (even though they had the same code) - probably due to being the first one to charge up the RC circitry.

I then added a 4.7K pullup to the IO and can now see all but the narrowest pulse.

The schematic of the io pins predicts this behavior exactly - thanks!

Issue closed.

The world can start spinning on it’s axis again …

  • Rick