preliminary k107.jal library

[Wayne Topa]

Most honorable JalList Guru's

I have attached my draft library for the k107. I still have to put in
the descriptive text but the library does compile but is, as of today,
untested.

I am sending it now so that TPTB (The Powers That Be) can make
suggestions as to what has to be changed to conform to your standards.

Please be critical! I want to learn! I won't mind a kick in the butt if
I deserve it.

Thanks

Wayne

[Sebastien Lelong]

Hi Wayne,

First of all, the filename itself should contain "lcd". I think "lcd_k107.jal" would be ok, following this section from JSG (http://code.google.com/p/jallib/wiki/JallibStyleGuide, section "Rules of Thumb/Filenames"):

"""
<device-family>_<device>.jal for external libraries [this is the case here, right ?]. device-family describes the device family (...), and is often the directory name where the lib is. device precisely sets the part.

Ex: lcd_hd44780_4.jal, rtc_ds1302.jal, co2_t6603.jal
"""


JSG validator also says ("jallib validate k107.jal"):

"""
File: k107.jal
2 errors found
        ERROR: Cannot find end of field content Description
        ERROR: 105: Found Capitals in token: 'k107_CR'

0 warnings found
"""

Mmmh... OK, so "k107_CR" should be "k107_cr". This other error is trickier: it can't find "Description" field, while there's one ! Why ? Actually, it can find the end of the section, so the whole section is ignored. Adding a "--" at the end fixes the problem:

--    Directions for use of this library in application programs
--    (in this sequence):
--    <==== THIS ONE :)


About k107_init, it takes an argument for the geometry. I guess it describes the number of rows and columns. Ex: 416 is a 4 rows and 16 columns LCD, right ? I would have preferred specifying rows and cols separately, maybe more user-friendly. But that's a matter of taste !

Thinking again about your "case" impl., I wonder how defining both "var byte cmd[]" and "const byte cmd[]" behaves... More, if "geo" can be 416 or 420, then it must be a "word", not a "byte". And here I've found interesting things... Here's a program I've written including unittest:

  - test_orig.jal: I took your case, and adapt it so I can run unittests on it. Basically, I removed arrays

 If you have last jallib from trunk, jallib.py and PICShell installed with correct PYTHONPATH, you can run:

    python jallib.py unittest test_orig.jal

this will give:

test_orig.jal compiled, running tests...
test_test : OK
test_geo : FAIL, 416 != 0


(you can also use PICShell's GUI)

Mmmh... cmd is 0, that is the initialized value. Weird. Does "var byte cmd" and "const byte cmd" are allowed on the same scope ? It seems not, and it seems logical. When using block... end block, a new scope is created. Looks like your const assignement has fade away.

Another test:

  - test_noconst.jal : I remove "const", that I directly assign to "cmd" being declared as "var byte cmd" before the "case". Also converted byte to word as needed.

Results are:

test_noconst.jal compiled, running tests...
test_test : OK
test_geo : OK


Good ! Another test...

  - test_noconst_noassign.jal : removed cmd assignement to 0.

Results:

test_noconst_noassign.jal compiled, running tests...
test_test : OK
test_geo : FAIL, 416 != 160


Weird ! Looks like it ate some of the bits, just as though it couldn't handle "word" in the case. Last test

  - test_byteonly.jal: same as before, but with "byte"

Results:

test_byteonly.jal compiled, running tests...
test_test : OK
test_geo : OK


It works !

This should be tested for real to check, but if I were you, I would dig this "case", there are weird things about it.

Sorry for this very long and cryptic mail :) Hope it helps though.


Cheers,
Seb

2009/6/10 Wayne Topa <linu...@gmail.com>

