Searching \ for 'GNU Development Tools for PICs' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'GNU Development Tools for PICs'.

Truncated match.
PICList Thread
'GNU Development Tools for PICs'
1995\11\13@125835 by Rick Miller

flavicon
face
Hi!

Well, I decided to start a mailing-list dedicated to writing development
tools for the PIC16C84 (and other PICs too) which will be freely available
in CopyLeft'd C source code.

The first priorities of the list will include:

 o Improving Timo Rossi's assembler to fully handle forward references.
   Probably, we'll need to add a "pass zero" to build a symbol table.
=20
 o Converting John Favata's compiler to output PIC assembly instructions
   instead of Parallax's pseudo-8051 code.  It may be best to follow
   John's strategy, but the assembly code will probably need some
   optimization once it's converted.

The mailing list charter is included below.  Please e-mail me personally
if you'd like to be included in this mailing list.

---------------
                              The GNUPIC Charter

      This is the charter for the "spam_OUTgnupicTakeThisOuTspamdigalogsys.com" mailing list.
                        Copyright =A9 1995 Rick Miller
                            <.....rickKILLspamspam@spam@digalogsys.com>
---------------------------------------------------------------------------=
----
The GNUPIC mailing list is provided as a forum for those wishing to program
Microchip PIC microcontrollers using tools which are freely available under=
the
GNU CopyLeft.

At first, this will mean developing such tools that may not already exist i=
n
freely available source such as a simulator, linker, librarian, or compiler=
s
for languages other than C. Then, refinement and distribution of these tool=
s
will be the main goal.

Due to the nature of the expected audience, the GNUPIC mailing list will be
targeted primarily at those wishing to use the PIC16C84. This is the only P=
IC
which Microchip makes with EEPROM program memory for in-circuit programming=
.
It's ideal for those who just want to try out microcontroller programming w=
ith
as little initial investment as possible.

Hopefully, we'll produce a top-notch development environment for the PIC16C=
84
which can be compiled for just about any platform.
---------------------------------------------------------------------------=
----
Copyright =A9 1995 Rick Miller
<rickspamKILLspamdigalogsys.com>

Rick Miller, Design Engineer  (and local "Internet Guy")
Digalog Systems, Inc.         <.....rickKILLspamspam.....digalogsys.com>
3180 S. 166th St.             <EraseMERick.Millerspam_OUTspamTakeThisOuTLinux.org>
New Berlin, WI  53151  USA    +1 414 797 8000 x-228

1995\11\13@145600 by Byron A Jeff

face picon face
>
> Hi!
>
> Well, I decided to start a mailing-list dedicated to writing development
> tools for the PIC16C84 (and other PICs too) which will be freely available
> in CopyLeft'd C source code.

Cool! Add me to it.

{Quote hidden}

I'd like to add a couple of things to the table. I'm a computer science
professor in Computer Science at Clark Atlanta University (obviously in
Atlanta ;-) Anyway for the last 3 years I've been teaching a class on the
development of Computer Systems Software. We focus on assembler and an
introduction to compilers including projects. Since we professor types
are obligated to at least have a cursory understanding of the projects ;-)
my students and myself have put in quite a lot of work into said projects.
Over the last 3 semesters we have been targeting PICs. The results:

- A fully functional 16C84 assembler. It's one pass and does forward
references. It currently doesn't output the symbol table for linking
purposes but is easy enough to add.

