Hardware logic in Propeller ... design contest...

OzStamp

Hi to all··

Got a little customer project that requires some high speed logic to sync itself to
a signal from a machine.
Presently this is implemented in std logic gates and works well.
The final output from the 3 input AND GATE triggers a ONE SHOT circuit
that operates for 10msec...( this is to be added later as well).
High accuracy is needed so thought the Propeller can do this ....

Please read the attached docs and see the schematic as to how I see it
what needs to be implemented..

The Propeller already does another task and thought wooow it would be
really cool if we could implement this as well and get rid of another small PCB as well
that is already there but looks very old... since we have plenty of I/O pins
and some COGS to spare.

I have had a good stab at this myself and it is not a trivial task ..
The 100% solution to the objective does not stare me in the face.
Have tried waitpeq commands and waitpne combo bit it seems to hang on those
instructions as th enable is the master signal....

Not asking for a complete solution here but thought I share the project
and see if anybody has attempted something similar like this.
A $3.00 CPLD will do it as well and also a handfull of other stuff but thought
lets see if we can make it all happen it the Propeller.

Anybody that comes up with a good solution will be rewarded .
We can hardware via Parallax USA or via one of its disties around the world.

Ronald Nollet··· Australia··· (Parallax OZ disty)

CJ

is there any timing constraints? how tight does the pulse have to be in regards to cam?
also, how close to the falling edge of enable does it have to be if enable goes low during cam?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

OzStamp

Hi CJ

It needs to be as quick as possible we have 28msec to do a task that needs all the time it can get..
so a 1-2 msec delay is way too long.

cheers
Ronald Nollet

CJ

I was worrying about it needing to be less than, say 10uS, as my code isn't as efficient as it could be and I don't know the speed you're working with

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

OzStamp

Hi CJ

The speed of operation is pretty well defined in the txt file.
The cam signal is on for 28 msec and off for 28msec (both 0.028 secs)
as soon as the cam signal is high ( once synced properly via the first high too low catch transition)
we need to act on the high going edge of the CAM signal as quick as possible.
As we have a full 28milliseconds (CAM High + ENABLE high) to do a task that could take 23-24 milliseconds...
So as you will appreciate we do not have much time to play with at all.

Cheers
Ronald Nollet

CJ

I think I got it!

from what I can tell, the maximum overshoot when enable goes low is about 24 clocks, or .25uS at 80Mhz

if anyone spots any bugs, please let me know so I can learn from them(not sure with a program this small)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

OzStamp

Hi All

Hereby attached an updated schematic

Added the timing mudmap ·of it as well just to make sure we understand each other correctly.

Cheers

Ronald Nollet

hinv

So let me see if I understand your correctly.
Once enable is high, you want to jump to a subroutine on every rising edge of cam.
The subroutine will finish in less than 28ms right?

Do you want the subroutine "interupted" if enable goes low?


Thanks,
Doug

OzStamp

Hi Doug.
Pretty well the way it is

My new timing diagram attached above ...
See it for further clarification..
The enable is the master on/off ..
I should have added that possible scenario to the timing mudmap as well..
My just do that right now as well.
Ronald

OzStamp

Hi Doug

Attached the latest timimg mudmap senario just to again clarify that my schematic

is understood correctly it shows that the enable is the absolute master on/off.

It is of paramount importance that the enable turns the output off as quick as possible

(if it was on that is..)·

Cheers
Ronald Nollet

Mike Green

This is implementable with a simple state machine. If I/O pin 0 is CAM and I/O pin 1 is ENA. The off state is the initial state. There's a transition to the on state when CAM is low and ENA is high. There's a transition back to the off state when ENA is low. If CAM is high and ENA is high in the on state, the monostable is triggered. In assembly, this would be:

PUB startup
   maxTime := clkfreq / 100           ' 10ms 
   cognew(@initialize,0)
   repeat                                        ' Do something else

DAT
initialize      mov  outa,#%000       ' Initialize output to low
                  mov  dira,#%100
offState      andn outa,#%100       ' Turn off output in off state
                  mov  monoEna,#0       '  and disable monostable
                  mov  temp,ina
                  and   temp,#%011      ' Copy inputs to Z and C flags
                  shr    temp,#1  wz,wc
  if_c_or_z  jmp   #offState            ' Stay in off state until /CAM,ENA
onState      tjz     monoEna,#monoOff
                  mov  temp,cnt            ' Compute elapsed time
                  sub   temp,time
                  cmp  temp,maxTime  wc  ' Is greater than 10ms?
  if_c           jmp  #monoOff
                  andn outa,#%100     ' If so, turn off output
                  mov  monoEna,#0     '  and disable timer
monoOff     mov  temp,ina
                  and   temp,#%011     ' Copy inputs to Z and C flags
                  shr    temp,#1  wz,wc
  if_z           jmp   #offState           ' Stay in on state until /ENA
  if_nc         jmp   #onState
                  or      outa,#%100      ' In on state, if ENA and CAM
                  mov  time,cnt             '  then begin 10ms pulse
                  add   time,maxTime
                  mov  monoEna,#1
                  jmp   #onState
maxTime    long   8000                 ' Compute this in Spin for 10ms
temp          res     1
time           res     1
monoEna   res      1

I think that, with a system clock of 80MHz, the longest path for any state is on the order of 1us.

Post Edited (Mike Green) : 3/8/2007 3:42:35 AM GMT

hinv

I think CJ has it nailed.

But, the oneshot(for 10ms) can be run right from the code in the same cog as well as it would be very simple.
I wouldn't start yet another cog do to the oneshot unless the out signal from your diagram went somewhere else also.

Do you have the code that does the oneshot?
Is it just a single 10ms pulse? You mentioned that you needed 23 to 24ms to do a task.

Doug

Mike Green

I just noticed that my routine doesn't do the one-shot properly. It does reset the monostable if ENA goes low which I intended, but may not be what is wanted. Unfortunately, it also extends the pulse as long as the starting condition is true. This really needs 3 states, one for off, one for on, and one for on once the monostable is triggered. It just needs a 3rd loop near the end for this.

OzStamp

Hi All

Attached my latest version that seems to work
Tested with an external pulse and a Pushbutton on my ProDEV board using a USB PropStick.
Special thanks to Mike Green and CJ ( just got your PM CJ)
Your submissions certainly were close and gave me enough detail to sort this..
so here it is ..
Don't you love those wz and nr instructions .. awesome..

Still need to hack into the waitcnt routine (want to cut it short it is needed) if the
enable goes low while out0 is high..

Ronald Nollet Australia

CJ

I think you may have to replace the waitcnt with a tight loop to check enable and cnt and exit if enable goes low or cnt rolls to the proper time
the enable check/exit is cake, however I don't know how to handle the CNT check without running into a rollover bug, anyone have an Idea?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.