Re: PropIO improvements

[yoda <yo...@r2d2.org>]

Hi Andrew,

That sounds like a good idea and we can experiment with the second
prop on the current board and prove that the 2 propeller idea works.
I guess we can just cut the traces on the second propeller and jumper
them up to the proto area.

On the jumpers for P30 and P31 make sure they are cross over jumpers
ie  propeller 1 P30 -> propeller 2 P31 and propeller 1 P31 ->
propeller 2 P30.

BTW with a little different layout (rotate props 90 degrees and mount
resistors vertically)  would give a bigger proto area I think

On Jul 7, 9:28 pm, "Andrew Lynch" <lyn...@yahoo.com> wrote:
> Hi Dave!  At this point, I've got three fixes in the board.
>
> 1.  the VGA mount holes
> 2.  removed P13 interProp line
> 3.  fixed transistor footprints.
>
> I can easily add additional jumpers to allow P30 and P31 to interlink the
> Propellers and that is no problem.
>
> At this point though I am thinking just do these minor clean ups and tweak
> and just let the rest be as it is while the software catches up.  As it
> matures and the SBC V2 comes out then for the next round of PropIO boards
> start looking into these advanced features.
>
> I am also thinking more like what Max was saying.  The builders may be
> better served by splitting the PropIO into a "stable" board with VGA, PS/2
> keyboard, uSD, Ethernet, and USB host on a board.  Then make a new
> "developer" PropIO board with two Propellers with one dedicated to the ECB
> and the other completely unassigned for experimentation purposes except for
> the inter-Prop link.  Then get rid of the expansion mezzanine concept since
> the "developer" PropIO would have a lot of free space for builder expansion.
>
> Actually we could start on the second board pretty soon to hash out the
> development concepts since it would be basically a stripped down PropIO.
>
> The big advantage is that I can send the existing PropIO basically "as is"
> with minor changes to PCB manufacturing in the next weekend without major
> redesign cycle.  Then I can catch up on these other projects floating about.
>
> How does that sound for a plan?  Thanks and have a nice day!
>
> Andrew Lynch
>
> > -----Original Message-----
> > From: n8...@googlegroups.com [mailto:n8...@googlegroups.com] On Behalf Of
> > yoda
> > Sent: Wednesday, July 07, 2010 9:34 PM
> > To: N8VEM
> > Subject: [N8VEM: 7444] Re: PropIO improvements
>
> > Hi Andrew,
>
> > Let me try to answer some of the questions.
>
> > What I meant by SPI is there are a lot of devices that talk SPI that
> > we can hang off of the propeller as there is a good low level driver
> > for SPI which is used to actually communicate with the uSD now so we
> > could reuse that code.
>
> > On freeing up one of the address lines, I want to hold off on that for
> > the moment - I was actually wanting to use it for further addressing.
> > For the high speed communications port we still have available P30 and
> > P31 which are only used to load the initial programs into the
> > propeller's eeprom.  We can implement a set of jumpers that you remove
> > to program and then insert them when you are operational.  Ray
> > (cluso99) did the same thing on the triblade prop which worked very
> > well.  My fear if we go to a command and data port that the loop for
> > parsing the commands is going to get very long and that has to be in
> > PASM and would not be easy for the uninitiated to try to write code
> > for.  I am also thinking in the new scheme we might want to rearrange
> > some of the I/O so that some of it is on the second propeller (I have
> > to check but I think we are out of cogs on propeller 1 and we will
> > need to free at least one cog for inter prop communication)
>
> > Yes I think that object will work but I think there is actually a
> > better one around that is even faster and implements a command
> > protocol which we will want.
>
> > I don't think losing a separately addressable propeller is a bad thing
> > because in fact it will be addressable by sending command strings via
> > the first propeller (just a different communications path and probably
> > as fast)
>
> > Dave
>
> > On Jul 7, 7:31 pm, "Andrew Lynch" <lyn...@yahoo.com> wrote:
> > > Thanks Dave!  OK, I think I understand what you are saying and propose a
> > new
> > > course of action.
>
> > > First, I fixed the problem with the PCB footprints for the PNP
> > transistors
> > > Q1 and Q3.  They were reversed and now fixed.
>
> > > > -----Original Message-----
> > > > From: n8...@googlegroups.com [mailto:n8...@googlegroups.com] On Behalf
> > Of
> > > > yoda
> > > > Sent: Tuesday, July 06, 2010 9:31 PM
> > > > To: N8VEM
> > > > Subject: [N8VEM: 7423] Re: PropIO improvements
>
> > > > Hi Andrew,
>
> > > > Sounds interesting.  I would wait a little on the decision as there is
> > > > work on a different chip that has a full tcp/ip stack built in and
> > > > around the same price or cheaper.  It uses the same type of interface
> > > > and will be much simpler to program in the long run.  Also I have a
>
> > > [AJL>]
>
> > > OK, scratch the Ethernet mod and I'll just leave the existing
> > functionality.
> > > If builders want this functionality they can build a prototype and once
> > > demonstrated working I'll include it in a future Propeller ECB board.
>
> > > > couple of the sparkfun usb break out boards that use SPI as well.  I
> > > > think it would be interesting adding serial ports with a much smaller
> > > > footprint.  I think there are all kinds of opportunities here.  I
> > > > think we might want to be able to jumper one more address line in
> > > > where P13 is.  There are so many things we can hang off the propeller
> > > > that have SPI ports that can be useful we may run out of addressable
>
> > > [AJL>]
> > > SPI serial ports?  Do you mean SPI ports or serial ports driven by SPI?
> >  Do
> > > you have a link for an example?
>
> > > > ports to the propeller.  I guess the other thing is to have a command
> > > > port that selects what the data port(s) do.  It will be tricky to code
> > > > but I have been pretty successful in the PASM code to make things
> > > > happen.  I was surprised with the uSD port I was still faster than the
> > > > propeller could handle and had to insert the waitpeq into the stream
> > > > to wait on the chip select line.
>
> > > [AJL>]
>
> > > I think this is very important.  We should switch to a command port and
> > data
> > > port interface.  Then we would only require A0 to distinguish between
> > the
> > > command and data port.  That would free up P15 which we could use with
> > P13
> > > to form a high speed interPropeller communications link.
>
> > > Once we have a working interPropeller communications link then dedicate
> > the
> > > first Propeller to full time ECB bus interface.  The first Propeller
> > uses
> > > several pins to communicate with the ECB and another two to communicate
> > with
> > > the second Propeller.  It also handles the VGA, PS/2 keyboard, and the
> > uSD
> > > interface.  The second Propeller's IO pins would be mostly free for
> > > additional IO devices rather than spending 11 pins duplicating an
> > interface
> > > with the ECB.
>
> > > What we lose is separately addressable Propellers but gain a lot of IO
> > pins
> > > and also a high speed interPropeller communications link.  The good news
> > > about this approach is that it is mostly compatible with the existing
> > PropIO
> > > board.  We can jumper the pins between the Propellers for the
> > interPropeller
> > > communications link.  Then cut the traces on the second Propeller to
> > free
> > > them up from the ECB interface.
>
> > > Here is an example of fast inter-Propeller link.  I gather it uses only
> > a
> > > single pin each way but we may want to use a diode between the
> > Propellers to
> > > protect the transmitter from a HIGH-LOW mismatch and also dedicate
>
> > >http://obex.parallax.com/objects/546/
>
> > > Probably there are many ways to implement so this is just an example.
>
> > > > One suggestion might be is run a small batch with the current fixes
> > > > and let some of us play with some ideas on the second port before
> > > > doing a larger run.  I have not even populated the second chip yet so
> > > > I don't know if there are any problems there, though I would expect
> > > > not as it is such a simple interface.
>
> > > [AJL>]
>
> > > Yes, this is certainly possible and even easy to do.  I can export the
> > freed
> > > up pins to a dual row header for expansion to the prototyping area
> > and/or
> > > mezzanine.
>
> > > > Just some ideas - I am on vacation at end of this week for a few days
> > > > - when I get back will finish up some of the current code - found a
> > > > few bugs in the terminal driver that I want to fix and then I will
> > > > start playing with the second prop and finalizing a driver for CP/M 3
> > > > that will support two 512 MB drives (I have figured out how I want to
> > > > do the protocol for it - should only require less than 10 lines of
> > > > spin code change)
>
> > > > Dave
>
> > > [snip]
> > > [AJL>] That's great!  Enjoy your vacation and I look forward to your
> > return!
> > > Thanks and have a nice day!
>
> > > Andrew Lynch
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "N8VEM" group.
> > To post to this group, send email to n8...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > n8vem+un...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/n8vem?hl=en.