[jallib build] buildbot failure in jallib on jallib-standard

[bu...@sirloon.net]

Hi guys,

This is buildbot speaking. I have finished a build of jallib-standard on jallib.
Buildslave for this Build: sebbot

Build Reason:
Build Source Stamp: HEAD
Blamelist: jsuijs,robhamerling

BUILD FAILED: failed unittest
Logs are attached.

sincerely,
-The Buildbot

[Rob Hamerling]

Hi Seb,

On 03/25/10 02:05 am, bu...@sirloon.net wrote:
ys,
>
> This is buildbot speaking. I have finished a build of jallib-standard on jallib.
> Buildslave for this Build: sebbot
>
> Build Reason:
> Build Source Stamp: HEAD
> Blamelist: jsuijs,robhamerling
>
> BUILD FAILED: failed unittest
> Logs are attached.

I've checked the (unit-test) log and it seems the ADC libs need an
update due to the recent changes in the device files. As far as I can
see the JANSEL_ANS declarations in the latest device files are OK, in
accordance with the datasheet.

Regards, Rob

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

[Sebastien Lelong]

Hi Rob,

I've missed something... In 16f722.jal, JANSEL_ANSx bits aren't contigous anymore ! 

JANSEL_ANS0

JANSEL_ANS1

JANSEL_ANS2

JANSEL_ANS3

JANSEL_ANS4

JANSEL_ANS8

JANSEL_ANS9

JANSEL_ANS10

JANSEL_ANS11

JANSEL_ANS12

JANSEL_ANS13

