compiler 2.4n

[Rob Hamerling]

Hi guys,

You may (not) have noticed that the latest device files specify '2.4n'
in the header. That was a little premature, since this version wasn't
available up till now. But since yesterday 2.4n-beta is available!

Version 2.4n is supposed to contain support for the new 'extended'
midrange PICs (like 16f1937), among other things. I'm working on the
Jallib device files for these PICs and I recently bought a 16f1937 from
Wouter for testing purposes. The first test (an hour ago) failed: no
blinking led. To be sure it isn't the board I tried a 16F877a with
success. So it could be a defective 16f1937, but I suspect the compiler.
I reported my analysis to Kyle and we also discuss the requirements of
the device files as far as the compiler is concerned.

I think it is a good idea to use 2.4n-beta for regression tests to see
if all libraries and applications still work (and if not to report the
issue to Kyle).

Regards, Rob.

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

[Sebastien Lelong]

Hi Rob

2010/2/4 Rob Hamerling <robham...@gmail.com>

I think it is a good idea to use 2.4n-beta for regression tests to see if all libraries and applications still work (and if not to report the issue to Kyle).

OK, I'll update buildbot with 2.4n


Cheers
seb

[Rob Hamerling]

Hi Seb, others,

> OK, I'll update buildbot with 2.4n

There is a new beta (dd 5 feb). This gives a working blink-a-led sample
for the 16f1937, and also with an LCD sample with this PIC. I only had
to disable PLL explicitly. PLL is enabled by default, and it caused my
PIC to run at 64 MHz with a 16 MHz oscillator: twice as fast as the
'absolute maximum'.

However with the serial_hw_int_cts library compilation fails, probably
related to context saving (missing _fsr). I've informed Kyle.

I'll wait for a fix before testing more libraries.

There are also some issues with the device files for the extended midrange.
- The compiler needs some special declarations specifically for the
extended midrange PICs. I'm in conversation with Kyle for this.
- In contrast to the existing baseline and midrange the MPLAB .dev
files for the extended midrange PICs have most bit-fields of registers
completely enumerated (a name for each individual bit). Since many
libraries use the multi-bit 'binary' subfields as single binary entity,
I have to add many extra declarations (and suppress the corresponding
redundant bit declarations). Work in progress.....

[Sebastien Lelong]

Hi Rob,

I updated compiler for buildbot tow days ago when you sent first mail, and I seem to have installed the version you're talking about: jal 2.4n-beta (compiled Feb  3 2010) (linux version). I re-downloaded it again, version have changed. Where did you find Feb 5 ?

Cheers,

Seb

2010/2/6 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

[Kyle]

Greetings,

On Sat, 6 Feb 2010 16:41:01 +0100, Sebastien Lelong wrote

> Hi Rob,
>
> I updated compiler for buildbot tow days ago when you sent first
> mail, and I seem to have installed the version you're talking about:
> jal 2.4n-beta
> (compiled Feb 3 2010) (linux version). I re-downloaded it again, version
> have changed. Where did you find Feb 5 ?

In the beta section of the JALv2 page:

<http://www.casadeyork.com/jalv2/archive/beta>

I've fixed a couple of problems Rob found. All of the jallib samples compile,
but some have warnings. I'll look into this.

--kyle

[Rob Hamerling]

Hi Seb,

Sebastien Lelong wrote:

> I updated compiler for buildbot tow days ago when you sent first mail,
> and I seem to have installed the version you're talking about: jal
> 2.4n-beta (compiled Feb 3 2010) (linux version). I re-downloaded it
> again, version have changed. Where did you find Feb 5 ?

Got a msg from Kyle: there is already another new version dd 6 feb. in
the beta directory:

> http://www.casadeyork.com/jalv2/archive/beta

I just came home, haven't tried it, but has some fixes for the problmes
I reported. I always take the source package and compile it here.

[Rob Hamerling]

Hi guys,

Kyle wrote:
>
> In the beta section of the JALv2 page:
>
> <http://www.casadeyork.com/jalv2/archive/beta>
>
> I've fixed a couple of problems Rob found. All of the jallib samples compile,
> but some have warnings. I'll look into this.

