Re: Learning PIC on the job

Nick,

I have been attempting a similiar project, connecting a robot to a PC.
My results have not been spectacular and had dropped the idea due to
lack of forward progress. Please post progress reports. I should
revisit my prior project.

In summary:

    CPU:                pic16f628
    RADIO:            ABACOM AD_RTD_315
    PROTOCOL:    Software encoded/decoded Manchester
    BAUD:              5K bits/sec (max)

I have redesigned the board to change to a pic18f1320 for greater speed
and
easier to use data duffers.

All work was done using GNU tools: GPUTILS & gEDA.

George

On Sat, 2005-08-06 at 12:15 +0100, Nicholas Robinson wrote:

> Hi
> 
> Thanks for the email and advice.
> 
> I'll try out gpsim as you suggest.
> 
> I haven't done anything so far, let alone blink a led!
> 
> I'm fairly relaxed about the design of the software - it seems to have a lot 
> of similarities with a food tasting panel application I wrote some years ago 
> with multiple independent slaves, etc. It's the extent to which I need to 
> know about the RF aspects - or can you just assume the PIC components are 
> black boxes that talk to each other?
> 
> I'd wondered about using 18FXXXX simply because they seem to do everything 
> except the RF, but then wondered if the rfPIC12 series would do what I want, 
> but could it handle the master requirement? Or should I use the 18F1220 
> interfaced to a rfPIC12F675K for the master with individual rfPIC12F675K at 
> the slaves?
> 
> Or would I be better with DLP-RF1 or RF2 combination 2 2.4GHz Transceiver from 
> DLP Design? This is superficially a bit pricey compared to the PIC solutions 
> but by the time I've added it all up it might not be.
> 
> Thanks
> 
> Nick
> 
> On Saturday 06 August 2005 09:06, Peter Onion wrote:
> > On Sat, 2005-08-06 at 08:37 +0100, Nicholas Robinson wrote:
> > > Hi
> > >
> > > I'm completely new to PIC.
> >
> > We all were once :-)
> >
> > > I would be really grateful for some pointers as to
> > > which technologies/devices I should use so that I can target my learning
> > > towards my goal!
> >
> > Have you looked at the liclist site ? And subscribed to that list as
> > well ?  It has a wider scope than this list and I think it includes more
> > electronics engineers than this list.
> >
> > > The controlling application resides on a Linux notebook PC (or PDA???)
> > > using C++/Qt with a wired connection to a master PIC-based device.
> >
> > I'm just doing something similar, but with C/Gtk+
> >
> > [SNIP system description]
> >
> > > Any suggestions as to the best way to take this forward for someone based
> > > in the UK in terms of programmers/test kits, etc. would be most helpful.
> >
> > UK suppliers I've used for PIC stuff:  Crownhill Associates, Rapid
> > Electronics.  Crownhill have some modules that may be useful for
> > learning (PIC based WiFi web server for example).
> >
> > I don't want to put you off, but by anyones standards what you have
> > described is a really quite complex pic project !  My advice, take some
> > time to "play" with some simple pic circuits first.  Have you "blinked a
> > led" yet ?
> >
> > You can start to experiment with pic programming before you even get any
> > hardware together by using gpsim.   gputils plus gpsim will let you
> > start to get the feel for things.
> >
> > Even if you end up using a high level language like C (I'm playing with
> > sdcc at the moment but other high level languages are available ;-) ) I
> > would make the effort to at least learn the basics of assembly language
> > programming.  It WILL help when things don't do what you expect.
> >
> > I would also suggest that since you have no "legacy code/hardware" to
> > worry about that you look at the 16 bit 18FXXXX series devices.
> >
> > > I have tried to make some guesses but I'd probably only embarrass myself
> > > if I included them here!
> >
> > Well your guesses would at least give us an idea of your level of
> > knowledge, for example if you use all the right words etc ;-)
> >
> >
> >
> > Peter
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
>