Subject:
Re: [gnupic] PIC under Linux developpement Howto
From:
Byron A Jeff ####@####.####
Date:
5 Jul 2005 23:25:03 +0100
Message-Id: <20050705222453.GA7194@cleon.cc.gatech.edu>
On Tue, Jul 05, 2005 at 03:08:35PM +1200, David McNab wrote:
> Christopher Bergeron wrote:
> > I'm going to have to second this one. However, there's a part of me
> > that thinks that having choices will be confusing to newbies.
>
> Well. in the light of all this reaction, allow me to amend my original
> suggestions:
>
> * C is most useful IMHO - more useful than dumbed-down high-level langs
> like BASIC, and less annoying for the newcomer than assembler, and
> easy to interface with assembler
>
> * another alternative is PyAstra - a cut-down Python to PIC assembler
> compiler - but Python scares many folks because whitespace is
> syntactically significant, so should probably stick with C instead
>
> * assembler is menial - justified only when performance or environment
> limitations necessitate it - you get way more functionality per litre
> of blood/sweat/tears when programming in higher level languages,
> because it's way easier to concentrate on the 'what' without being
> constantly distracted by the 'how' - basic stuff like parameter
> passing, data structures, and (in the 16F case) those damn fragmented
> program/data memory segments etc etc - C compilers spare the user of
> all that crap
The issue still stands that assembler has a much much wider spread usage
than anything else in thei venue. No matter how aggravating, menial, or
non abstracted assemlber is, it's the language that most PIC developers
use for projects. You simply cannot have meaningful converstations about
many tasks without knowing it.
I'm not saying that you have to stick with it. But to give maximum impact
to the greatest number of new users, they need to learn it first.
It may even be permissible to show a rosetta stone type translation between
assembler and a higher level language. But reading and writing PIC assembly
is an essential skill for anyone who wants to participate in the at large
PIC community. Any other language is going to limit the audience that you
can communicate with.
>
> * a howto should take the user, step by manageable and verifiable
> step, from a bag of parts and an internet connection through to a
> board with a blinking 'hello world' LED, and then through to other
> PIC stuff like ADC, PWM, USART etc - without them needing to spend
> a cent on anything other than hardware
That's fine with me. Showing a new user how to leverage the onboard hardware
is an essential item on my tutorial list.
> * I'd suggest sdcc - it's not the prettiest C compiler, but it can
> do the simple stuff, and it's speech/beer free, and available on
> all decent linux distros
Even Scott, who was the longtime primary developer of the PIC SDCC port, says
that it's not ready for prime time. Can you give an update to its status?
> * I'd suggest the 16F876/7 as the main chip, since it can self-program,
> it has the on-chip goodies, and it's cheaper than the 18Fs; upgrading
> from 16F to 18F is orders of magnitude easier than the other way
> round; also it's got less memory scarcity than (say) the 16f873
What's the price difference between it and a comparable 18F part? I'll go
check digikey....
[Some virtual minutes later]
It seems that the 18F parts are 60-80% higher ($9 vs. $5.15 or so in singles.)
> * for a programmer - probably best to pick one that:
> - has minimal parts count
> - can work via serial port (PCs usually have 2 serial ports but only
> one parallel port, and the parport is often in use with a printer)
> - has PCB artwork and parts list, plus working Linux-compatible
> on-chip and on-host programming software, freely downloadable from
> the net (I bought a great programmer kit from Jaycar, but can't
> recommend this because Jaycar only has stores in Aus and NZ, and
> this would be a pain for people in other countries)
Programmers are a tough issue. With the decline of the serial port, serial
programmers are becoming relegated to USB or to using USB to serial cables.
Neither guarantee compatibility across all potential programmers.
I'm planning on designing a simple, cheap programmer that works with any
3 wire serial port. So it should be usable with any USB-serial cable without
worries about modem control.
> * for a bootloader - I'm personally using TinyPIC Bootloader on my
> 18Fs, but haven't got this working on the 16Fs (so I use the PicForth
> Serial Monitor on those chips) - need to choose a bootloader which:
> - is written in assembler and builds ok on gputils, or is written in
> C and builds ok with sdcc
Check.
> - has a working host client written in a common language, that is
> easily built with reliable results without dragging the user
> through autocrap/dependency hell (as linux progs can sometimes do)
Check.
I've used Wloader with the linwload client. Wloader fails the first requirement
due to some funky macro usage.
I really like it because it doesn't require any shifting of the application
code and doesn't use the hardware serial port.
>
> * tutorial should include a section on gpsim, using .map and .lst files
> so user can correlate the high-level code to the raw binary; should
> walk user through:
> - setting up gpsim config
> - single-stepping and use of breakpoints
> - inspecting SFRs and user data memory contents
Doesn't that still require understanding PIC assembly. I find it tough to
support putting in an abstractive layer when you'll have to then tear down
the abstraction at multiple points in time.
How about dividing into 2 sections. Start with only relocatable assembler.
Then have a second "advanced" section where the student transistions to a
high level language.
I agree that developing in assembler slows you down. But unless you have a
clear understanding of the underpinnings of assembler, a lot of material
in this domain will get you lost.
> This approach eliminates the complication of multiple
> chips/languages/programmers.
Other than my insistance that the intro language has to be assembly, I'm
pretty much in agreement.
BAJ
