Searching \ for '[PIC] Anybody else using PIC19F193X?' 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: 'Anybody else using PIC19F193X?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Anybody else using PIC19F193X?'
2011\06\28@134110 by Bob Axtell

face picon face
I wanted to use JAL but this has a few very different instructions
that there are no libraries for.

I am gonna MPASM this one. Is there a friendly face out there
who might be there in case I have trouble?

--Bob

2011\06\28@141414 by Rob Hamerling

picon face

Hi Bob,

On 2011/06/28 19:41, Bob Axtell wrote:
> I wanted to use JAL but this has a few very different instructions
> that there are no libraries for.

As member of the Jallib group I'm curious to know what you mean exactly with 'different instructions for which there are no libraries'.

In the Jallib sample library you can find two sample JAL programs for the 16f1937 using the serial port.

> http://code.google.com/p/jallib/source/browse/#svn%2Ftrunk%2Fsample


Regards, Rob.

-- R. Hamerling, Netherlands --- http://www.robh.n

2011\06\28@142757 by Byron Jeff

flavicon
face
I'm starting integration of this series. I've gotten up to speed on the
architectures. I'm still trying to get the latest version of gpasm working
with it, though an old copy that one of the Mchip guys updated does the job
so far.

You can start with a skeleton that I put together for my students. It
cranks up the internal oscillator up to 32 Mhz. I have it set up for
bootloader work, but if you don't need it, you can pull the initial jump
out, as the bootloader will not rewrite the first 32 word block of the
chip.

http://kahuna.clayton.edu/csci2305/pic/skeleton1938.asm

One last item from the errata: low voltage programming for the 16F1938 and
16F1939 does not work. Not sure if you plan to use it. But no need to waste
time on it. High voltage programming works fine.

Hope this helps,

BAJ

On Tue, Jun 28, 2011 at 01:41:26PM -0400, Bob Axtell wrote:
> I wanted to use JAL but this has a few very different instructions
> that there are no libraries for.
>
> I am gonna MPASM this one. Is there a friendly face out there
> who might be there in case I have trouble?
>
> --Bob A
> -

2011\06\28@175639 by Bob Axtell

face picon face
On 6/28/2011 11:11 AM, Rob Hamerling wrote:
> Hi Bob,
>
> On 2011/06/28 19:41, Bob Axtell wrote:
>> I wanted to use JAL but this has a few very different instructions
>> that there are no libraries for.
> As member of the Jallib group I'm curious to know what you mean exactly
> with 'different instructions for which there are no libraries'.
>
> In the Jallib sample library you can find two sample JAL programs for
> the 16f1937 using the serial port.
>
>> http://code.google.com/p/jallib/source/browse/#svn%2Ftrunk%2Fsample
>
> Regards, Rob.
>
I apologize, Rob. So your JAL libraries are handling the new FSR1, INDF++, ++INDF,
etc? How would I know if a JAL library can handle these or not? I have little knowledge
of how one develops a high level language, forgive me...

--Bob

2011\06\29@032312 by Rob Hamerling

picon face


On 2011/06/28 23:56, Bob Axtell wrote:

>> On 2011/06/28 19:41, Bob Axtell wrote:
>>> I wanted to use JAL but this has a few very different instructions
>>> that there are no libraries for.

> So your JAL libraries are handling the new FSR1,
> INDF++, ++INDF, etc? How would I know if a JAL library can
> handle these or not? I have little knowledge
> of how one develops a high level language, forgive me...

Sounds to me like you never used a high level programming language...

When using Jal (or C or Pascal, etc.) the compiler (JALV2) chooses  the machine instructions needed for the desired operations, depending on the processor-type for which the program is destined. I don't know and I don't really care if the JalV2 compiler uses new instructions like those of the 16f193x. It might be able to build more efficient programs if it does, but that is a different matter.

The Jallib libraries are written in JAL (with few exceptions), for which the same applies as above: independent of the machine instruction set.