The idea behind JANSEL_ANSx is to normalize these numbers and hide complexity for ADC libs (in general, not for these PICs). Specifically, there exception handling for these PICs: 16F722, 16F723, 16F724, 16F726, 16F727 + LF versions. So I'll update the extra normalization step, but can you confirm there aren't such change in other PICs ? (for which ANSx bits aren't contigous anymore)

Cheers,

Seb

2010/3/25 Rob Hamerling <robham...@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.

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

[Rob Hamerling]

On 03/25/10 11:13 am, Sebastien Lelong wrote:

> I've missed something... In 16f722.jal, JANSEL_ANSx bits aren't
> contigous anymore !

True, like there are gaps and irregular sequences in the pin/bit
nummering of AN-pins in their respective registers. The 16F722 for
example has pin_AN0 to pin_AN3 on RA0 to RA3, but pin_AN4 is on RA5.
This PIC does not have pin_AN5 to pin_AN7 and pin_AN8 to pin_AN13 are
spread over RB0 to RB5 (typically Microchip style I would say!).
There are similar 'irregularities' with many other PICs.

> The idea behind JANSEL_ANSx is to normalize these numbers and hide
> complexity for ADC libs (in general, not for these PICs). Specifically,
> there exception handling for these PICs: 16F722, 16F723, 16F724, 16F726,
> 16F727 + LF versions. So I'll update the extra normalization step, but
> can you confirm there aren't such change in other PICs ? (for which ANSx
> bits aren't contigous anymore)

There is obviously a misunderstanding! The idea of JANSEL was (in my
view) to obtain a one-to-one relationship between JANSEL_ANSx and
pin_ANx (with the same value of 'x'). So for example when using ADC
channel 4: pin_AN4 is the input pin and control its analog setting is
with JANSEL_ANS4. This sounds very obvious to me and is also similar to
the PICs which use ANCON1_PCFGx bits for this purpose.

I could make a list of all PICs with irregularities in their AN-pin
numbering. But I'm pretty sure it will contain almost all PICs with
JANSEL_ANSx (except for the very small ones with 2 or 3 ADC channels
which are difficult to randomize!). You might as well use the FindJANSEL
wiki, which was really meant to show how AN-pins are organised.

I'm sorry when I've caused trouble, of course unintentionally.

Regards, Rob.

[Sebastien Lelong]

Hi Rob,

The logic with ADC libs (2nd case, using ANS bits) is:

  - ADC libs create aliases: ADC_JANSEL_ANSx => ADC_JANSEL_ANSy. x and y can be the same. This is actually what's expected for most PIC in this 2nd case, except those I mentioned ealier.

  - in set_analog/digital_pin(num), which takes a number as input, the logic is:

if num == x then

    -- act on ADC_JANSEL_ANSx

    -- setup pin_ANx_direction

there are plenty of these "if", for each ANSx. So the idea is users just have to tell which ADC channel (where x means pin ANx from datasheet) they want to activate/deactivate. If user says "set_analog_pin(5), then it should act on pin AN5 (not RA5 for instance). The question now is: what if there's no AN5 pin ? I think what you've done must actually be ok. Normalization is now in device files for these PICs, so my normalization step in ADC libs is now wrong, you were right, I read all of this too fast. I thought contigous JANSEL_ANSx bits was important, but maybe not, I'll check this some more, I'm currently quite lost with all these aliases and normalization :)

Cheers,

Seb

2010/3/25 Rob Hamerling <robham...@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.

[Rob Hamerling]

On 03/25/10 12:35 pm, Sebastien Lelong wrote:
> So the idea is users just
> have to tell which ADC channel (where x means pin ANx from datasheet)
> they want to activate/deactivate. If user says "set_analog_pin(5), then
> it should act on pin AN5 (not RA5 for instance).

Agreed!

> The question now is: what if there's no AN5 pin?

No pin_AN5 on the particular PIC then you cannot use ADC channel 5.

> I think what you've done must actually be k.

> Normalization is now in device files for these PICs, so my
> normalization step in ADC libs is now wrong, you were right, I read all
> of this too fast.

In my view it has always been like this (except that I made mistakes
with the numbering of the JANSEL_ANS bits). This is confirmed by my doc
(devicefiles.html) which hasn't changed on this point for some time.
But when I read it now I think the example and text need improvement and
a better example (showing gaps and irregularities, e.g. with the 16F722).

[Rob Hamerling]

Hi Seb,

On 03/25/10 12:35 pm, Sebastien Lelong wrote:

> If user says "set_analog_pin(5), then
> it should act on pin AN5 (not RA5 for instance). The question now is:
> what if there's no AN5 pin?

Due to an little error in the Dev2Jal script some of the latest device
files have JANSEL_ANSx declarations for non-existing ADC channels. That
is not too bad, unless you check on defined(JANSEL_ANSx) and not on
defined(pin_ANx). BTW my error was in this check!
While testing my fix I noticed a 'peculiarity'. The device file of the
16F913 has a JANSEL_ANS4, but when looking in the datasheet, I saw no
AN4 in Table2! So I thought it was an eeror in pinmap.py.
Looking a little further I saw that the QFN package (Table 3) does have
an AN4! This is strange, since all are 28 pins packages. However on the
Pin Diagram all packages have an AN4 pin! So I assume this is an error
in Table2 of the datasheet.

It seems unlikely to me that the different packages have different
electronics (for example more active ADC channels). But it could be that
44-pin QFN packages have more active pins than their 40 PDIP
counterparts. Or am I seeing ghosts?

Can anybody say more about this hardware issue (and preferrrably assure
me that different packages have the same electronics)?

Regards, Rob

[Sebastien Lelong]

Hi Rob,

2010/3/25 Rob Hamerling <robham...@gmail.com>

Hi Seb,

On 03/25/10 12:35 pm, Sebastien Lelong wrote:

                            If user says "set_analog_pin(5), then
it should act on pin AN5 (not RA5 for instance). The question now is:
what if there's no AN5 pin?

Due to an little error in the Dev2Jal script some of the latest device files have JANSEL_ANSx declarations for non-existing ADC channels. That is not too bad, unless you check on defined(JANSEL_ANSx) and not on defined(pin_ANx). BTW my error was in this check!

Then we have a problem, this is exactly what I do... See adc_channels.jal.

 

It seems unlikely to me that the different packages have different electronics (for example more active ADC channels). But it could be that 44-pin QFN packages have more active pins than their 40 PDIP counterparts. Or am I seeing ghosts?

More GND pins on 44 pins package ?

Cheers,

Seb

[Rob Hamerling]

On 03/25/10 09:13 pm, Sebastien Lelong wrote:

> Due to an little error in the Dev2Jal script some of the latest
> device files have JANSEL_ANSx declarations for non-existing ADC
> channels. That is not too bad, unless you check on
> defined(JANSEL_ANSx) and not on defined(pin_ANx). BTW my error was
> in this check!
>
>
> Then we have a problem, this is exactly what I do... See adc_channels.jal.

Of course the device files will be fixed! When there is no pin_ANx there
should not be a JANSEL_ANSx (with the same 'x').

Regards, Rob.

[bu...@sirloon.net]

Hi guys,

This is buildbot speaking. I have finished a build of jallib-standard on jallib.
Buildslave for this Build: sebbot

Build Reason:
Build Source Stamp: HEAD

Blamelist: eur.van.andel,robhamerling

BUILD FAILED: failed validate

[Rob Hamerling]

Hi Seb,

On 03/25/10 12:35 pm, Sebastien Lelong wrote:

> - in set_analog/digital_pin(num), which takes a number as input, the
> logic is:
>
> if num == x then
> -- act on ADC_JANSEL_ANSx
> -- setup pin_ANx_direction

I see that set_analog_pin() goes to 27, but set_digital_pin() goes only
to 22. Since the remark in 'Notes:' in the header I cannot make
corrections....

And a question:
It is somewhat difficult to see if all PICs (of which we have device
files) are supported in ADC_channels.jal. Do you (have to) regenerate
this library after new device files arrive?

[Rob Hamerling]

Hi Seb,

On 03/27/10 09:13 pm, Rob Hamerling wrote:

>
> I see that set_analog_pin() goes to 27, but set_digital_pin() goes only
> to 22. Since the remark in 'Notes:' in the header I cannot make
> corrections....
>
> And a question:
> It is somewhat difficult to see if all PICs (of which we have device
> files) are supported in ADC_channels.jal. Do you (have to) regenerate
> this library after new device files arrive?

To help finding an answer to my question I've added some statistical
information to the FindJANSEL wiki: a list of PICs for the different
cases. If you need more or better info (I'm thinking of listing the PICs
in groups using the same dataset), shouldn't be to difficult.
Suggestions are welcome.

[Sebastien Lelong]

Hi Rob,

Sorry for the late reply

2010/3/27 Rob Hamerling <robham...@gmail.com>

Hi Seb,

On 03/25/10 12:35 pm, Sebastien Lelong wrote:

  - in set_analog/digital_pin(num), which takes a number as input, the
logic is:

if num == x then
    -- act on ADC_JANSEL_ANSx
    -- setup pin_ANx_direction

I see that set_analog_pin() goes to 27, but set_digital_pin() goes only to 22. Since the remark in 'Notes:' in the header I cannot make corrections....

You can within the template :) I'll fix this today.