-- -----------------------------------------------------------------------------
-- Title: LCD library for the k107 Serial Backpack
-- Author: Wayne Topa, Copyright (c) 2008..2009, all rights reserved.
-- Adapted-by:
-- Compiler:  >=2.4k
--
-- This file is part of jallib (http://jallib.googlecode.com)
-- Released under the ZLIB license (http://www.opensource.org/licenses/zlib-license.html)
--
-- Sources:
--
-- Description:
--    Serial interface for K107 (and similar) serial LCD backpack for
-- 2x16 to 4x20 HD44780 compatible alphanumeric LCD displays.
-- .
--    Expects: - 1 pin from Pic to K107
-- .
--    Directions for use of this library in application programs
--    (in this sequence):


-- define in calling program or here ???
const byte K107_CHARS = 20
var byte i
-- var byte cmd[]

procedure k107_init(byte in  geo) is
   var byte cmd[]
   case geo of
       216: block const byte cmd[] = "?G216" end block
       220: block const byte cmd[] = "?G220" end block
       224: block const byte cmd[] = "?G224" end block
       240: block const byte cmd[] = "?G240" end block
       416: block const byte cmd[] = "?G416" end block
       420: block const byte cmd[] = "?G420" end block
   end case
   for 5 using i loop
       serial_sw_write(cmd[i])
   end loop
--  delay required when writing to K107 EEPROM
   delay_100ms(2)
end procedure

-- Tab size can be 1-8
procedure k107_tabsize(byte in tab) is
   serial_sw_write("?")
   serial_sw_write("s")
   serial_sw_write(tab)
   delay_100ms(2)
end procedure

procedure k107_cursor_style(byte in c_style) is
   serial_sw_write("?")
   serial_sw_write("c")
   serial_sw_write(c_style)
   delay_100ms(2)
end procedure

-- Back Light settings 00 to FF hex. Use 80 or less normally
procedure k107_backlight(byte in bl) is
   serial_sw_write("?")
   serial_sw_write("s")
   serial_sw_write(bl)
end procedure

-- goto line

procedure k107_goto_line(byte in ln) is
   serial_sw_write("?")
   serial_sw_write("y")
   serial_sw_write(ln)
end procedure

-- goto column

procedure k107_goto_column(byte in cl) is
   serial_sw_write("?")
   serial_sw_write("x")
   serial_sw_write(cl)
end procedure

--  home cursor

procedure k107_home() is
   serial_sw_write("?")
   serial_sw_write("a")
end procedure

-- CLRF, cursor at start of line, line cleared

procedure k107_clrf() is
       serial_sw_write("?")
       serial_sw_write("n")
end procedure

-- tab, advances display one tab postiion

procedure k107_tab() is
   serial_sw_write("?")
   serial_sw_write("t")
end procedure

-- carrage return, cursor to start of current line

procedure k107_CR() is
   serial_sw_write("?")
   serial_sw_write("m")
end procedure

-- clear current line, cursor to start of current line

procedure k107_clr_line_home() is
   serial_sw_write("?")
   serial_sw_write("l")
end procedure


-- clear screen and leave cursor at home position

procedure k107_clear() is
   serial_sw_write("?")
   serial_sw_write("f")
end procedure

-- Non-destructive backspace

procedure k107_cur_back_1_no_del() is
   serial_sw_write("?")
   serial_sw_write("h")
end procedure

-- destructive backspace

procedure k107_cur_back_1_del() is
   serial_sw_write("?")
   serial_sw_write("b")
end procedure

-- forward cursor

procedure k107_cur_forward_1() is
   serial_sw_write("?")
   serial_sw_write("i")
end procedure

-- down cursor

procedure k107_cur_down_1() is
   serial_sw_write("?")
   serial_sw_write("j")
end procedure

-- up cursor

procedure k107_cur_up_1() is
   serial_sw_write("?")
   serial_sw_write("k")
end procedure

--
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org

[Wayne Topa]

Sebastien Lelong wrote:
> Hi Wayne,
>
> First of all, the filename itself should contain "lcd". I think
> "lcd_k107.jal" would be ok, following this section from JSG (
> http://code.google.com/p/jallib/wiki/JallibStyleGuide, section "Rules of
> Thumb/Filenames"):
>

Yes, I remembered as soon as i read it, lcd_k107.jal it is

> """
> <device-family>_<device>.jal for external libraries [this is the case here,
> right ?]. device-family describes the device family (...), and is often the
> directory name where the lib is. device precisely sets the part.
>
> Ex: lcd_hd44780_4.jal, rtc_ds1302.jal, co2_t6603.jal
> """

I have renamed all procedures per your examples.

>
> JSG validator also says ("jallib validate k107.jal"):
>
> """
> File: k107.jal
> 2 errors found
> ERROR: Cannot find end of field content Description
> ERROR: 105: Found Capitals in token: 'k107_CR'
>
> 0 warnings found
> """

>
> Mmmh... OK, so "k107_CR" should be "k107_cr". This other error is trickier:
> it can't find "Description" field, while there's one ! Why ? Actually, it
> can find the end of the section, so the whole section is ignored. Adding a

^^ do you mean can't??

> "--" at the end fixes the problem:
>
> -- Directions for use of this library in application programs
> -- (in this sequence):
> -- <==== THIS ONE :)

Sorry I'm not understanding that-----

k107_CR has been changed to lcd_k107_cr

>
> About k107_init, it takes an argument for the geometry. I guess it describes
> the number of rows and columns. Ex: 416 is a 4 rows and 16 columns LCD,
> right ? I would have preferred specifying rows and cols separately, maybe
> more user-friendly. But that's a matter of taste !
>

As the k107 only accepts 6 different geometrys, I thing it is better
if this is changed to lcd_k107_init(byte geo) , The gom arg would be a
number between 1 & 6.

> Thinking again about your "case" impl., I wonder how defining both "var byte
> cmd[]" and "const byte cmd[]" behaves... More, if "geo" can be 416 or 420,
> then it must be a "word", not a "byte". And here I've found interesting
> things... Here's a program I've written including unittest:

Yes I forgot to change it when the if,elseif code would not compile.

All the unittest is interesting but I can't get that to run here.
>

I keep coming up with very strand errors when using the library.
ie:

const byte LCD_CHARS =20 (Which is also declared in serial_sw_write)
which I include before the lcd_k107

If I declare it in the sample program, I get errors in the lcd_k107.jal
LCD_CHARS not declared

If I declare it in the library
var byte init1[LCD_CHARS] = "?G216" -- Compiler says constant expected

But it seems to work ok in the sample 16f648a_lcd_hd44780_4_1.jal which
it that way.
var byte line1[LCD_CHARS] = "<= 2 x 16 LCD =>"

Maybe the compiler does not like the? (?????)

I tried to replace the case part of lcd_k107_init with the it/elseif
and I get elseif not declared. It's in the use guide so I must just be
screwing things up. I don't know how tho.

I plan to put the lib aside, for now, and concetrate on the sample
program. I will switch to assembly if necessary. I have 8-10 LCD's and
4 K107's so I have to get something working soon. I am not getting younger.

Thanks for the pointers Seb. I really appreciate the guidance.

Regards

Wayne

[funlw65]

elseif must be elsif ?

[Wayne]

Sebastien Lelong wrote:
> Hi Wayne,
>
> First of all, the filename itself should contain "lcd". I think
> "lcd_k107.jal" would be ok, following this section from JSG (
> http://code.google.com/p/jallib/wiki/JallibStyleGuide, section "Rules of
> Thumb/Filenames"):
>
> """
> <device-family>_<device>.jal for external libraries [this is the case here,
> right ?]. device-family describes the device family (...), and is often the
> directory name where the lib is. device precisely sets the part.
>
> Ex: lcd_hd44780_4.jal, rtc_ds1302.jal, co2_t6603.jal
> """
>
>
> JSG validator also says ("jallib validate k107.jal"):
>
> """
> File: k107.jal
> 2 errors found
> ERROR: Cannot find end of field content Description
> ERROR: 105: Found Capitals in token: 'k107_CR'
>
> 0 warnings found
> """

I changed the sample progrms to comply, I hope.

> Mmmh... OK, so "k107_CR" should be "k107_cr". This other error is trickier:
> it can't find "Description" field, while there's one ! Why ? Actually, it
> can find the end of the section, so the whole section is ignored. Adding a
> "--" at the end fixes the problem:
>
> -- Directions for use of this library in application programs
> -- (in this sequence):
> -- <==== THIS ONE :)
>
>
> About k107_init, it takes an argument for the geometry. I guess it describes
> the number of rows and columns. Ex: 416 is a 4 rows and 16 columns LCD,
> right ? I would have preferred specifying rows and cols separately, maybe
> more user-friendly. But that's a matter of taste !
>

Yes the init is to program the k107 16f628a/648a eeprom to set it up for
a 4x20 LED (in this example). There are seperate row and col routines
that go 'directly' to the LCD. the init, a 3 other routines, are ysed
once to program the k107 eeprom and are not needed again unless you
change LCDs. ie change a 4x20 to 2x24 requires a change in the k107 chip.

I have added more information under the "Directions for use".

Done! ??? dig = dump? as in throw away this junk code? :-)

> Sorry for this very long and cryptic mail :) Hope it helps though.