- The foundation to a high level language called NPC (nano-pseudo-C). NPC
strips most of the functionality from C and leaves just the absolute
minimum. It adds some keywords (ENDIF, ENDWHILE, CALL) to simplify the
parsing process. It does most of the C operators and adds a couple
(Like direct bit manipulation and direct assignment of addresses to
variables). It only has pointers and chars right now. I had been targeting
the 17C42 and was about 30% finished with the code generation. It uses
flex for a front end (any GNU problems there?) and is recursive descent
(Didn't want to confuse the students with bison). The heart of it is
the infix-postfix parser that makes code generation straightforward. This
semester I'm splitting the project in two adding a lower half interpreter.

It's all in C and should be no problem to release under GNU. Runs under
Linux right now.

Anyway put me on the list and let me know if there is anything I can do
to help.

BAJ

1995\11\14@045016 by Matthew Rowe

flavicon
face
> Well, I decided to start a mailing-list dedicated to writing development
> tools for the PIC16C84 (and other PICs too) which will be freely available
> in CopyLeft'd C source code.
> At first, this will mean developing such tools that may not already
> exist in freely available source such as a simulator, linker,
> librarian, or compilers for languages other than C. Then,
> refinement and distribution of these tools will be the main goal.
>
> Due to the nature of the expected audience, the GNUPIC mailing list will be
> targeted primarily at those wishing to use the PIC16C84. This is the only
> PIC which Microchip makes with EEPROM program memory for in-circuit
> programming.
> It's ideal for those who just want to try out microcontroller programming
> with as little initial investment as possible.
>
> Hopefully, we'll produce a top-notch development environment for the
> PIC16C84 which can be compiled for just about any platform.

Sounds great but I see no mention of a programmer.
This is fairly key in the development environment isn't it?

/\/\att.

1995\11\14@080205 by Byron A Jeff

face picon face
> > Hopefully, we'll produce a top-notch development environment for the
> > PIC16C84 which can be compiled for just about any platform.
>
> Sounds great but I see no mention of a programmer.
> This is fairly key in the development environment isn't it?

Not in this instance. Since the initialize target is the 16C84 and there
are several designeds out for programming it. The COM84 programmer is
quite effective.

Right now I'm thinking about putting together an interpretive environment
a-la the BASIC Stamp. Like the stamp the program would be saved in a
serial EEPROM. Unlike the stamp I'd like to add a 4 chip static RAM
circuit for storing the program and data like the 8031. On Boot up
the PIC loads the RAM from the EEPROM and off it goes. I plan to use
a separate serial based loader to load up the EEPROM thus removing the
need for the board to have to load it.

It's just in the thought phase right now...

But the bottom line is that we have programmers but very little in the
way of programming tools that are cross platform. I use DOS/Windows once
every fifth blue moon. So Unix/serial based tools are top priority.

BAJ

1995\11\14@095200 by Rick Miller

flavicon
face
On Tue, 14 Nov 1995, Matthew Rowe wrote:
[...]
> > Hopefully, we'll produce a top-notch development environment for the
> > PIC16C84 which can be compiled for just about any platform.
>
> Sounds great but I see no mention of a programmer.
> This is fairly key in the development environment isn't it?
>

Um... yup.  That gets mentioned later, where I beg and plead for
someone to come up with the code to drive an RS-232 port for the
"PicBlaster" el-cheapo '84 programmer.  :-)

Seriously though, you're absolutely right.  It doesn't do me much
good if I can't download the code I've developed without booting DOS.

Doing code for parallel-port programmers is fairly straightforward
on IBM-style PCs... but I'd rather use the RS232 port, since more
folks are likely to have 'em, and the programmer is really easy to
build.

So, Matt, should I count you in on the gnupic list?

Rick Miller, Design Engineer  (and local "Internet Guy")
Digalog Systems, Inc.         <rickspamspam_OUTdigalogsys.com>
3180 S. 166th St.             <@spam@Rick.MillerKILLspamspamLinux.org>
New Berlin, WI  53151  USA    +1 414 797 8000 x-228

1995\11\14@103223 by Matthew Rowe

flavicon
face
> > > Hopefully, we'll produce a top-notch development environment for the
> > > PIC16C84 which can be compiled for just about any platform.
> >
> > Sounds great but I see no mention of a programmer.
> > This is fairly key in the development environment isn't it?
> Not in this instance. Since the initialize target is the 16C84 and there
> are several designeds out for programming it. The COM84 programmer is
> quite effective.


Absolutely! It's the only thing I use but it's certainly not cross
platform.

> I plan to use a separate serial based loader to load up the EEPROM
> thus removing the need for the board to have to load it.

You're going to go to a different machine to load up? I don't follow.


> It's just in the thought phase right now...
>
> But the bottom line is that we have programmers but very little in the
> way of programming tools that are cross platform.

We don't have cross platform programmers. COM84 is completely tied to
DOS - it won't even work in Windows.

/\/\att.

1995\11\14@104919 by Rick Miller

flavicon
face
On Tue, 14 Nov 1995, Matthew Rowe wrote:
[...]
> We don't have cross platform programmers. COM84 is completely tied to
> DOS - it won't even work in Windows.

COM84 works fine in a DOS-Window under Windows'95...

Rick Miller, Design Engineer  (and local "Internet Guy")
Digalog Systems, Inc.         <KILLspamrickKILLspamspamdigalogsys.com>
3180 S. 166th St.             <RemoveMERick.MillerTakeThisOuTspamLinux.org>
New Berlin, WI  53151  USA    +1 414 797 8000 x-228

1995\11\14@174612 by Byron A Jeff

face picon face
>
> > > > Hopefully, we'll produce a top-notch development environment for the
> > > > PIC16C84 which can be compiled for just about any platform.
> > >
> > > Sounds great but I see no mention of a programmer.
> > > This is fairly key in the development environment isn't it?
> > Not in this instance. Since the initialize target is the 16C84 and there
> > are several designeds out for programming it. The COM84 programmer is
> > quite effective.
>
>
> Absolutely! It's the only thing I use but it's certainly not cross
> platform.

Why can't it be. Doesn't Unix and MAC platforms have the ability to
fiddle twiddle the bits so that it can program?

>
> > I plan to use a separate serial based loader to load up the EEPROM
> > thus removing the need for the board to have to load it.
>
> You're going to go to a different machine to load up? I don't follow.

Call it an intelligent cable. RS-232 serial that attaches to a machine
and a PIC on the other. The PIC talks standard ASCII to the serial port
and has an interface to program the serial EEPROM. The programmer board
contains a MAX-232 type device and a UART. Once the "cable" is detached
from the board, the on-board PIC is free to load the program from the
serial EEPROM and execute it. This provides more of the 1K space
for the interpreter for the on-board PIC and relieves it from the duty
of having to communicate serially to the programming system. When you're
talking about a 18 pin part, 2 pins is important.

Of course this is a chicken and egg problem because you need two
programmed PICS to do the job. I have a PICSTART so that isn't a
real big deal to me. And if you have 16C84's then the COM84 can do the
job the first time then you can use whatever you like to do your development.

But once you have those programmed PICS downloading programs are simple.
Also as long as you have the same interface to the serial EEPROM you can use
whatever PIC you like as the on-board one. Just program the interpreter
into the PIC and load the program into the serial EEPROM just like the
stamp.

See I'm trying to get this system for my students so that they can
load their programs to the system dozens, hundreds, or thousands of times.
And I need it to run from a Linux box.

>
>
> > It's just in the thought phase right now...
> >
> > But the bottom line is that we have programmers but very little in the
> > way of programming tools that are cross platform.
>
> We don't have cross platform programmers. COM84 is completely tied to
> DOS - it won't even work in Windows.

Well then my interpreter can resolve this by making the COM84 used once
and then you can directly connect it to whatever you like from then on.

How much would one spend on a 3 chip circuit with a preprogrammed PIC that
simply reads a serial port and flips bits and allows for precise timing on
the flipping of those bits? This is the real piece of technology that is
needed to bridge the gap. David Tait attempted this with his MIPI stuff
and it is the right idea. It tried to eliminate the need for something
to be programmed. But it's tough to do simply. Maybe we need to revisit
that idea...

BAJ

1995\11\15@044530 by Matthew Rowe

flavicon
face
> > > are several designeds out for programming it. The COM84 programmer is
> > > quite effective.
> > Absolutely! It's the only thing I use but it's certainly not cross
> > platform.
>
> Why can't it be. Doesn't Unix and MAC platforms have the ability to
> fiddle twiddle the bits so that it can program?

No reason it can't be. The point is it isn't. I don't have the know
how to write one myself.


> See I'm trying to get this system for my students so that they can
> load their programs to the system dozens, hundreds, or thousands of times.
> And I need it to run from a Linux box.

Thats where we differ then. I'm more interested in the electronics
side and don't want the overhead of a complete development system
tied to every PIC. (And I prefer programming in PIC assembly language
which is completely portable.)


/\/\att.

1995\11\15@101353 by Byron A Jeff

face picon face
> > See I'm trying to get this system for my students so that they can
> > load their programs to the system dozens, hundreds, or thousands of times.
> > And I need it to run from a Linux box.
>
> Thats where we differ then. I'm more interested in the electronics
> side and don't want the overhead of a complete development system
> tied to every PIC. (And I prefer programming in PIC assembly language
> which is completely portable.)

I haven't made myself completely clear. This system is for rapid
prototype development work. Right now while doing development there
are a few options each with their own "quirks".

1) 16C84 - Probably the best of the bunch. The EEPROM allows for in-circuit
programming and quick turnarounds. However the part is I/O and speed limited.
2) Simulator - The MPSIM software works pretty well but you're locked into
PC land to use it. I've effectively used it under the DOS emulator with Linux.
But it was a lot of additional setup.
3) ICE - Expensive. 'Nuff said.
4) EPROM based PICS - The windows parts are expensive and the programmers are
all PC based. The turnaround time is slow.
5) BASIC stamp - going in the right direction. However running from a serial
EEPROM slows everything down immensly. And development can only be done from
a PC based platform.
6) 17C42 - Fast, runs from external memory, sufficient I/O, built in UART. But
have you priced these puppies lately? Also for the external memory interface
you need 4 to 7 additional chips. Lastly the standard programmers don't do
the 17C42.