Cheers,

Seb

[Sebastien Lelong]

And a question:
It is somewhat difficult to see if all PICs (of which we have device
files) are supported in ADC_channels.jal. Do you (have to) regenerate
this library after new device files arrive?

To help finding an answer to my question I've added some statistical information to the FindJANSEL wiki: a list of PICs for the different cases. If you need more or better info (I'm thinking of listing the PICs in groups using the same dataset), shouldn't be to difficult. Suggestions are welcome.

This is interesting, users may refer to this list, at least to know when ADC pins are dependent or not. Could you split this information and put in an another page, so they won't get flooded by too much data ? I'll then add a link in headers.

To answer your question, if a new PIC is added:

  - if ADC pins are dependent (case 1, controlled by PCFG bits), ADC libs must be re-generated, PIC must be added to pinmap.py and pcfg.py (see http://code.google.com/p/jallib/wiki/UpdatingPinmap)

  - if ADC pins are independent (case 2 & 3, controlled by either PCFG or ANSEL bits), there's usually no need to re-generate ADC libs, as configuration setting is probably already handled. Exception: eg. PIC has more ADC pins than declared in libs (22 => 28), or if there's an exception for this PIC that needs to be handled in the lib.

Cheers,

Seb

[Rob Hamerling]

Hi Seb,

On 29/03/10 07:47 am, Sebastien Lelong wrote:

[RobH]

> To help finding an answer to my question I've added some statistical
> information to the FindJANSEL wiki: a list of PICs for the different
> cases. If you need more or better info (I'm thinking of listing the
> PICs in groups using the same dataset), shouldn't be to difficult.
> Suggestions are welcome.
>
>
> This is interesting, users may refer to this list, at least to know when
> ADC pins are dependent or not. Could you split this information and put
> in an another page, so they won't get flooded by too much data ? I'll
> then add a link in headers.

You mean a separate wiki with only the bottom part of the current
FindANSEL wiki? Could be done, I think. Did you see the latest wiki with
the group-sorted list? Is that suitable for you and the users?

> To answer your question, if a new PIC is added:
>
> - if ADC pins are dependent (case 1, controlled by PCFG bits), ADC
> libs must be re-generated, PIC must be added to pinmap.py and pcfg.py
> (see http://code.google.com/p/jallib/wiki/UpdatingPinmap)

Update of pinmap.py will probably be done by me when a new device file
appears. But I systematically forget to update pcfg.py, sorry.
New device files will appear only once in several months with a new
version of MPLAB.

> - if ADC pins are independent (case 2 & 3, controlled by either PCFG
> or ANSEL bits), there's usually no need to re-generate ADC libs, as
> configuration setting is probably already handled. Exception: eg. PIC
> has more ADC pins than declared in libs (22 => 28), or if there's an
> exception for this PIC that needs to be handled in the lib.

So there is no warning signal to update ADC libs. That was one of my
doubts about ADC libs being up to date.

[Sebastien Lelong]

2010/3/29 Rob Hamerling <robham...@gmail.com>

Hi Seb,

On 29/03/10 07:47 am, Sebastien Lelong wrote:

[RobH]

   To help finding an answer to my question I've added some statistical
   information to the FindJANSEL wiki: a list of PICs for the different
   cases. If you need more or better info (I'm thinking of listing the
   PICs in groups using the same dataset), shouldn't be to difficult.
   Suggestions are welcome.


This is interesting, users may refer to this list, at least to know when
ADC pins are dependent or not. Could you split this information and put
in an another page, so they won't get flooded by too much data ? I'll
then add a link in headers.

You mean a separate wiki with only the bottom part of the current FindANSEL wiki? Could be done, I think.

I can do it of course, but it may be generated. Let me know.

 

Did you see the latest wiki with the group-sorted list? Is that suitable for you and the users?

Not sure. Is it content beginning from "Number of PICs listed..." to the end ? This is what I see as a dedicated wiki page for users.

 

To answer your question, if a new PIC is added:

  - if ADC pins are dependent (case 1, controlled by PCFG bits), ADC
libs must be re-generated, PIC must be added to pinmap.py and pcfg.py
(see http://code.google.com/p/jallib/wiki/UpdatingPinmap)

Update of pinmap.py will probably be done by me when a new device file appears. But I systematically forget to update pcfg.py, sorry.

I can take care of pcfg.py to share the burden...

 

So there is no warning signal to update ADC libs. That was one of my doubts about ADC libs being up to date.

AFAIK, they are now up-to-date.

Cheers,

Seb

 

[bu...@sirloon.net]

Hi guys,

This is buildbot speaking. I have finished a build of jallib-standard on jallib.
Buildslave for this Build: sebbot

Build Reason:
Build Source Stamp: HEAD

Blamelist: sebastien.lelong

[Rob Hamerling]

Hi Seb,

On 03/29/10 11:02 am, Sebastien Lelong wrote:

> This is interesting, users may refer to this list, at least to
> know when ADC pins are dependent or not.

I've added a new wiki for ADC library users to see which PICs have
dependent and which PIC independent ADC channels. Do you think it is
useable in this format and with this contents?

[bu...@sirloon.net]

[Sebastien Lelong]

2010/3/29 Rob Hamerling <robham...@gmail.com>

I've added a new wiki for ADC library users to see which PICs have dependent and which PIC independent ADC channels.  Do you think it is useable in this format and with this contents?

Looks perfect to me ! Thanks, I'll add a link in headers.

Cheers,

Seb

[bu...@sirloon.net]

Hi guys,

This is buildbot speaking. I have finished a build of jallib-standard on jallib.
Buildslave for this Build: sebbot

Build Reason:
Build Source Stamp: HEAD

Blamelist: robhamerling

BUILD FAILED: failed svn

[bu...@sirloon.net]

Hi guys,

This is buildbot speaking. I have finished a build of jallib-standard on jallib.
Buildslave for this Build: sebbot

Build Reason:
Build Source Stamp: HEAD

Blamelist: mattsc...@hotmail.com

[bu...@sirloon.net]

Hi guys,

This is buildbot speaking. I have finished a build of jallib-standard on jallib.
Buildslave for this Build: sebbot

Build Reason:
Build Source Stamp: HEAD

Blamelist: bvwelch

[William]

Is there really a problem? The log appears to be an empty file.
thanks!

>  svn.stdio
> < 1KViewDownload

[Sebastien Lelong]

2010/4/1 William <bvw...@gmail.com>

Is there really a problem?

there's a real problem with my wifi connection on my server 

 

The log appears to be an empty file.

my server failed to contact google code, build fails, SVN log file is empty (sometime you can see an error), and there's no other file attached.

Cheers,

Seb

 

thanks!

On Apr 1, 4:32 am, bu...@sirloon.net wrote:
> Hi guys,
>
> This is buildbot speaking. I have finished a build of jallib-standard on jallib.
> Buildslave for this Build: sebbot
>
> Build Reason:
> Build Source Stamp: HEAD
> Blamelist: bvwelch
>
> BUILD FAILED: failed svn
> Logs are attached.
>
> sincerely,
>  -The Buildbot
>

>  svn.stdio
> < 1KViewDownload

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

[bu...@sirloon.net]

Hi guys,

This is buildbot speaking. I have finished a build of jallib-standard on jallib.
Buildslave for this Build: sebbot

Build Reason:
Build Source Stamp: HEAD

Blamelist: mattsc...@hotmail.com