USB Serial not working right on the last SVN

[funlw65(Vasi)]

Tried "USB Serial" sample and is not working right for 18F2550. It not echoes the right char all the time... for most of the time, is ok but some times it trows a train of three or four weird chars (on linux with gtkterm - just keep pressed a button and you will see the behavior), not matter which speed you set. I had to revert to my trusty 2.4n and 0.6 package and now is working as expected.

Vasi

[Sebastien Lelong]

Can you try last SVN + 2.4o, in order to know which is guilty ?

2011/7/24 funlw65(Vasi) <fun...@gmail.com>

Tried "USB Serial" sample and is not working right for 18F2550. It not echoes the right char all the time... for most of the time, is ok but some times it trows a train of three or four weird chars (on linux with gtkterm - just keep pressed a button and you will see the behavior), not matter which speed you set. I had to revert to my trusty 2.4n and 0.6 package and now is working as expected.

Vasi

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/rZccDCTWC1EJ.
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

[funlw65(Vasi)]

I tried last night the last SVN (downloaded yesterday) with the last stable compiler, 2.4o. That is the culprit.

Vasi

[Sebastien Lelong]

You mean the compiler is the culprit, it works with last SVN + 2.4n, right ?

Seb

2011/7/24 funlw65(Vasi) <fun...@gmail.com>

I tried last night the last SVN (downloaded yesterday) with the last stable compiler, 2.4o. That is the culprit.

Vasi

--

You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/OQUhSnILa9IJ.

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

[funlw65(Vasi)]

Didn't tried that combination. Used the SVN with the last compiler, thinking that the jallib use some features from the new compiler...

[Sebastien Lelong]

AFAIK nothing strictly related to 2.4o has been put in USB libs.

Can you try latest SVN + 2.4n combination ? That way we'll know which is the culprit: libs or compiler.

Seb

2011/7/24 funlw65(Vasi) <fun...@gmail.com>

Didn't tried that combination. Used the SVN with the last compiler, thinking that the jallib use some features from the new compiler...

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/WCiIUqTooxcJ.

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

[funlw65(Vasi)]

I will do that. Until then, this is what I get:

[funlw65(Vasi)]

And this is the result using 2.4n on the last SVN:

[Sebastien Lelong]

You have to tell us more: what is it that you're doing to see that, what are the expected results, etc... Fill an detailed issue in tracker eventually.

Seb

2011/7/24 funlw65(Vasi) <fun...@gmail.com>

And this is the result using 2.4n on the last SVN:

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/R1AazQXJMfQJ.

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

[funlw65(Vasi)]

Ok Seb,

Is about 18f4550_usb_serial.jal example.
On the last working package (2.4n with 0.6.0), If I start it and press (keep pressed) in gtkterm a button, I have that character echoed on the terminal window continuously, with no interruptions or weird chars. I can put an object on that key button to keep it pressed and I can go in vacation and nothing weird will happen.

If I do the same using last SVN, the behavior is like on images above. Some times, instead of the char you sent, you receive those weird chars. On other terminals like moserial, you get different chars than the submitted ones. Not all the time but this must not happen.

Look at the image, from four trials, only one succeeded:


Vasi

[funlw65(Vasi)]

The only change I did on the example file is that I changed the target microcontroller to 18F2550.

[funlw65(Vasi)]

More info.

I just copied the old USB libraries over the last SVN and the issue is the same.

I removed entirely the last SVN and used my old package. Is working as expected. So I suppose the error come from some additional libraries used by USB libraries....

[Sebastien Lelong]

OK, thanks for the information. I'll try to have look when I get a chance.

Seb

2011/7/24 funlw65(Vasi) <fun...@gmail.com>

More info.

I just copied the old USB libraries over the last SVN and the issue is the same.

I removed entirely the last SVN and used my old package. Is working as expected. So I suppose the error come from some additional libraries used by USB libraries....

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/1EBHDKSIAVYJ.

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

[funlw65(Vasi)]

The problem is at device file, 18f2550 !?
I used the USB files form SVN and along with some other libraries but kept the compiler (2.4n) and the device file from 0.6.0 (I had to add only a constant required by the USB libs modified by Seb). Everything worked as expected.

Then I used the new 18f2550 device and the issue surfaced again.

[Sebastien Lelong]

OK, I can see one important change by diff'ing both version, about "pragma data"

0.6.0:

pragma  data    0x60-0xFF,0x100-0x1FF,0x200-0x2FF,0x300-0x3FF

current:

pragma  data    0x60-0xFF,0x100-0x1FF,0x200-0x2FF,0x300-0x3FF,0x400-0x4FF

pragma  data    0x500-0x5FF,0x600-0x6FF,0x700-0x7FF

This can have an impact with USB BDT.

Can you try the latest version (or 0.7.0), and remove 0x400-0x4FF as well and the line 0x500-0x5FF,0x600-0x6FF,0x700-0x7FF so it matches 0.6.0 code. If this comes from here, your sample should work.

Thanks

Seb

2011/7/24 funlw65(Vasi) <fun...@gmail.com>

The problem is at device file, 18f2550 !?
I used the USB files form SVN and along with some other libraries but kept the compiler (2.4n) and the device file from 0.6.0 (I had to add only a constant required by the USB libs modified by Seb). Everything worked as expected.

Then I used the new 18f2550 device and the issue surfaced again.

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/7tH9-2k2AUQJ.

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

[funlw65(Vasi)]

Hi Seb,

That is not enough. The issue is still there.

[Sebastien Lelong]

Do you know if the problem is the same on 18F4550 ? Because I don't have a 18F2550 by now...

Seb

2011/7/24 funlw65(Vasi) <fun...@gmail.com>

Hi Seb,

That is not enough. The issue is still there.