Jallib contains device files (comparable to asm '.inc' files) which make it possible to write device independent programs and makes it easy to switch from one to another type of PIC.

Furthermore Jallib provides a collection of function libraries (like for PWM, ADC, I2C, LCD, RS232, USB and many other functions) which lift application programming to an even higher level than pure JAL.

To give JALV2 and Jallib a try you might find the tutorials helpful:

> http://www.justanotherlanguage.org/content/jallib/tutorials/tutorial_book


Regards, Rob.

-- R. Hamerling, Netherlands --- http://www.robh.n

2011\06\29@034809 by Tamas Rudnai

face picon face
On Wed, Jun 29, 2011 at 8:22 AM, Rob Hamerling <spam_OUTrobhamerlingTakeThisOuTspamgmail.com>wrote:

> When using Jal (or C or Pascal, etc.) the compiler (JALV2) chooses  the
> machine instructions needed for the desired operations, depending on the
> processor-type for which the program is destined. I don't know and I
> don't really care if the JalV2 compiler uses new instructions like those
> of the 16f193x. It might be able to build more efficient programs if it
> does, but that is a different matter.
>

In my reading that's what exactly Bob wanted to know -- if JAL supports
these new enhanced instructions to make more efficient code or not. Without
the support from the compiler side there is very little advantage using the
enhanced core over a normal midrange one.

Tamas




{Quote hidden}

>

2011\06\29@052109 by Michael Watterson

face picon face
On 29/06/2011 08:48, Tamas Rudnai wrote:
> In my reading that's what exactly Bob wanted to know -- if JAL supports
> these new enhanced instructions to make more efficient code or not. Without
> the support from the compiler side there is very little advantage using the
> enhanced core over a normal midrange one.
>
> Tamas

Kyle would know.

The JALv2 compiler does appear to "take advantage" of PIC HW, i.e. multiply if it's an 18F rather than a 10F uses the multiply instruction and multiply hardware.

It's a superb optimising compiler. Unless you are Olin, you will not do as well in Assembler even if the compiler is ignoring the odd device specific instruction.

I've found all the C compilers produce much larger and sometimes buggy code..

I've done Assembler since 1979 and done PIC 16F877 assembler projects. I'd not use anything else now for Traditional PIC (10F to 18F).

Also in unlikely event (once in last 4 years or so for me?)  you need assembler you can use it inline.

http://www.justanotherlanguage.org
Is very clear for beginner. The Google hosted libraries are great.
Also some examples JALV2 on http://www.techtir.ie
USB communication
Serial
Frequency counter
Interrupts
ADC use
7 seg LED, text LCD and Graphic LCD driving
I2C memory device used as if an array variable
Analogue clock face on GLCD, can be resized and moved while running
How to use lookup tables for trig and other maths.



2011\06\29@061435 by Walter Banks

picon face


Rob Hamerling wrote:

>  I don't know and I
> don't really care if the JalV2 compiler uses new instructions like those
> of the 16f193x. It might be able to build more efficient programs if it
> does, but that is a different matter.

The enhanced 14 bit core parts (PIC19F193X) has two significant
changes. The ISA is a superset of the normal instruction set has
been mentioned in this thread. The second major difference is the
organization of the the processors memory map. This affects how
memory management is handled in code and how RAM should be
allocated by a compiler.

The memory organization changes makes it essentially impossible
to use existing HLL tools to support the parts.

The changes in the  memory maps are a big step in making the parts
more efficient for applications. RAM has effectively two addresses
one similar to the original 14 bit core and a second where the RAM
pieces are mapped into one long linear address.  Tools can optimize
how data is accessed knowing this relationship.



Regards,


w..
--
Walter Banks
Byte Craft Limited
http://www.bytecraft.com




2011\06\29@062309 by Tamas Rudnai