No need to be sorry. This is what I was hoping for. I have

This was removed and seperate routines to intitalize are put into the
sample programs. see below

>> procedure k107_init(byte in geo) is
>> var byte cmd[]
>> case geo of
>> 216: block const byte cmd[] = "?G216" end block
>> 220: block const byte cmd[] = "?G220" end block
>> 224: block const byte cmd[] = "?G224" end block
>> 240: block const byte cmd[] = "?G240" end block
>> 416: block const byte cmd[] = "?G416" end block
>> 420: block const byte cmd[] = "?G420" end block
>> end case
>> for 5 using i loop
>> serial_sw_write(cmd[i])
>> end loop
>> -- delay required when writing to K107 EEPROM
>> delay_100ms(2)
>> end procedure

in addition to the init routine
The 3 functions, below, have been removed from the library. They are
used only when first initializing a particular LCD. Once initialized
the code is no longer needed so why use the code space.

>> -- Tab size can be 1-8
>> procedure k107_tabsize(byte in tab) is
>> serial_sw_write("?")
>> serial_sw_write("s")
>> serial_sw_write(tab)
>> delay_100ms(2)
>> end procedure
>>
>> procedure k107_cursor_style(byte in c_style) is
>> serial_sw_write("?")
>> serial_sw_write("c")
>> serial_sw_write(c_style)
>> delay_100ms(2)
>> end procedure
>>
>> -- Back Light settings 00 to FF hex. Use 80 or less normally
>> procedure k107_backlight(byte in bl) is
>> serial_sw_write("?")
>> serial_sw_write("s")
>> serial_sw_write(bl)
>> end procedure
>>
>> -- goto line