--
You received this message because you are subscribed to the Google Groups "jallib" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jallib/-/s_izv_MUxRQJ.

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

[funlw65(Vasi)]

I can compile it and burn it in a 2550 because I don't have yet a board for my 18f4550. Is that good enough?

[funlw65(Vasi)]

BTW, adding those missing pragma to the old device does not affect the USB serial functionality.

[funlw65(Vasi)]

BTW, adding those missing pragma to the old device does not affect the USB serial functionality.

(last message arrived in my inbox, don't know if appeared on group so I'm sending it again, sorry if is double post).

[funlw65(Vasi)]

Yes, same issue on 18F4550 device!

[Rob Hamerling]

Hi Vasi, Seb,

On 07/24/11 04:44 pm, Sebastien Lelong wrote:
> OK, I can see one important change by diff'ing both version, about
> "pragma data"

There may be another important difference: pragma fuse_def CPUDIV has
changed. The value P2 has a different meaning!

In JALPACK06:
P2 = 0x0 -- [osc1/osc2 src: /1][96mhz pll src: /2]

In JALPACK07:
P2 = 0x8 -- [primary oscillator src: /2][96 mhz pll src: /3]

So when you copy the sample program without changing this pragma it
might explain the garbage chars (but I would expect more severe problems!).

BTW: The difference in the pragma fuse_def (and other differences) is a
result of differences in MPLAB versions (and not actually testing all
samples with every new set of device files and libraries).

Regards, Rob.

--
R. Hamerling, Netherlands --- http://www.robh.nl

[funlw65(Vasi)]

Hi Rob,

That was the issue, CPUDIV. No problems now, thanks!

Vasi

In my opinion, Microchip does not good if change the tokens for configuration bits, which configuration bits are a little scary for the beginners.

[mattschinkel]

Can we have a sample?

Matt.

[funlw65(Vasi)]

Hi Matt,

About working program, or about how often Microchip change things?
If is about program, I only changed CPUDIV pragma to P1 in 18f4550_usb_serial.jal sample.
It is confusing and you must keep your eyes on the device file (supposing you know where to look).
Not speaking about compatibility break on books and tutorials... it seems that for Microchip is not so important...

Vasi

[mattschinkel]

> About working program, or about how often Microchip change things?
> If is about program, I only changed CPUDIV pragma to P1 in
> 18f4550_usb_serial.jal sample.

I don't think this is about microchip changing things. I don't think
they will change anything here. This is specific to the PIC you are
using. Each PIC has different meanings for this CPUDIV pragma.

Another suggestion is to change the blink sample (or have another) to
use the correct settings for USB so it is easy to copy/paste good
settings.

Matt.

[mattschinkel]

> The problem is caused by a wrong fuse_dev CPUDIV setting. Somewhere between
> jalpack 0.6 and 0.7 the meaning of the keywords of this fuse_def has
> changed.

Never mind... I just read the other topic/issue. I guess microchip
does change these things? :(

[Rob Hamerling]

Hi Matt,

On 07/26/11 06:54 am, mattschinkel wrote:

> Another suggestion is to change the blink sample (or have another) to
> use the correct settings for USB so it is easy to copy/paste good
> settings.

I'll think about adding a separate set of blink samples for PICs with
USB. These sample will use PLL and the appropriate fuse settings. Thanks
for the suggestion.

[vasi vasi]

Yes, that is a good idea.

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

--
Vasi

[Rob Hamerling]

Hi Matt,

On 07/26/11 06:58 am, mattschinkel wrote:
>> The problem is caused by a wrong fuse_dev CPUDIV setting. Somewhere between
>> jalpack 0.6 and 0.7 the meaning of the keywords of this fuse_def has
>> changed.
>
> Never mind... I just read the other topic/issue. I guess microchip
> does change these things? :(

For general understanding: I often curse Microchip for changing things
in MPLAB from version to version because of the consequences for my
interpretation of the MPLAB .dev files. And it is not always ovbious if
the change is a correction of a previous error or a simple improvement
(esp. in the case of description fields).

For the fuse_def definiton in the Jallib device files the dev2jal script
has to interpret a description (which is frequently a whole sentence!)
in the MPLAB .dev file and 'translate' it to a single keyword. This is a
tricky operation! Even a tiny change of the description (and Microchip
changes these descriptions often) may invalidate my interpretation. What
makes it even more tricky is that frequently the descriptions of the
same fuse are different for different groups of PICs.
Most of the time I catch these changes, certainly when there are few.
But when there are many - even tiny - changes I may overlook one (or
more). I think this was the case with CPUDIV.

Since some time I copy the original description of fuse settings in
MPLAB as comment in the Jallib device files. This is not meant as
replacement for the datasheet, but only as reminder for those who really
read the datasheet. My main purpose was however to help me (us) with
catching errors.

[Rob Hamerling]

Hi Matt,

On 07/26/11 06:54 am, mattschinkel wrote:

> Another suggestion is to change the blink sample (or have another) to
> use the correct settings for USB so it is easy to copy/paste good
> settings.

I've just added about 40 samples for PICs with USB, using a 20 MHz
crystal and PLL to get CPU freq of 48 MHz, thus using PLLDIV 5, and
CPUDIV P1 (with a comment). Hopefully this helps.
I have tested one sample with an 18F2550, but have not added these
samples to TORELEASE.

[funlw65(Vasi)]

Hi Rob,

Thank you for samples, but why
USBPLL = OSC and not F48MHZ ?

Vasi

[Rob Hamerling]

Hi Vasi,

On 07/26/11 08:35 pm, funlw65(Vasi) wrote:

> Thank you for samples, but why
> USBPLL = OSC and not F48MHZ ?

For this blink sample it won't matter since USB is not used. But when
you take it as base for an application which uses USB then it better be
F48MHZ. I'll change it!