ina[?|

rjo__ · 2014-11-04 13:17

I was fiddling around with my DE2_115/ D5M/P1v. Everything was going swimmingly until I tried to control a P1v pin with a D5M signal through a register and a wire... my first:)

In short, I was expecting a signal to be read at a P1v pin through a Spin command... such as "temp:=ina[mypin]"

ina[mypin] always reads 1.

Thinking that it was me... I started to trace back through my various incantations of the P1v... until I got all the way back to Chip's original.pof file, released on 8/11... and it has the same issue. Boooooooo!!!!

I suspect that tying the pin to ground through a resister is required... but why? and which resister. At last count, I had 52,001 resistors ... but only three where I am right now. These were being used as pullups on something... so probably 1k to 5k(no meter here either and since I am working from a single candle I can't see the little buggers well enough to decode them; no combination of serial or parallel configuration would work... but I got a good laugh out of it:)

???

Seairth · 2014-11-04 17:46

You were reading a "1" even when the pin was tied to ground (without a resistor)?

No other cog has that pin set to a high output?

Do you get the same results in assembler?

rjo__ · 2014-11-04 18:04

Good point...Spin only using PropellerIDE didn't try it in assembler.

Ran the same code on my life-time-guaranteed Propeller Bored of Edication ... and it ran fine.

Will have to try it tomorrow... don't have my "toys" with me tonight:)

ozpropdev · 2014-11-04 18:12

Rich
What pin are you using? Is it a custom assignment or from the DE2 CD assignments?

pik33 · 2014-11-04 21:36

What is your Quartus setting for unused pins? Default is with pullup, so you will always read 1 on floating pin.

Short the pin to the ground, then read ina. If you don't find any zero, check block file naming in Quartus settings, it is a mother of all stupid problems with bad assigned pins.

rjo__ · 2014-11-05 06:18

Good morning!

This morning, I repeated what I did at the very end yesterday.

Start Quartus.

Do not select a project.

Start Programmer...

Select Add New File ->P8X32A_DE2_115.pof
This file is from the original download from Chip. This has a date modified = 8/11/2014 ... so it has to be the original.

I set the hardware as usual...Active Serial, USB-Blaster and then selected "Start."

This was successful and I then change the switch on the DE2-115 from prog->run, cycled the power and ran this code from PropellerIDE:...

CON 
  _clkmode = xtal1+pll16x
  _clkfreq = 80_000_000

OBJ ser : "FullDuplexSerial"
  
pub main  | temp
  ser.start(31,30,0,115200)
  waitcnt(clkfreq + cnt)
  dira[2]:=0
  temp:=ina[2] 
  ser.Dec(temp)
  SER.Tx(13)
  ser.Bin(INA, 8)
  SER.Tx(13)
  repeat

On a regular P1 board the output was fine:
0
00000000

On the P1v it is:
1
11111111

I shorted one of the pins to ground and then re-ran the code... did not change.

In summary... I didn't use quartus... I used only the Programmer. I used the original design file (.pof) from Chip.
I know that the DE2_115 GPIO works because the D5M camera uses the same GPIO as the unmodified P1v and the camera functions normally.

Seairth · 2014-11-05 08:12

rjo__ wrote: »
ser.start(31,30,0,115200)

So we know that pin 30 is working, at least. Maybe add some code to echo data received on pin 31.

rjo__ · 2014-11-05 12:53

Trying to zero in on this... mixed results.
Just to restate the problem... for unused pins, the value of INA should be all zeroes.
However, when I use Altera's Programmer to load the .pof from the 8/11/14 release, the values are all ones...
except for pin 30, which is in use and which is occasionally zero.

The code below demonstrates that by first setting dira[..] to 1's and then setting dira[..] to zero's the subsequent values for INA are correct.

However after a fraction of a second the values return to all 1's when they should be all zero's(for pins 0..8).

CON 
  _clkmode = xtal1+pll16x
  _clkfreq = 80_000_000

OBJ ser : "FullDuplexSerial"
  
pub main  | temp,time1,time2
  ser.start(31,30,0,115200)
  waitcnt(clkfreq/2 + cnt)
 
  SER.Bin(INA,32)
  ser.str(string("  initial value of INA  ",13))
  SER.Tx(13)
  SER.Tx(13)
  ser.str(string("  Set dira as 1s then dira as 0s for pins 0..8 ",13,13))
  dira[0..8]:=%111111111
  dira[0..8]:=%000000000
  time1:=cnt
  ser.Bin(INA,32)
  ser.str(string("  Resulting INA correct for pins 0..8",13))
  SER.Tx(13)
  SER.Tx(13)
  ser.str(string("  count clocks until ina[0]=1  ",13))
  
  waitpeq(1,1,0)
  time2:=cnt
 
  time2:=time2-time1
  ser.Dec(time2)
  ser.str(string("  clocks  ",13,13))
  ser.Bin(INA,32)
  ser.str(string("  FINAL INA  ",13))

  SER.Tx(13)
  repeat

the output looks like this:

1011111111111111111111111111 initial value of INA

set dira as 1s and then set dira as 0s for pins 0..8

1011111111111111111000000000  Resulting INA correct for pins 0..8

count clocks until ina[0]==1
811824 clocks


1111111111111111111111111111 FINAL INA

I remember playing with Propeller pins... attaching very short lengths of wire to them to see how sensitive they are to environmental EMF's...They are incredibly sensitive.

I wonder if that has anything to do with this?

Rich

pik33 · 2014-11-06 03:26

I checked INA pins (17..8) connected to GPIO in my retromachine.

When I use my retromachine capabilities to check these pins:

dira[8..17]:=0
vga.poke($83000+36,ina)  ' lit red  leds according to ina

I have ina[17..8] = 0 - the leds are dark

However if run your code (modified to use pins 15..8 instead of 7..0) I got this

11001111110111111111111100001000  initial value of INA


  Set dira as 1s then dira as 0s for pins 0..8

11001111110111110000000001011000  Resulting INA correct for pins 0..8


  count clocks until ina[0]=1
2234256  clocks

11001111110111111111111100001000  FINAL INA

Something is wrong here. Port A works, I use it for many things in my project. Maybe there are something in fullduplexserial object which causes ina to change.

rjo__ · 2014-11-06 07:44

pik33...

It isn't FDS, because I have run code where the state of the pin(if incorrect) prevents fds from reporting... it gets hung up waiting for the right INA values.

1. I am wondering... since portA is tri-stated, is Quartus adding a weak pullup without our knowledge?

2. Even though the port looks like it shouldn't work... I brought a signal out from my camera( terasic d5m)... the frame valid signal...
to pin 88 on the Parallax AddOn board... I then jumpered this to pin0 and I could get the effective frame rate of the camera.

I have no idea what is going on here:) And I have run out of free time... won't be able to work on it much for the next 2 days.