The ideal part would be a 16CXX or 17CXX part with a UART and 33 I/O pins
that runs at 20-25 Mhz and is EEPROM programmable in-circuit. But it doesn't
exist and probably will not ever. Discussions on the list from Microchip has
made it clear that their big customers need ultra cheap one time programmable
parts where each penny makes a big difference. They can afford PC based
environments and ICE for doing their work.

So for the rest of us, that is hobby and one-off folks, Our issues of easy
programmability, multi-platform development, and more I/O, and of course the
usual ones of more speed and less power and inconsistent with the goals
of the folks who pays Microchip's bills.

As for the assembly vs. high level language debate, I think the issues have
been re-hashed enough. Both require tools and as long as the tools are
available the choice shouldn't matter. My goal is to produce a high level
front end with multiple back-ends just like GCC. By having an assembly
back-end and a interpreter back-end I can develop with the interpreter and
once the code is working correctly then I can compile it into native code
and blow the part.

The way I see it I'd rather build one interpreter that I can blow into
a OTP then use that OTP interpreter for development in a HLL than to have to
pull a EPROM chip over and over and over for development in assembly.

I guess I need to explain where I've been in terms of SBC development. I
cut my teeth on motorola stuff starting with 6800 stuff and quickly moving
to 68K's. Through experience I found that the two most essential tools
for good development was a good compiler and a good on-board loader/monitor.
At the top of the heap (about 3 years ago) I had a 68340 with a self written
serial file system that was self hosting a C compiler, linker, and assembler.
Then I ran into PICs and all that changed.