With 2.4n dd 06 feb. the sample with the serial_hw_int_cts library with
which I had problems compiles now OK and even better it works with the
16F1937!
It looks to me that 2.4n is quite good. I'll do some regression tests
and when no problems appear I'll generate the device files and
blink-a-led samples for more 16F18/19xx (and if OK commit 'm to-morrow).

[Sebastien Lelong]

Hi Kyle,

2010/2/6 Kyle <googl...@videovideo.com>

In the beta section of the JALv2 page:

<http://www.casadeyork.com/jalv2/archive/beta>

I've fixed a couple of problems Rob found. All of the jallib samples compile,
but some have warnings. I'll look into this.

OK, I've been there, and downloaded jalv24n-beta.zip, which was "Last modified Feb 6". When I run "jalv2" linux exec, I have:

sirloon@storm /tmp/jalv24n-beta ./bin/jalv2

jal 2.4n-beta (compiled Feb  3 2010)

no source file, use ./bin/jalv2 --help for help

Is this the correct version you and Rob re talking about ? What does "dd 06 feb" means ?

Cheers,

Seb

[Rob Hamerling]

Hi Seb,

Kyle won't be awake yet, so let me try....

Sebastien Lelong wrote:

> sirloon@storm /tmp/jalv24n-beta ./bin/jalv2
> jal 2.4n-beta (compiled Feb 3 2010)

This is the wrong executable, you must have JalV2 compiled 06 feb.

Have you an older version installed (somewhere in a path directory)?

> Is this the correct version you and Rob re talking about ? What does "dd
> 06 feb" means ?

'dd' is an abbreviation of 'de dato', meaning 'of the date'.

[Sebastien Lelong]

Hi Rob,

2010/2/7 Rob Hamerling <robham...@gmail.com>

Sebastien Lelong wrote:

sirloon@storm /tmp/jalv24n-beta ./bin/jalv2
jal 2.4n-beta (compiled Feb  3 2010)

This is the wrong executable, you must have JalV2 compiled 06 feb.

Have you an older version installed (somewhere in a path directory)?

No, nothing as a problem here, as you can see I run jalv2 exec locally to the "/tmp/jalv24n-beta" directory.

The version I've downloaded have the following md5sum:

66aa64a981c0c3180b78582c8c6c68dd  jalv24n-beta.zip

Is that ok ? I really don't know where the problem is... :)

Cheers,

Seb

[Rob Hamerling]

Hi Seb,

Sebastien Lelong wrote:

> sirloon@storm /tmp/jalv24n-beta ./bin/jalv2
> jal 2.4n-beta (compiled Feb 3 2010)

As I said earlier: I always use the source and compile myself. But I
just downloaded the binary and indeed it contains compile date '03 feb'
(find it with a hex editor or so). So you probably have the right
executable!

Probably only the fixed modules were replaced by Kyle and the module
containing the date string is not recompiled and thus the old date
appears in the opening message. I had a similar issue with some of my
own programs (like TinyBld2 and XWisp2) and I've modified my makefiles
such that the module with the compile date is always recompiled,
regardless if it was changed or not.

[Sebastien Lelong]

As I said earlier: I always use the source and compile myself. But I just downloaded the binary and indeed it contains compile date '03 feb' (find it with a hex editor or so). So you probably have the right executable!

OK :)

 

Probably only the fixed modules were replaced by Kyle and the module containing the date string is not recompiled and thus the old date appears in the opening message.  I had a similar issue with some of my own programs (like TinyBld2 and XWisp2) and I've modified my makefiles such that the module with the compile date is always recompiled, regardless if it was changed or not.

I think we agree, but let's check this together: I don't want to compile a new executable on my Linux, I want to use the one provided by default in ZIP file, and to users, just to make sure there won't be unexpected behavior due to my local configuration.

So for me, updating a compiler for buildbot really just means copying the appropriate exec.

Do we agree ?

Cheers,

Seb

[Rob Hamerling]

Hi Seb,

Sebastien Lelong wrote:
> ......... let's check this together: I don't want to compile