face picon face
On Wed, Jun 29, 2011 at 10:21 AM, Michael Watterson <.....mikeKILLspamspam@spam@radioway.org>wrote:

> The JALv2 compiler does appear to "take advantage" of PIC HW, i.e.
> multiply if it's an 18F rather than a 10F uses the multiply instruction
> and multiply hardware.
>

Thanks for the head up. Once I have evaluated JAL v2 and found it great,
except that it does not support any floating point maths (or did not do that
by that time I have tried).

So JAL is great, however, as the 16F193x family is rather new based on a
brand new core, it is a good question if JAL is updated for that already or
just compiles code as it was a normal Midrange core.


> It's a superb optimising compiler. Unless you are Olin, you will not do
> as well in Assembler even if the compiler is ignoring the odd device
> specific instruction.
>

Right, I did not want to go for religious war here :-) I think I know my
limits, and as started Assembly programming in the mid '80s I am confident
enough to make smaller and faster code than a HLL compiler -- probably takes
more time to me to optimize it properly :-)

Anyway, getting back the original subject, the enhanced core provides
features that an HLL compiler can take advantage of, for example creating a
stack and stack frames fast enough to avoid generating pseudo stack instead,
which then makes the compiled code much smaller and faster if for example a
reentrance needed (for example using printf or other C lib functions from
interrupts, or writing a recursive algorithm etc). So I believe the OP
question is valid with wondering if JAL use these enhanced things.

BTW: Probably the best is to just compile some tests and disassembly the
code and see how it is -- or just analyse it by it's behaviour, like code
size, test how fast is it, if it can take recursive things etc etc etc.

Tamas




{Quote hidden}

>

2011\06\29@063405 by Oli Glaser

flavicon
face
On 29/06/2011 10:21, Michael Watterson wrote:
> I've found all the C compilers produce much larger and sometimes buggy code.

Interesting - do you have some examples of this? Do you really mean every single C compiler?
How much larger? How many more bugs?
I would be interested to see the comparisons if you have some links.

2011\06\29@064600 by Walter Banks

picon face


Oli Glaser wrote:

> On 29/06/2011 10:21, Michael Watterson wrote:
> > I've found all the C compilers produce much larger and sometimes buggy code.
>
> Interesting - do you have some examples of this? Do you really mean
> every single C compiler?

Some old misconceptions take a long time to die.

w..

2011\06\29@073333 by Michael Watterson

face picon face
On 29/06/2011 11:33, Oli Glaser wrote:
> On 29/06/2011 10:21, Michael Watterson wrote:
>> I've found all the C compilers produce much larger and sometimes buggy code.
> Interesting - do you have some examples of this? Do you really mean
> every single C compiler?
> How much larger? How many more bugs?
> I would be interested to see the comparisons if you have some links.
>
I didn't mean ALL c compilers.. Came out wrong:
I meant ones I tried,
Various HiTech C over the years
Microchip's 18F
Mikroe
Something else...