I spent the first year trying the learn how to program the danged things. The
Microchip released the 16C84 and the programming specs for everything. In
addition their really cool seminars supplied PICSTARTS 16's for a reasonable
price. But I'm a Linux guy so their tools weren't real interesting to me until
one of my students ran some tests and figured out that everything ran under
the DOS emulator. That helped. Good thing it was serial based programmer.

But the process sucks. Pull the chip, program the chip, test the chip,
repeat. We broke at least one pin off 4 different 16C84's. You have to
be there to do development. With my 68K board hanging off a network I
could do development anywhere I could telnet from. And the kicker was the
16C84 project we were working on was serial based (and I got some good
serial tools from my student) so there was no need to hover over the board
except for the development process.

BTW I also have a special need. I have a class of twenty students that need
to program a board. I'm pretty sure that even in-circuit programming can
withstand that assult.

So as a first attempt I've built a board with a 17C42 with 64K of RAM. The
RAM is loaded using a 16C84 with my student's serial routines. It has some
glitches but is on the right track.

The other thing is the language issue. Consider this: if I have a high
level language I can run the same program on a PIC 16C84, a PIC 17C42,
and a motorola 68K. I can scale the I/O, memory, and speed to match the
particular application I need. Also if I interpret the HLL then once I
have the interpreter solid I can blow it into a OTP and be sure that
part is usable. I can test with interpretation and compile for production.
But if speed isn't the primary issue there's no reason to switch from the
interpreter once it works. This requires some semi-permanent storage.
Hence the serial EEPROM.

Now for development part. I want the following features:

- In-circuit
- Multiplatform
- fast loading and turnaround
- fast execution
- Circuit continues to function even when detached from development
 environment.
- Minimal additional circuitry

Note that many of these are at cross purposes. To support the first two
it requires more circuitry. For the circuit to continue to function
after programming you need EEPROM. for less circuitry you want serial
EEPROM. But that slows the execution.

So there's a bunch of tradoffs. But the one thing that's clear is that
the loader and the target need not be the same. The serial part and
the programmer can be on one board that stays attached to the PC or workstation
and the target can then be separated. Plus the "programmer" can be used
with different targets.

So the programmer would probably consist of a UART, a MAX232, and a programmed
16C84. A DB9 or 10 pin dual header would connect the target to the board.
The programmer's primary job is to program the serial EEPROM on the target.
The programmer holds the RESET/MCLR of the target in reset during programming.

The target's job is to interpret the code in the EEPROM. For speed a target
can transfer the code to a faster device (like a RAM) before executing. Targets
that can execute native code certainly can do so. Some possible targets:

1) A 16C84 and a serial EEPROM. Just like a stamp.
2) A 17C42 that's programmed with an interpreter and a EEPROM loader. It
can interpret in single chip mode or interpret or run native code that's
loaded into RAM.
3) 683XX products that can either interpret or run native code that's loaded
via the BDM port from the EEPROM using a PIC.

The list goes on and on...

I think it's a very powerful and flexible concept.

BTW the chicken and egg problem I'm working on too. How to program without
having a programmed chip. David Tait has given me some good ideas.

Comments?

BAJ

1995\11\15@114740 by Mike Goelzer

flavicon
face
Please add me to the new list.

-mike
--
Mike Goelzer
<spamBeGonemgoelzerspamBeGonespamus.net>

1995\11\19@014420 by Erik Hermann

flavicon
face
pmdl> So the programmer would probably consist of a UART, a MAX232, and a
pmdl> programmed
pmdl> 16C84. A DB9 or 10 pin dual header would connect the target to the

No need for this.
You can program a 16C84 with a Max232 and two inverters.
Even only with a Max232, but this is triky.
This works with every RS232, not just with PC-Ports.

I've used this on my machine independant Pic programmer.
After programming, the 16C84 takes controll over the serial communication
and can program other PIC's, EEPROM, Flash, etc.


Gruss
   Erik

___ Terminate 1.51

1995\11\19@024556 by Mohamad Shalan

flavicon
face
Hi Erik,
       I need information about ur m/c independent programmer.

       Shalan,

1995\11\19@125845 by Byron A Jeff

face picon face
>
>  pmdl> So the programmer would probably consist of a UART, a MAX232, and a
>  pmdl> programmed
>  pmdl> 16C84. A DB9 or 10 pin dual header would connect the target to the
>
> No need for this.
> You can program a 16C84 with a Max232 and two inverters.
> Even only with a Max232, but this is triky.
> This works with every RS232, not just with PC-Ports.

Um, Erik, I think you kind of lost the context of what I was talking
about. Thumbnail summary of my issues:

- I hate programming parts during development.
- I not too keen on assembly language.
- the 16C84 while ultra-cool doesn't handle every need.
- I'm not a DOS guy. Serial interface is a must.

So my proposal:

- Develop a language for microcontroller developent.
- Design multiple back ends, one for compilation on each platform and an
 tokenized interpretive backend.
- Install an interpreter for the tokenized program into the microcontroller
 the minimum requirement is that tokens can be read from a serial EEPROM.
 These target boards can load the serialized program from the EEPROM into
 RAM if you want faster execution. For machines like the 17C42 which can run
 native code, the code can be read into ram and executed directly.
- The loader I was talking about above would take a tokenized program and
 write it to the serial EEPROM. that way the target wouldn'y need an RS-232,
 and a loader program on board. More hardware and software space for the
 interpreter.

So you'd actually need a 16C84 to have enough smarts to decode the incoming
stream and program the serial EEPROM. It can also double as a programmer since
it'll have enough smarts to do that.

However the initial 16C84 has to be programmed and so it's an issue too.

So please explain what software is necessary to fiddle the bits properly.
I was inspired by David Tait's MIPI design to think about how to do this
bootstrapper easily. Two avenues come to mind...

1) Use a 6402 UART. It doesn't need to be programmed to work and requires
only a crystal for the bit rate. Jameco has them for $4.95 each. With it and
a crystal you can get 8 inputs and 8 outputs.

2) A MIPI type circuit that uses a crystal controller counter and a flip-flop
to read and latch some bits out of each word written. David's concept is
the right idea, I think it had a bit too much hardware considering it'll
probably be an interim bootstrap anyway.

Erik, take another read of what I was saying and comment. I'm trying to get
away from physically programming anything.

BAJ

1995\11\20@000907 by barnwell

flavicon
face
In article <TakeThisOuTPine.LNX.3.91.951113112246.5269A-100000EraseMEspamspam_OUTnet.digalogsys.com>, you
say...
>
>Hi!
>
>Well, I decided to start a mailing-list dedicated to writing development
>tools for the PIC16C84 (and other PICs too) which will be freely available
>in CopyLeft'd C source code.
>
Put me on the list. I am new to pic programming (just a hobby) but have dealt
with assembly for machines since the PDP5.

I might be able to find some time to get modules done and also have access to
most DEC platforms in the larger computer space.

1995\11\24@052159 by Lattmann Marcel

flavicon
face
yo, man

More... (looser matching)
- Last day of these posts
- In 1995 , 1996 only
- Today
- New search...