> a new executable on my Linux, I want to use the one provided by default
> in ZIP file, and to users, just to make sure there won't be unexpected
> behavior due to my local configuration.

OK. But how to check if the Linux executable in the ZIP file of 06 feb.
is really the right version? The file date of the executables is 06
feb., which is what I would expect. What else is there to check?

> So for me, updating a compiler for buildbot really just means copying
> the appropriate exec.

You might simply trust Kyle's organisation/habits.
In case of doubt like this you could download older beta versions and
compare contents and check file dates.

> Do we agree ?

Yes. But in addition we could persuade Kyle to make sure the opening
message really displays the right compile date (and for beta-versions
maybe also compile time!).

BTW the MD5 checksums of your and my downloads are identical.

[Kyle]

Greetings,

On Sun, 07 Feb 2010 13:46:25 +0100, Rob Hamerling wrote

> Probably only the fixed modules were replaced by Kyle and the module
> containing the date string is not recompiled and thus the old date
> appears in the opening message.

Yes, this is the problem. Before real releases I always do a clean build, so
the date is always correct. I failed to do it this time and as Rob suggested,
the one file that has the datestamp compile in did not change, hence the
incorrect reporting.

I'll fix this.

--kyle

[Joep Suijs]

Hi Guys,

While chasing bugs, I check the compiler version from SVN and was
surprised that it is 2.4m.I assumed this directory also contains the
next-to-be-released compiler and that's why this the one I use for all
JAL work.
So, is this version 2.4m and at which point in time is it updated?

Joep

[Rob Hamerling]

Hi Joep,

Joep Suijs wrote:

> While chasing bugs, I check the compiler version from SVN and was
> surprised that it is 2.4m.I assumed this directory also contains the
> next-to-be-released compiler and that's why this the one I use for all
> JAL work.

I would have no problem with a beta-version of the compiler in
bee-packages. Isn't 'bee' an equivalent to 'beta'?
It would make it possible to distribute 16F19xx samples too.

[Sebastien Lelong]

I don't understand, Rob, you said in jallib bee error message today you didn't want to put compiler in SVN ?

Also, guys, no exception for buildbot please: if it's in SVN, then it'll be in bee packages. If not in SVN, it won't be in bee packages. There are quite a lot of tricky code to setup environment, choose correct content, etc... I don't want to put yet another "if".

I hope you'll agree :)

Cheers,

Seb

2010/2/14 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.

[Joep Suijs]

I don't agree or disagree, I just trying to figure out how it works...

2010/2/14 Sebastien Lelong <sebastie...@gmail.com>:

[Rob Hamerling]

Hi Seb,

Sebastien Lelong wrote:
> I don't understand, Rob, you said in jallib bee error message today you
> didn't want to put compiler in SVN ?

I took for a fact that bee-packages would not contain a beta-compiler
and then removing the 16F19xx samples from TORELEASE would be the best
option to avoid 'generation conflicts'.
But when considering 'bee' as 'beta' I think it is a better alternative
to put the beta compiler in SVN. I see a draw-back: if we would want to
release a new Jallib version while the compiler is still in beta-stage
we have a problem.

[Sebastien Lelong]

Well... Do you really want me to explain how buildbots are working behind the scene ? This sounds hard :)

What I mean, for buildbot to succeed in its hard task, is it should as straight forward as possible from getting things from SVN to what it produces. The more there are manual adjustements, the more I have to act on buildbot, and the more it's error prone... If you want to add beta compiler in bee package, but not in SVN, I would require to download last compiler version and re-create a temporary "compiler" directory, with docs, etc... (no jalv2 exec for eCs), just to have to this separate, very specific way to produce bee package. Note I already download beta compiler from time to time, *but just copy the linux binary*, then update buildbot config when needed. If we use only SVN compiler, I will skip all of this.

The more it's automated, the better it is.

Cheers,

Seb

2010/2/14 Joep Suijs <jsu...@gmail.com>

[Rob Hamerling]

Sebastien Lelong wrote:

> So for me, updating a compiler for buildbot really just means copying
> the appropriate exec.
>
> Do we agree ?

To answer you (after 2 weeks!) I would say 'yes'.