Mcp3202

John Abshier

Ken Gracey posted an object http://obex.parallax.com/objects/515/ for the MCP3202. His demo program works, but only because he used P0 as the clock pin. It also appears to me that the assembly part of the driver is expecting 5 parameters and the Spin part only sets up 4. Attached is my modification to Chip Gracey's driver with three demo programs. I used the Propeller Professional Development board's pots for input to the MCP3202 and its LEDs to test the DAC part of the driver.

I ask that someone please test/review the attached object. If there is positive feedback, I will ask Ken to replace the object in the OBEX with this one.

John Abshier

kuroneko

Looks like the MCP3202 driver has been derived from the MCP3208 (PropTool library) and broken in the process. In the latter, the ins array is also used as temporary parameter storage (to keep stack values alive until PASM grabs them). This means it has to be 4 longs in size to cover pins(3) and mode(1) without affecting count & Co. If it were me I'd simply re-instate the array and adjust the code to upset frqx, i.e. (untested, no h/w)

VAR

  long  cog

  long  ins[COLOR="#FF0000"][4][/COLOR]          ' [COLOR="#FF0000"]7[/COLOR] contiguous longs ([COLOR="#FF0000"]8[/COLOR] words + 1 long + 2 longs)
  long  count
  long  dacx, dacy

and

mov     t4,par                  ' update DACs between clock transitions
                        add     t4,#[COLOR="#FF0000"]20[/COLOR]                  ' [COLOR="#FF0000"]@dacx[/COLOR]
                        rdlong  frqa,t4
                        add     t4,#4                   ' [COLOR="#FF0000"]@dacy[/COLOR]
                        rdlong  frqb,t4

Edit: Addtionally count update would have to be adjusted (it's hardwired to follow par by channels words).

Ken Gracey

Thanks Mr. Abshier - I'll monitor this thread and replace that object whenever the time is right.

I think that's my only object on OBEX and at least I'm glad to have it be a point of discussion and improvement.

kuroneko

@John: Your current version has several issues (hence my suggestion in post #2). By copying 6 longs in startx methods start and start1 have their pin assignments replaced with stack values (X+Y and Y). It would be better to just copy 4 longs as before. However, this still gives dacx and dacy unwanted values, spin and mode respectively (low enough to not have any obvious effect but ...).

As for not being able to use P0 for the DAC output(s), you could either use a negative value or anything greater 31 (instead of 0) to indicate unused (similar to like it's been done originally by setting bits 7/15 meaning valid). Removing functionality (i.e. being able to use pin 0) doesn't seem like a good idea. That said, passing 32 would be recognised as 0 ATM but that's just ugly.

John Abshier

Kuroneko, thanks for looking. I have tried to avoid assemby programming since a bad experience with a RCA mainframe in the early 1970s, but get forced into it from time to time. I am traveling right now and will try to incorporate you comments when I return home in a few days.

John Abshier

John Abshier

I've got to teach the grandkids not to share virsuses. Thanks to kuroneko for a some tips. I think the attached files are ready for release. I almost gave up. I was calling the start method and then immediately calling the one of the out methods to set DAC values. That did not allow enough time for the ADC/DAC cog to load and go through its initialization. I have made this error before and it is hard for me to find.

John Abshier

kuroneko

Some of the comments don't match the code (mainly pin numbers). Also, waiting a fraction of clkfreq is a bad idea, e.g. at 5MHz you'd only wait for 5k cycles and a cog needs 8K to start up. Yes, one could simply wait for 8K cycles but by that you effectively waste time. OTOH you could simply clear each parameter field once you read it and wait for DACpins to become zero (which would require the startx call from start to pass 1 as the second parameter, non-zero but invalid).

John Abshier

Kuroneko, thanks. I understand what you said in English in you reply. I tested you code and it works fine. What I don't understand is

wrlong par,t1 'acknowledge parameter

It appears that as a source par contains an address in hub memory, but as a destination par contains 0.

John Abshier

John Abshier

Ken, I think it is done. Kuroneko deserves most of the credit.

John Abshier

Daniel Harris

<hijack>
This thread highlights the need for an open repository where others can contribute to an object's development.
</hijack>

kuroneko

John Abshier wrote: »

What I don't understand is

wrlong par,t1 'acknowledge parameter

It appears that as a source par contains an address in hub memory, but as a destination par contains 0.

Yes, par & Co have a shadow twin when used in the destination slot of an insn which by default is cleared (so unless I find myself under special circumstances par is aliased to zero for tasks like this). I used a similar effect (shadow[phsx] vs counter[phsx]) for the [thread=129719]initial hub-to-cog transfer[/thread] but this has since been superseded.

Anyway, usually you'll find stuff like this

wrlong  zero, addr

zero    long    0

Use what works for you.

Ken Gracey

Thanks kuroneko and John Abshier. I've uploaded your new demo and replaced the one I had at http://obex.parallax.com/objects/515/

BrainStrain

Thank you, Gentlemen, for updating the MCP3202 driver, and your perfect timing in doing so.

I'm right in the middle of learning how to program... and just about have figured out how to get output from the Parallax joy stick to do something useful, such as turn LEDs on at the moment. Let's hope I can figure out how to pass the CH0 X, and CH1 Y values into variables in my new spin object by tomorrow, mabye.

Ken Gracey

BrainStrain wrote: »

Thank you, Gentlemen, for updating the MCP3202 driver, and your perfect timing in doing so.

I'm right in the middle of learning how to program... and just about have figured out how to get output from the Parallax joy stick to do something useful, such as turn LEDs on at the moment. Let's hope I can figure out how to pass the CH0 X, and CH1 Y values into variables in my new spin object by tomorrow, mabye.

Way to go, BrainStrain. Feel free to ask around if you feel like you need help.

And welcome to the forums, too!

Ken Gracey

Ttailspin

Sorry, I am a little late to the party, but I have been swamped with work stuff...

Thanks for reworking the MCP3202 code, I wondered why I could only use P0..P2.

Added this little schematic to the demos...

I think they are correct, not the most profesional, but they do the trick.
Now I will try to use more of the LEDs on the PPDB, or do some kind of cool display with the 16 segment displays.

Anyways, thanks again for fixing the code.


-Tommy