Many regards.

rjo__ · 2014-11-06 08:16

I forgot...

Once the pins are in the correct state... they don't all go into the wrong state at once and the transitions look somewhat orderly...
they might be completely orderly... I was too tired at the time to pay perfect attention to this detail...

To see this you replace my wait for pin 0 to get to 1, with a repeat loop spitting out INA to FDS until ina[0] ==1 or for some number of repeats that gets you there.

So.... it looks like a decay process. RC? How do we get there from Verilog?
Or an electrostatic process... where the lengths of the physical wires determine the rate of decay?
Or our favorite whipping boy... Quartus:)

Or it could be that I am not an engineer and this is what we should expect from what we have done?

pik33 · 2014-11-06 08:25

There are Schottky diodes on these pins. They have some non infinite resistance and capacitance. There are unknown circuits inside the FPGA. So, if the pins are not connected and tristated, we can have all kind of things on them.

jac_goudsmit · 2014-11-06 09:05

rjo__ wrote: »

Just to restate the problem... for unused pins, the value of INA should be all zeroes.

Is this really true? I don't remember ever reading that anywhere. From my experience, I would expect that disconnected input pins would be HIGH, not LOW.

I haven't tried this but in the Quartus pin assignment editor, you can add "input termination" or "passive resistor" or "weak pull-up resistor" entries to pull inputs low or high. The NRES pin has a "weak pull-up resistor" entry in all Altera targets.

If you don't pull inputs low or high, because of the nature of CMOS, it will be whatever it was last set to, until you read it. The way I understand it, CMOS transistors basically draw so little current on the input and have such a high resistance when they're switched off, that what you read from an input transistor (if it has no pull-up or pull-down resistor) is basically the left-over electrons that were still in there from when you last connected it to an output (either by setting DIRA to 1 or by connecting something on the outside).

Whether I'm mistaken or not, I don't think there's anything different with the Verilog for the P1V compared to the P1 when it comes to inputs, you're just seeing side effects because you're not connecting anything to your inputs and expecting a different result from what you're getting. I don't even think there's a way to change this in Verilog because this has nothing to do with logic, it's a side effect of the technology that's used on the FPGA.

Either way, an important point is being made here: I think we should probably add "weak pull-up resistor" entries for all data pins so the inputs are high (not low and not "undefined" as they probably are now) whenever there's nothing attached to them. What do you guys think?

===Jac

jmg · 2014-11-06 15:55

jac_goudsmit wrote: »

Either way, an important point is being made here: I think we should probably add "weak pull-up resistor" entries for all data pins so the inputs are high (not low and not "undefined" as they probably are now) whenever there's nothing attached to them. What do you guys think?

Yes, of course all Configurable pins should be set to default to light pullup.
Floating pins on high speed logic is never a good idea, and can have effects that reach wider than the pins.
- and on a test bench, you really do not need more variables in the mix.

ina[?|

Comments