The column procedure is stumping me so is not included in the current
library.

I have to call the go to column routine with with bytes and I'm not
happy with the methods I have tried. The column number is 2 digits
00 up to 49. This is why I did not use it in the samples.
I have looked at & tried many variations but am still not satisfied
with the results.

it could be
var byte ln_col[] = ("?y{0-3}?x{00-39}")
so the use would be
for COUNT(ln_col) using i loop
serial_sw_write(ln_col[i])
end loop
This could be done in a program but I can't figure out how to do it,
nicely, in the library.


>> -- goto column
>> This prodedure does not work!!! DUMP IT

>> procedure k107_goto_column(byte in cl) is
>> serial_sw_write("?")
>> serial_sw_write("x")
>> serial_sw_write(cl)
>> end procedure

> serial_sw_write("a")
>> end procedure

Thank's for the comments, they are really appreciated!!!

I am attaching a photo that shows the a static view of a display.
The samples I have, for the 628a, 88 and 688 have the screen rewritten
for


Best Regards

Wayne

[Wayne]

Sebastien Lelong wrote:
> Hi Wayne,
>
>

>> (1)---------------
>> Assuming that the col is 12
>>
>> var byte clm[] = "12"
>> lcd_k107_col(clm[]) -- don't even know if this is correct
>>
>> procedure lcd_k107_col(byte in clm) is
>> serial_sw_write("?")
>> serial_sw_write("y")
>> for (COUNT(clm) using i loop
>> serial_sw_write(clm[i])
>> end loop
>> this works but is not as efficient as I would like
>> which just seems like it requires too much code space
>>
>
> If col is 12, why don't you pass 12, the integer ? Your procedure then has
> to translate this to "1" and "2" (divide by 10, blablabla). Maybe you can
> even use print.jal or format.jalprint.jal for this. Or did I misunderstand something
> ?

Because I did not find any samples of how to use print.jal or format.jal
with serial_sw_write. I don't really understand enough to figure that out.

I would like to know if they would work though.

>
>> (2)------------------------
>> why not do it in the program
>> var byte line_col[] = ("?y02?x12")
>> for COUNT(line_col[])
>> serial_sw_write to send the string
>> done
>>
>
> I would consider this as a "leak" API. User doesn't have to care about how
> it works behind the scene.
>
>
>> If you want the line done by itself the string would be "?y02"
>> if you want to change the # "4" at that line then ""?y##5"
>>
>> I have attached the latest samples, Lib and a picture of what the display
>> shows. You will notice that i have not used any of the
>> library routines. The mow code I write, I find that I have not needed any
>> of them. Admittedly, I have only done the samples and a preliminary
>> screen for my application in which I have, currently, 4 screens. Each
>> screen has fixed text and I only change values on each screen (go to line &
>> column rewrite results). The screens rotate every 10 seconds
>> now but I want to incorporate 4 push buttons to call up any one I want to
>> continuously monitor.
>
>
> Sorry but I don't have much time right now to dive into this... These
> Jallib/Jaluino books are taking all my time, I didn't write a single jal
> line code for two months :)

