Congrats to the jallib team
sunish
Its after a long time that I happened to use JAL, and I tried jallib.
Excellent
work, this is something that I wished for from jal for a long long
time.
I convereted my old code and I could do it with unbelieveable ease. I
tried changing PICs by just changing the include file, changed serial
baud rates and everthing worked just as expected.
Just a few suggestions,
1) We can have all the old jal v0.4 and jalv2 examples converted so
that its available as examples.
2) We need a site and a complete installer with JALV2 compiler,
IDE,simulator, jallib, samples and documentation.
3) More publicity, great effort from Kyle on the compiler and the
jalllib team should really be spread by web publicity.
4) The examples should cover all peripherals and generic stuff like
interrupts. I spent some time to get interrupts working, of course it
was my error but having a sample should have saved time.
Best regards,
Sunish
Sebastien Lelong
Thanks for your feedback !
> I convereted my old code and I could do it with unbelieveable ease. I
> tried changing PICs by just changing the include file, changed serial
> baud rates and everthing worked just as expected.
where we explain how to use jallib (and probably more...), if you
want, you could also write a post to explain how you do this. Or just
expose how do you feel using jallib, etc... Let me know !
> Just a few suggestions,
> 1) We can have all the old jal v0.4 and jalv2 examples converted so
> that its available as examples.
jallist file's section ?...
> 2) We need a site and a complete installer with JALV2 compiler,
> IDE,simulator, jallib, samples and documentation.
having simple web interface/app.
> 3) More publicity, great effort from Kyle on the compiler and the
> jalllib team should really be spread by web publicity.
(http://freshmeat.net/projects/jalv2/ and http://freshmeat.net/projects/jallib/),
which is quite visited and used as a feeder for many (oh many...)
other sites. Do you have any suggestions ?
> 4) The examples should cover all peripherals and generic stuff like
> interrupts. I spent some time to get interrupts working, of course it
> was my error but having a sample should have saved time.
slave), and still can't get it work... Could you post a sample ?
(remember in google groups, you can attach files...).
Cheers,
Seb
Joep Suijs
>
> I'm currently trying to make interrupts working (for i2c hardware
> slave), and still can't get it work... Could you post a sample ?
> (remember in google groups, you can attach files...).
I have plenty of interrupt based programs (including i2c slave0 so let
me know if I can help.
I'm also working on an lib with timer0 isr (actually, the lib is
ready, just have to make the test program).
Joep
Sebastien Lelong
if you have ready-to-compile sample, for 16f88, that would be perfect...
my current isr can't work, even if confugred to, i can't find why.
seb
2008/12/17, Joep Suijs <jsu...@gmail.com>:
Sébastien Lelong
http://www.sirloon.net
http://sirbot.org
Sebastien Lelong
but not jallib upgraed yet too. upgrading is what (mm currently doing,
and as usual debugging i2c is pita...
iirc eur has used isr too in his software rtc lib. i'll have a look.
thanks!
Rob Hamerling
Hi Seb,
Sebastien Lelong wrote:
>
> if you have ready-to-compile sample, for 16f88, that would be
> perfect...
>
> my current isr can't work, even if confugred to, i can't find why.
Where exactly are you looking for? If any ISR will do: the
serial_hw_int_cts library has 2 interrupt routines.
And I have a program which uses its own time interrupt routine in
addition to this serial_hw_int_cts library.
Regards, Rob.
--
Rob Hamerling, Vianen, NL (http://www.robh.nl/)
Sebastien LELONG
I forgot this one ! I'll have a look too ! Thanks
Seb
Le Wednesday 17 December 2008 21:24:23 Rob Hamerling, vous avez écrit :
> Hi Seb,
>
> Sebastien Lelong wrote:
> > if you have ready-to-compile sample, for 16f88, that would be
> > perfect...
> >
> > my current isr can't work, even if confugred to, i can't find why.
>
> Where exactly are you looking for? If any ISR will do: the
> serial_hw_int_cts library has 2 interrupt routines.
> And I have a program which uses its own time interrupt routine in
> addition to this serial_hw_int_cts library.
>
> Regards, Rob.
--
Sébastien LELONG
http://www.sirloon.net
http://sirbot.org
Sebastien LELONG
Thanks for your help on this. I tried the following:
* enable RCIE interrupt (on receive usart): it works, so it means interrupt
(global) are enabled
* enable i2c interrupt on start/stop works too (but I don't use them usually,
only for debug purpose)
* switching back to i2c without start/stop interrupt, it doesn't work (this
is case at the beginning)
In the last case, interrupts are triggered when there's an address match. So
this may mean there's a address problem. As they say: "i2c problems are
usually a matter of addressing". I've set "0x5C" for both slave and master.
I can't dig more right now, so to be continued.
Seb
Joep Suijs
Address is 0x70.
i2c_receive_byteaddres(0x70, 0x80, 2) should work and give 0x3C 0x01
as an answer (did not verify it though).
Joep
2008/12/18, Sebastien LELONG <sebastie...@gmail.com>:
Sebastien LELONG
I'm still on my i2c problem... I've localized the problem: it's in the
software master. For testing purpose, I've setup a 2 PIC communnication (2
16f88), with an incredible added value: master reads serial and sends a char
through i2c, slave answers the same char + 1, master writes the result to
serial. So you enter "a", you get a "b"
The jallib migrated slave works perfectly (I thought that'd be the tricky
part, but...). I've tested it against my old not-migrated master (using
original Wouter's lib), everything works nice.
When I try to use my migrated master, it just doesn't work. The slave does not
produce any interrupts, as though the address were wrong. I'm probably doing
a nasty mistake, but I can't see which... maybe you'll see the problem.
Attached are my jal files for both master and slave. As you see, address
declared in slave (0x5C) is the same as in the master (as expected, IIUC).
Master uses i2c_level1 with tx/rx buffer.
Another question is: did i2c_software and i2c_level1 been tested with a PIC,
and not only a eeprom ? Joep, I know you did something similar, but it's not
converted yet to jallib. Maybe you have further information now :) ...
Thanks,
Seb
PS: once working, I'll put these 2 files as test files, and write a post to
jalliblog
:wq!
Joep Suijs
> Hi guys,
>
>
> I'm still on my i2c problem... I've localized the problem: it's in the
> software master.
> I've tested it against my old not-migrated master (using
> original Wouter's lib), everything works nice.
So it can be done! It must be timing and probably has to do with clock
streching...
> Attached are my jal files for both master and slave. As you see, address
> declared in slave (0x5C) is the same as in the master (as expected, IIUC).
> Master uses i2c_level1 with tx/rx buffer.
I'll give it a try and see if I can reproduce the problem. I hope I
can, because when I can reproduce it, I'm sure I can solve it!
> Another question is: did i2c_software and i2c_level1 been tested with a PIC,
> and not only a eeprom ? Joep, I know you did something similar, but it's not
> converted yet to jallib. Maybe you have further information now :) ...
I only tested with an eeprom.
Joep
Sebastien LELONG
> Good! I assume you use the software I migrated?
Yes I do
>
> > I've tested it against my old not-migrrated master (using
> > original Wouter's lib), everything works nice.
>
> So it can be done! It must be timing and probably has to do with clock
> streching...
OK, I'll also have a look at this. Maybe _i2c_wait ? I use 100KHz speed.
> > Attached are my jal files for both master and slave. As you see, address
> > declared in slave (0x5C) is the same as in the master (as expected,
> > IIUC). Master uses i2c_level1 with tx/rx buffer.
>
> I'll give it a try and see if I can reproduce the problem. I hope I
> can, because when I can reproduce it, I'm sure I can solve it!
Same here, particularly with i2c :)
Joep Suijs
I have a running configuration here. The main issue is that you have
to call i2c_initialize() before you use the library.
Apart from that:
- I get an 'false' back from your slave, but it works okay with a
16f88 with my own slave code.
- I could not get it to work with your oscillator setup, so I use the
20MHz resonator.
And... if I look at the commented-out mastercode:
;;i2c_start()
;;i2c_transmit_byte(icaddress & 0xFE) -- i2c address for write (for
memory address, within eeprom)
;;i2c_transmit_byte(pc_char)
>> add a restart statement here <<
;;i2c_transmit_byte(icaddress | 0x01) -- i2c address for read (of
memory from eeprom)
;;ic_char = i2c_receive_byte(true)
>> Acking the last byte reading is asking for trouble; nack this one!! <<
;;i2c_stop()
;;serial_hw_write(ic_char)
Joep
Sebastien LELONG
working. Could send me back your files so I can test here ?
Thanks
Seb
Sebastien LELONG
With a 8MHz int osc, it works if I change the _i2c_wait procedure, so it
sleeps 12µs (original value) instead of 3µs. This is because the slave is too
slow, as you suggested.
So, my question now is: how could we make the lib working with an slow
internal osc ? Maybe this 3µs value could be configured ?
At least, many thanks again !
Seb
Le Sunday 21 December 2008 20:00:45 Joep Suijs, vous avez écrit :
Joep Suijs
you give this a try?
But it also surprises me. i2c at 400kHz should be possible and I don't
see what the oscillator has to do with that.
What is the value of the pull-up resistors you're using?
Joep
2008/12/21, Sebastien LELONG <sebastie...@gmail.com>:
Sebastien LELONG
> It is, but it's also wrong. At 100kHz, half a period is 5 us. Could
> you give this a try?
Does not work with 5µs, nor with 6, 7 or 8 :(
The minimum value that works for is 10µs.
> But it also surprises me. i2c at 400kHz should be possible and I don't
> see what the oscillator has to do with that.
Maybe an hardware slave @ 8MHz is too slow to react ?
> What is the value of the pull-up resistors you're using?
2.2K, I think this is in the standard values.
Seb
Joep Suijs
>
> The minimum value that works for is 10µs.
> Maybe an hardware slave @ 8MHz is too slow to react ?
Well... There are few things that are bugging me:
- If it works at 400kHz with 20 mHz osc, why does it not work at 100
kHz with an 8 mHz osc?
- It would be realy crippling if an 16f88 has a high-speed internal
oscillator, but that would not allow the i2c device to run at the
basic 100kHz speed and thus be incompatible with all i2c busses.
- shifting bytes into a register should not be a problem at 100 kHz.
- each bit takes 4x the delay to send. This means that 10us creates a
cycle time of 40 us or 25kHz.
So I think I have to retry this - get an 16f88 i2c slave working at
the internal oscillator, get software i2c master to work with it and
then see what it does with the hardware master...
Although an 12us delay makes it work, I have the idea there is
something else wrong and think it is worth to know what...
Joep
Joep Suijs
You did not set the OSCCON_IRCF to 7, so it has the default value 0.
This means your pic is not running @ 8Mhz but 31.25 kHz. And you can
imagine that's a bit slow for 100kbps I2C...
Joep
2008/12/22, Joep Suijs <jsu...@gmail.com>:
Sebastien Lelong
Seb
Joep Suijs
> Wow... Thanks for this, and sorry not having checked this (I wasn't even
> aware of this).
would pay for it accordingly, I'd make it my job ;)
> This means all my samples using internal osc @ 8Mhz are
> bugged ?
I think so.
> I can remember seeing my led blinking @ 1Hz, as expected, using the
> config in my samples...
The human memory is a strange thing...
But serious: I got on this track since the serial port did not work. I
put a blink-loop at the top and had to reduce the time to 2ms to get a
decent blink. So please re-check your blink example. BTW: Rob uses an
external oscillator...
Joep
Sebastien Lelong
2008/12/22, Sebastien Lelong <sebastie...@gmail.com>:
> Wow... Thanks for this, and sorry not having checked this (I wasn't evenDon't worry - this is what I like to do and am good at. If someone
> aware of this).
would pay for it accordingly, I'd make it my job ;)
:)
The human memory is a strange thing...
> I can remember seeing my led blinking @ 1Hz, as expected, using the
> config in my samples...
But serious: I got on this track since the serial port did not work. I
put a blink-loop at the top and had to reduce the time to 2ms to get a
decent blink. So please re-check your blink example. BTW: Rob uses an
external oscillator...
I used to modify Rob's blink files to adjust osc and speed. I'll double check that this evening.
Seb
Sebastien LELONG
When declaring "pragma target clock 8_000_000" and "pragma target OSC
INTOSC_NOCLKOUT", and :
* not setting OSCCON_IRCF, the LED blinks @1Hz (I swear)
* OSCCON_IRCF = 7, the LED also blinks @1Hz
* OSCON_IRCF = 0, the LED blinks @ ..... I don't know, it's so
slooooowwww.... but setting "pragma target clock 31_250" gives a 1Hz blinking
LED, as expected according to the datasheet (also tested OSCON_IRCF = 1 with
clock 115_000, blinks @ 1Hz as expected too)
What about i2c ? I've tried setting OSCCON_IRCF = 7, as you suggested, and...
it does not work (as expected I'd say).
Reading the datasheet, it's said the INTOSC source is a 8MHz clock (something
like that), and there are postscalers, selected with IRCF. Question now is
why IRCF = 7 by default where the datasheet says it's 0. (not sure this is
good test, but serial_hw_write(OSSCON) give "|", 124 decimal, 1111100 binary
(IRCF = 111 = 7). IRCF = 0 might be the default only for INTRC, not INTOSC...
Seb
Joep Suijs
>
> OK, here are the results of the "blink a led" test(you won't be happy...)
> When declaring "pragma target clock 8_000_000" and "pragma target OSC
> INTOSC_NOCLKOUT", and :
>
> * not setting OSCCON_IRCF, the LED blinks @1Hz (I swear)
> * OSCCON_IRCF = 7, the LED also blinks @1Hz
> * OSCON_IRCF = 0, the LED blinks @ ..... I don't know, it's so
> slooooowwww.... but setting "pragma target clock 31_250" gives a 1Hz blinking
> LED, as expected according to the datasheet (also tested OSCON_IRCF = 1 with
> clock 115_000, blinks @ 1Hz as expected too)
That's good - this did not work like it should, but does now!
>
> What about i2c ? I've tried setting OSCCON_IRCF = 7, as you suggested, and...
> it does not work (as expected I'd say).
I'll work on this.
> Reading the datasheet, it's said the INTOSC source is a 8MHz clock (something
> like that), and there are postscalers, selected with IRCF.
It is. But intosc is not fed into the cpu (see figure 4-6)
> Question now is
> why IRCF = 7 by default where the datasheet says it's 0.
It's not. It's 0, giving 31.25 khz.
> (not sure this is
> good test, but serial_hw_write(OSSCON) give "|", 124 decimal, 1111100 binary
> (IRCF = 111 = 7). IRCF = 0 might be the default only for INTRC, not INTOSC...
I'll check that along the way.
Joep
Sebastien LELONG
Reading this diagram (I'm not an expert, this kind of diagram burns my
brain...), I understand IRCF = 0 with INTOSC is not possible, which is
confirmed reading the datasheet: postscaler allows values from 115KHz to
8MHz, not 31.25KHz.
Maybe (?) when I set clock to 31.25KHz, it switches to INRC instead of
INTOSC... There's no INTRC config in device files. Actually I don't event
know the difference between the two. This is out what I can understand :)
I also need to check, but 115Kbds serial perfectly works with INTOSC@8MHz and
I wouldn't expect it to work @31KHz, so for me by default it really runs
@8MHz.
Cheers,
Seb
Joep Suijs
>
> > It is. But intosc is not fed into the cpu (see figure 4-6)
>
> Reading this diagram (I'm not an expert, this kind of diagram burns my
> brain...), I understand IRCF = 0 with INTOSC is not possible, which is
> confirmed reading the datasheet: postscaler allows values from 115KHz to
> 8MHz, not 31.25KHz.
>
> Maybe (?) when I set clock to 31.25KHz, it switches to INRC instead of
> INTOSC... There's no INTRC config in device files. Actually I don't event
> know the difference between the two. This is out what I can understand :)
comes from the internal osc block. I don't mind that the simplified
block diagram does not tell me everything ;)
>
> I also need to check, but 115Kbds serial perfectly works with INTOSC@8MHz
> and I wouldn't expect it to work @31KHz, so for me by default it really runs
> @8MHz.
It does not for me...
Just added checking of 5% error in serial_hw lib and now compilation
fails at 115k2, 8MHz. 56k2 works fine.
I could not get your code to work at all, so I build the
simple_i2c_slave with my lib (enclosed). It runs okay now and I can't
even break it when I delete the content of the delay function - just
calling it seems enough.
I enclosed the code (add a board file for the i2c_master)
Joep
Joep Suijs
If it runs properly and only has the speed problem, try to remove the
serial calls or put them at the end of the procedures, not at the
start. Iirc, it is time-critical to respond to some of the interrupts.
Please let me know how you intend to proceed with your i2c slave.
I could port my code to jallib when I put the user code in a call-back
procedure.
The only downside of my lib is that it can't handle a write string
(not followed by a read), since there seems no interrupt on stop or
restart..
Joep
2008/12/22, Joep Suijs <jsu...@gmail.com>:
Sebastien LELONG
Thanks again for your investigation ! I tried your master & slave, works
nice ! I then kept your master, and modify my slave: remove serial_hw_write,
put a OSCCON_IRCF = 7: works. Then remove OSCCON_IRCF = 7 (no
serial_hw_write): works...
So the problem really comes from my serial_hw_write calls (this is one of my
speciality: I consider them as just some debug statement without even the
slightest impact on timing etc... :)).
Question: why not setting OSCCON_IRCF = 7 makes the slave works ? Seems to be
the default value, at least for me ! Re-thinking about the problem, I use
tiny bootloader for my 16f88s. The tinybl configuration (the file used)
specifies internal osc @8MHz and serial @19200bds. Could it be possible that
tinybl sets IRCF = 7, and this values is kept by the PIC as the default ?
Thanks again !
Seb
Sebastien LELONG
> I could port my code to jallib when I put the user code in a call-back
> procedure.
I don't understand why you activate start/stop interrupts in your slave. For
me, that's not necessary, unless you want to debug the bus (very handy) or
implement a software master (software implementation based on some hardware
features, though).
Maybe we could put both yours and mine (one with start/stop interrupts, one
without). Mine is the implementation of Microchip Application Note AN734A +
some fixes taken from elsewhere:
* appnote: http://sirbot.org/sirbot-modules/datasheets/AN734A.pdf/view
* one of my old post:
http://sirloon.net/loonaweb/sirblog/i2c-com-with-two-16f88-master-slave
Seb
Joep Suijs
>
> Hi Joep,
>
> Thanks again for your investigation ! I tried your master & slave, works
> nice ! I then kept your master, and modify my slave: remove serial_hw_write,
> put a OSCCON_IRCF = 7: works. Then remove OSCCON_IRCF = 7 (no
> serial_hw_write): works...
>
> So the problem really comes from my serial_hw_write calls (this is one of my
> speciality: I consider them as just some debug statement without even the
> slightest impact on timing etc... :)).
You could probably do so if you use serial_hw_int_cts, since that
queues the chars.
>
> Question: why not setting OSCCON_IRCF = 7 makes the slave works ? Seems to be
> the default value, at least for me ! Re-thinking about the problem, I use
> tiny bootloader for my 16f88s. The tinybl configuration (the file used)
> specifies internal osc @8MHz and serial @19200bds. Could it be possible that
> tinybl sets IRCF = 7, and this values is kept by the PIC as the default ?
Yes, that would explain it!
Joep
Joep Suijs
- I put the state procedures 'inline', saving a stack level, a bit
faster and smaller.
- I receive and transmit from a buffer and have a user code part to
process this buffer at the right (well, almost right) moment.(I don't
know how to activate start/stop interrupts but I would like them).
- I don't have any code in state 5 (and that might be an issue...)
I would like to see how you're going to interface between the main
code and the lib. Unless it is worth while this interface have it both
your an my way, I see no reason to have both libs. This will only be
confusing for jallib users.
Joep