gnupic@linuxhacker.org

gnupic@linuxhacker.org


Subject: Should JAL be added to the gputils?
From: Byron A Jeff
Date: Sun, 4 May 2003 19:47:57 -0400 (EDT)

Just wondering if maybe we should add JAL to the gnupic lineup?

JAL (http://www.voti.nl/jal) is a high level language PIC compiler. It's
primary focus so far has been the PIC 14 bit family. But there has been some
18FXXXX support added.

Wouter van Ooijen, JAL's author, released the source of the project into the
GPL nearly 6 months ago. It can be downloaded from the website. JAL also 
carries a widely read Yahoo group: http://yahoo.groups.com/group/jallist
and a fairly recently created developers group: 
http://yahoo.groups.com/group/Jal_developers

JAL has an extensive set of libraries to operate a wide variety of devices
such as HD44100 LCDs, 7 segment LED displays, and I2C interfaces. In addition
JAL libraries have a lot of support for PIC internal devices such as hardware
USARTs, A/D converters, timers, and the like.

The simple Pascal like language syntax is fairly easy to pick up too. In 
addition Wouter has written fairly extensive documentation for the language.

In my personal JAL port I've added a couple of small items:

* Default library directory support. Specifically /usr/local/lib/jal is
  autosearched for library files.

* A slightly more extensive upgrade that handles the issue of multiple
  include file inclusion using aliased filenames. JAL was primarily developed
  under windows and as such didn't utilize the C PreProcessor. So include files
  are in fact a part of the language. In addition like C++, include files are
  automagically excluded after the first inclusion. However it breaks down
  if the include file name is aliased. For example JAL has a default include
  file for pin definitions, called jpic.jal. But there are processor specific
  definitions files, say for the PIC 12F675, that has improved routines for
  accessing the parts periperals over the standard jpic.jal. However replacing
  the original include of
   
   include jpic.jal

   with something like

   include jpic_12F675.jal

   will cause failure because several of the internal includes include jpic.jal
   under the presumption that if it's already included, then there's no foul.
   Unfortuately it does fail because after including jpic_12F675.jal, the 
   subsequent include of jpic.jal will happen, causing conflict.

   Of course here's the wonder of Open Source. I hacked in an alias mechanism
   so that any number of include file names can be autoexcluded in a single
   include statement. So I would instead encode the above include as:

   include jpic_12F675.jal,jpic.jal

   which tells the compiler to actually include the first file, and to mark 
   any subsequent files as being included already. So I get the updated 
   definitions, and any subsequent includes of jpic.jal will be skipped.

I'm just thinking that the gputils group may be able to use JAL as a kinder,
gentler intro to PIC programming. A lot of times speed isn't the issue in
getting a job done, but how simply the job can be specified in code.

I do think that JAL would need at the very least an autoconfig file to simplify
installation. Amazingly enough Wouter has the project as a single 13K line C
file. Also I guess that adding some sort of gpsim support would probably be
next on the support list.

Any thoughts?

BAJ

gnupic@linuxhacker.org