Well I believe that the lcd_k107.jal is usable , as is, to add to the
library. You have the samples and the library. I leave it to you, or
some other developer, to make that decision. I am using it in my
application now. But, IFAIK, I'm the only one that has any k107
Backpacks to experiment with. :-( Maybe if it is added, and people
know it is in jallib, we will have others to test it too.

If I learn enough from the Tutorial books, maybe then I can use the
print.jal or format.jal to do as you suggest. I open to suggestions
and hints.

Thanks and regards

Wayne

PS I hope that this gets to the list as well as to you Seb.
>
> Cheers,
> Seb
>
>
>
>
>>> Cheers,
>>> Seb
>>>
>>> 2009/11/23 Wayne <linu...@gmail.com>

>>>> -- Compiler: >=2.4l

>>>> --
>>>> -- This file is part of jallib (http://jallib.googlecode.com)
>>>> -- Released under the ZLIB license (
>>>> http://www.opensource.org/licenses/zlib-license.html)
>>>> --
>>>> -- Sources:
>>>> --
>>>> -- Description:
>>>> -- Serial interface for K107 (and similar) serial LCD backpack for

>>>> -- 2x16, 20, 24 or 40 characters as well as 4x16 or 20 character
>>>> -- HD44780 compatible alphanumeric LCD displays.
>>>> -- .
>>>> -- Expects: - 1 pin from Pic to K107 and +5 and Gnd.

>>>> -- .
>>>> -- Directions for use of this library in application programs
>>>> -- (in this sequence):
>>>>
>>>>

>>>> var byte i
>>>>
>>>>
>>>>
>>>> -- home cursor
>>>> procedure lcd_k107_home() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("a")
>>>> end procedure
>>>>
>>>> -- CLRF, cursor at start of line, line cleared

>>>> procedure lcd_k107_clrf() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("n")
>>>> end procedure
>>>>
>>>> -- tab, advances display one tab postiion

>>>> procedure lcd_k107_tab() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("t")
>>>> end procedure
>>>>
>>>> -- carrage return, cursor to start of current line

>>>> procedure lcd_k107_cr() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("m")
>>>> end procedure
>>>>

>>>> -- clear current line, cursor goes to start of current line
>>>> procedure lcd_k107_clr_line_home() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("l")
>>>> end procedure
>>>>
>>>> -- clear screen and leave cursor at home position

>>>> procedure lcd_k107_clear() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("f")
>>>> end procedure
>>>>
>>>> -- Non-destructive backspace

>>>> procedure lcd_k107_cur_back_1_no_del() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("h")
>>>> end procedure
>>>>
>>>> -- destructive backspace

>>>> procedure lcd_k107_cur_back_1_del() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("b")
>>>> end procedure
>>>>
>>>> -- forward cursor

>>>> procedure lcd_k107_cur_forward_1() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("i")
>>>> end procedure
>>>>
>>>> -- down cursor

>>>> procedure lcd_k107_cur_down_1() is
>>>> serial_sw_write("?")

>>>> serial_sw_write("j")
>>>> end procedure
>>>>
>>>> -- up cursor

>>>> procedure lcd_k107_cur_up_1() is
>>>> serial_sw_write("?")
>>>> serial_sw_write("k")
>>>> end procedure
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>

[Joep Suijs]

2009/11/24 Wayne linu...@gmail.com

Because I did not find any samples of how to use print.jal or format.jal
with serial_sw_write.  I don't really understand enough to figure that out.

I would like to know if they would work though.

 

Just init the serial software comms like you do now and use serial_sw_data as the first param in stead of serial_hw_data.

Haven't tested this, but it should work...

 

Joep

[Wayne]

And it does!!!

Thank YOU joep, that makes everything much simpler!

format and print were like black magic before. It was not obvious, to
me, that the calls to serial_hw would work with serial_sw.

Many thanks!!!!

Wayne

[Wayne]

I am integrating a Maxim DS18B20 into my application and asked on
jallist if anyone had a jallib lib they were working on. I got a
response, with a link, to one that Helge<hel...@start.noHelge> had
modified from on that Stef had written back in 2002/4.

In looking at the application I noticed that Helge also had a problem
getting 9600 baud with a 4 MHZ clock on a 16c84. He had this in the code
const serial_sw_baudrate = 10400 (this is really 9600 baud).

I just tried that with the 16f628a_lcd_k107sample.jal. What do you know,
the k107 communicates with LCD now with a 4 MHZ Crystal.

I am reporting this but wish I had the answer as to why this works. I
also hope that someone else wanting to work at 9600 baud can use the
information above.

I still can't use it on the 12f509 due to the lack of INTCON_GIE
which is required by the serial_software.jal lib but sure would like to.
:-)

Best Regards

Wayne

[Joep Suijs]

Hi Wayne,

 

It seems that we have to dig deeper into this.

The only cause I can think of is the bit calculation overhead that adds to each bit. Hower to verify this, I need time and my tools, which both are currently unavailable due to some serious redecoration at home ;)

However, if you create an issue on googlecode, I'll look into serial_software baudrates at lower clock rates some day.

 

And about INTCON_GIE. This is used to disable interrutps. If your pic doesn't have interrupts or you don't use them, you can just define a bit var with this name. If your pic has interrupts and you use them, they have to be disabled. You can do this yourself (and define the var) or use the pseudo-var construct. I can provide you with some sample code if you want.

 

Joep

2009/11/28 Wayne <linu...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "jallib" group.
To post to this group, send email to jal...@googlegroups.com.
To unsubscribe from this group, send email to jallib+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jallib?hl=en.

[Wayne]

Joep Suijs wrote:
> Hi Wayne,
>
> It seems that we have to dig deeper into this.
> The only cause I can think of is the bit calculation overhead that adds to
> each bit. Hower to verify this, I need time and my tools, which both are
> currently unavailable due to some serious redecoration at home ;)
> However, if you create an issue on googlecode, I'll look into
> serial_software baudrates at lower clock rates some day.
>

