Subject:
Re: [gnupic] PIC under Linux developpement Howto
From:
"Philippe BEAU" ####@####.####
Date:
4 Jul 2005 21:06:49 +0100
Message-Id: <1888.86.194.118.75.1120507607.squirrel@www.choup.net>
Hello all,
Thanks for all the answers i receive. I will make a wiki (i thank to this
:) ) and i will post the information here. Also, we should begin to work
on soon,
Best regards
Philippe,
> On Tue, Jul 05, 2005 at 03:41:21AM +1200, David McNab wrote:
>> Philippe BEAU wrote:
>> > Hello all,
>> >
>> > i would like to write an howto about the developpement with Pic series
>> > under Linux. Do you think it's a good idea ? Is anyone can confirmed
>> me
>> > that this type of document don't already exist ?
>>
>> Such a document is sorely needed. It would have saved me much heartache
>> if good newbie doco had existed when I got started with PICs.
>>
>> Some ideas to consider:
>>
>> 1. designing the documents as a set of 'trails', where one can click on
>> links according to their situation:
>>
>> - what kind of PIC (I'd suggest supporting just 16F and 18F for
>> now)
>
> Bad idea. Pick 1 part and stick to it like glue. Choices confuse new
> users. Pick something that has capabilites for intermediate projects but
> is simple to get started with. Considering the USB craze, I'm thinking
> that
> maybe the 18F2550 may be a good target.
>
>
>> - what kind of programmer hardware
>> - choices of programmer software
>> - choice of languages
>> - toolchains appropriate for chosen language
>
> I would put options on a separate page and limit programmers to a single
> build or buy choice.
>
> Personally I think it's a disservice to start any PIC newbie in any
> language
> other than PIC assembly.
>
>> 2. walk the reader through each step, eg:
>>
>> - selecting a PIC chip
>
> Skip. Tell them the chip.
>
>> - procuring the programmer hardware
>> - choosing the programmer software, downloading and
>
> No choices. Tell them what to download.
>
>> installing it
>> - building a mimimal test circuit with one or more LEDs
>> - choosing a programming language - assembler, C, Forth,
>> Python or one of the obscure ones
>
> One language. Preferably relocatable assembler. An intermediate user can
> make bettern choices.
>
>> - sourcing, downloading, (if necessary, compiling) and
>> installing the toolchain(s) - gputils, sdcc, picforth etc,
>> possibly with instructions for the major distros such as
>> debian, gentoo, ubuntu, redhat etc
>
> That may be OK.
>
>> - writing a 'hello, world' LED-blinker program in chosen
>> language
>
> One language.
>
>> - compiling the program successfully to a .hex file
>> - burning the program into the PIC
>> - verifying the programmed image
>> - plugging the PIC into the test circuit and verifying
>> that it works
>
> All fine.
>
>> and for PICs with self-programming capability:
>
> Only one pic, and it should be self programmable.
>
>> - building a MAX232 or equivalent TTL<->RS232 level converter
>> circuit
>> - writing a simple program to test/verify that PIC serial I/O
>> is working, via GTKterm or similar
>> - choosing a bootloader
>> - compiling the bootloader to a .hex, and burning it into the
>> PIC
>> - downloading the earlier test program to the PIC using this
>> bootloader, verifying all is ok
>
> If you're going the bootloader route, and personally I love the bootloader
> route, then the programmer should be a one shot such as one of my Trivial
> Programmers. They were designed specifically for that purpose.
>
>> and also:
>> - link-farm pages with sources of extra info, eg PICLIST for
>> contributed library routines
>>
>> The idea is that the reader can work through each step in sequence,
>> verify their successful completion of that step, then move on to the
>> next step. After the final step, they will end up empowered to take
>> their PIC development wherever they choose from that point on.
>
> I would carry projects from early beginner to mid-intermediate. Stuff
> like LCD displays, switches, ADC (for user input), PWM (for LED
> brightness),
> USART. In each show them the hardware solution followed by a software
> solution. Explain at each step that they should use the hardware solution
> whenever possible.
>
>>
>> Thinking about it, it might be a good idea to make it a wiki, so people
>> can contribute. Perhaps the wiki could be templated with
>> language-specific links at the top, so when reading any given page, they
>> can switch to a version of that exact same page in another language -
>> also, wherever translations are missing, polylingual folks with a few
>> minutes to spare can contribute a translation.
>
> Now that might be an idea!
>
>>
>> Good on you, Philippe, for your willingness to offer such a substantial
>> boost to the linux-using PIC community. We look forward to seeing how it
>> shapes up.
>
> Keep it simple to start. Pick one chip, one language, one programmer, and
> one bootloader if you choose to go in that direction.
>
> BAJ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