C is designed for "normal" kind of CPU. the 10F to 16F are definitely not ideal (I've been using C on 8051, Z80, x86, ARM, MIPS, Controllers, Linux, DOS, Windows etc since MS C in 1988 on DOS).  C also designed as a general purpose portable "Macro Assembler like tool" to enable easy port of UNIX and UNIX apps to different CPUs.

JAL specifically designed for controller type applications and 16F in particular. It has maybe 3 or 4 less usual constructs that make life nice for controller programming  ('get, 'put, the "at" to alias a variable to address of a different type of variable, a bit like a C union, using 'get and 'put to implement array indexed device drivers)

So you'd expect JAL to do better than C on 10F to 18F. If there was a JAL for other higher end PICs, MIPS, ARM etc, I'd expect it to be a poorer option than C for those CPUs.

2011\06\29@080044 by cdb

flavicon
face


:: JAL specifically designed for controller type applications and 16F
:: in particular

I found Sergio Masci's XCSB excellent at producing tight code for the 16F series. I thought it a shame that a wider audience wasn't of the same opinion.

Colin
--
cdb, colinspamKILLspambtech-online.co.uk on 29/06/2011
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 

2011\06\29@081809 by Michael Watterson

face picon face
On 29/06/2011 13:00, cdb wrote:
> I found Sergio Masci's XCSB excellent at producing tight code for the 16F
> series. I thought it a shame that a wider audience wasn't of the same
> opinion.
>

Perhaps a wide enough audience didn't know about it?  Link?
Does it do 18F, which really will be only one I'm  using in PIC

(Though I've probably got too much code invested in JAL now

2011\06\29@082213 by mcd

flavicon
face
Michael Watterson wrote:

> C is designed for "normal" kind of CPU.

AMAZING.  Somebody else "gets" it.

My observation is a little different.  I have found most of the compilers
produce some very elegant code in some cases, and tolerable code most of
the time.  But most also produce some really pathological code in some
situations.  This "works most of the time" behavior can be terribly
frustrating.

Each compiler seems to have different cases where it goes nuts, but they
all seem to be related to attempting to comply with implementation details
required by the ANSI standard that make no sense on an embedded system.

The exception seems to be SDCC.  It almost never produces good code, but
as best I can tell, it never seems to come up with pathological code,
either.

--McD

2011\06\29@090219 by Michael Watterson

face picon face
On 29/06/2011 13:27, .....mcdKILLspamspam.....is-sixsigma.com wrote:
> The exception seems to be SDCC.  It almost never produces good code, but
> as best I can tell, it never seems to come up with pathological code,
> either.
>

Ah yes.. I looked at it.
Some promise, but basically a work in progress. I think it's the worst for PIC.
If you really want to do C, Hitech C (now bought by Microchip) might be best.
I  think I may even used a Z80 version back in late 1980s.
On 16F877 once it produce code for a case statement that was wrong. We never figured why. Looking at the Assembler we could see the logic was wrong.
Replacing the offending section with a bunch of "ifs" fixed it. That's the only really memorable "bug".

I've ported even some parts of Linux application C code for x86 to JAL and also VB6 on Windows fairly painlessly, so even if you have a lot of existing C code for 8051 or something, it's no big deal to re-write for JAL, and maybe find a bug or two that slipped by before.

I really really didn't like the 8051. Back in early 1980s I was also using NEC 78C11 (six galvanically isolated slave controllers for I/O on Z80 master CPU). I used its Macro Assembler to build a Forth like environment and wrote 16bit math library in assembler for it. (only match instructions 8 bit add, shifts, and  complement) It was easier to work with even though no ICD than the 8051 with ICD and assembler or C.

2011\06\29@122855 by Bob Axtell

face picon face
On 6/29/2011 2:21 AM, Michael Watterson wrote:
{Quote hidden}

Thanks, Michael. Nicely analyzed.

I think you and I are almost identical. Over the years I have written some beautiful and elegant
PIC code for the mid-range PIC (PIC16F/PIC12F) and stored each module. So, in essence,
I HAVE a higher-level language. But the PIC16F1939 has some significant differences, such
that I'd have to rewrite and retest almost all of my "library". That task will be a significant one.

So, knowing this, I simply wanted to VERIFY that all that work had been done on JALv2. 'cause
if it hadn't, then it would be faster to code in MPASM. Its that simple. I didn't want a war, just
a verification.

--Bob A


.

2011\06\29@130730 by Byron Jeff

flavicon
face
Bob,

It should be too difficult to generate some test code and see what assembly
the compiler outputs. Since the JAL libaraies are written in JAL, and not
assembly, if the optimizations are done for any piece of code, then they'll
be done for the libraries too upon compilation.

BAJ

On Wed, Jun 29, 2011 at 12:28:43PM -0400, Bob Axtell wrote:
{Quote hidden}

> -

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