I understand :-) Been there done that.

I will create an issue.

> And about INTCON_GIE. This is used to disable interrutps. If your pic
> doesn't have interrupts or you don't use them, you can just define a bit var
> with this name. If your pic has interrupts and you use them, they have to be
> disabled. You can do this yourself (and define the var) or use the
> pseudo-var construct. I can provide you with some sample code if you want.

I looked at the data sheets and 'thought' that I might be able to do
what you say. I wasn't sure but 'hoped' that if I mentioned it you
would suggest a workaround, you are very good at that you know. :-)))

Thanks for your help, again!

Have a nice weekend

Best Regards

Wayne

>> jallib+un...@googlegroups.com<jallib%2Bunsu...@googlegroups.com>
>> .

[Rob Hamerling]

Hi Joep,

Joep Suijs wrote:

> And about INTCON_GIE. This is used to disable interrutps. If your pic
> doesn't have interrupts or you don't use them, you can just define a bit
> var with this name.

Suggested library improvement: check for existence of GIE with

if defined(INTCON_GIE)

Simple solution, works for all PICs.

Regards Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)

[Joep Suijs]

Does the absence of INTCON_GIE means interrupts are not supported by this pic? Or are there pics around with interrupts but without INTCON_GIE?

If not INTCON_GIE means no interrupts, the libarary improvement is a good idea indeed.

 

Joep

2009/11/28 Rob Hamerling <robham...@gmail.com>

[Rob Hamerling]

On Sat, Nov 28, 2009 at 8:26 PM, Joep Suijs <jsu...@gmail.com> wrote:
> Does the absence of INTCON_GIE means interrupts are not supported by this
> pic? Or are there pics around with interrupts but without INTCON_GIE?
> If not INTCON_GIE means no interrupts, the libarary improvement is a good
> idea indeed.

A GREP for INTCON in the directory with device files shows which PICs
have interrupts. I'm not sure
that the reverse (no INTCON no interrupts) is true as well. But there
are not that many PICS without INTCON, so a check of the datasheets is
not much work.

Regards, Rob.

--
Rob Hamerling, Vianen, NL (http://www.robh.nl)

[Wayne]

Joep Suijs wrote:
> Hi Wayne,
>
> It seems that we have to dig deeper into this.
> The only cause I can think of is the bit calculation overhead that adds to
> each bit. Hower to verify this, I need time and my tools, which both are
> currently unavailable due to some serious redecoration at home ;)
> However, if you create an issue on googlecode, I'll look into
> serial_software baudrates at lower clock rates some day.
>
> And about INTCON_GIE. This is used to disable interrutps. If your pic
> doesn't have interrupts or you don't use them, you can just define a bit var
> with this name. If your pic has interrupts and you use them, they have to be
> disabled. You can do this yourself (and define the var) or use the
> pseudo-var construct. I can provide you with some sample code if you want.

