Post by thread:[PIC] Anybody else using PIC19F193X?

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 > -

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

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

On Wed, Jun 29, 2011 at 8:22 AM, Rob Hamerling <spam_OUTrobhamerlingTakeThisOuTgmail.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}> > 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.nl >

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.

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

On Wed, Jun 29, 2011 at 10:21 AM, Michael Watterson <.....mikeKILLspam@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}> > 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. > > > > > >

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.

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

On 29/06/2011 13:27, .....mcdKILLspam.....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.

On 6/29/2011 2:21 AM, Michael Watterson wrote: {Quote hidden}> 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. > > > > > 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 .

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}> On 6/29/2011 2:21 AM, Michael Watterson wrote: > > 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. > > > > > > > > > > > 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 > > > . > -