Sample code is always welcomed, here! I learn faster that way.

I added var bit intcon_gie but the serial software lib keeps complaining
about 'intcon_gie' not defined. Then I pulled my head out of my --- and
put it before the include serial_software. Now i have '_irp' & '_plath'
errors and also what I was afraid of 'Out of data space'. I may be able
to fix that though if I can get rid of the other errors.

One reason I was asking about the documentation so much was that answers
to the questions I have asked you in the past were, in my opinion, not
available to the novice JALv2 programmers, which I am. I have wanted to
suggest that jallib start a FAQ section but hesitated due to the
workload all of you Guru's have now.


Thanks again Joep. I hate bothering you on the weekend tho. No rush on
the sample code, take your time

Wayne

>> jallib+un...@googlegroups.com<jallib%2Bunsu...@googlegroups.com>
>> .

[Joep Suijs]

Hi Wayne,

Iirc I did not send you the code yet (so it is long overdue...)

Procedure PwmIrLed() acts like the pin for software_serial. But it is
not just a pin, it enables and disables pwm on ccp2. And it s ets the
pwm-pin c1 low when pwm is turned off, so the leds are actually off
(and not continuous on).

Joep

PS I changed the serial_software timing. Can you verify if it works
okay now for your k017 library?

-- ir_sender.jal

-- PwmIrLed - pulse led @ 56kHz or put it off.
procedure PwmIrLed'put(bit in ii) is
if (ii) then
ccp2con = 0x0c ; pwm mode on
else
ccp2con = 0x00 ; pwm mode off
pin_c1 = low
end if
end procedure

-- ----------------------------------------------------------------------------
; setup serial_sw to pulse the IrLed
const bit serial_sw_invert = false
const serial_sw_baudrate = 1200
const serial_sw_stopbits = 0 -- don't send stop bits (actually, don't let the
-- serial routine *wait* for the stop bit)
var bit serial_sw_rx_pin
alias serial_sw_tx_pin is PwmIrLed
include serial_software

pin_c1_direction = output ; IrLed pin

; setup pwm for the IR led
T2CON = 4 ; timer 2 on, prescaler = 1, postscaler = 1
PR2 = 88 ; create 56 kHz pulse
ccpr2l = 44 ;

-- ----------------------------------------------------------------------------

[Wayne <linuxtwo@gmail.com>]

Joep Suijs wrote:
> Hi Wayne,
>

Sorry but I have been busy trying to get a wireless networking and have
not had any time lately for my jal hobby,
>

Joep

I am confused. The code I 'thought' you were sending was to help get
rid of the INTCON_GIE errors I was getting on some of the 8 pin chips
ie the 12f509 IIRC.

Does the ir_sender procedure help with that???? If it does, I have been
away from jal for too long.

Sorry for the cc: but I don't think my mail is getting to the list when
I originate it, it seems to be OK, sometimes, if I reply only.

I never know if my mail is getting through because if no one replies, I
think nobody cares.

I an going to test the 4MHz clocks ASAP. I WILL let YOU know.

Happy New Year

Wayne

[Wayne <linuxtwo@gmail.com>]

Joep Suijs wrote:
> Hi,
>
> Happy new year to you all!
>
> You are right, this is not the code I should have sent. But... I don't
> know what I intended in the first place - my best current guess is
> that I intended to use conditional compile and not pseudo-vars.
> I'll look into this later.
>
> Joep
>
> 2010/1/4 Wayne <linu...@gmail.com> <linu...@gmail.com>:

>> Joep Suijs wrote:
>>> Hi Wayne,
>>>

>>> Iirc I did not send you the code yet (so it is long overdue...)
>>>
>>> Procedure PwmIrLed() acts like the pin for software_serial. But it is
>>> not just a pin, it enables and disables pwm on ccp2. And it s ets the
>>> pwm-pin c1 low when pwm is turned off, so the leds are actually off
>>> (and not continuous on).
>>>
>>> Joep
>>>
>>> PS I changed the serial_software timing. Can you verify if it works
>>> okay now for your k017 library?

Joep

Sir, I am happy to inform you that the changes you made to the
serial_software timing were successful. I am now able to run the
16f628a_lcd_k107_sample at 4MHz.

Thanks again for your efforts.

Wayne