M. Kerhuel,

there is still a problem with the ADC Input block.



For dsPIC33FJ256GP710, it gives the permitted

analogue input pins as 0-21 and 24-33, instead of

0-31 (which is certainly correct)



It is as though 22 and 23 were entered as 32 and 33, and the list was

then sorted into order. Typing 22 produces a dialogue

box:



RTW for PIC 16 MCU error

Subscript indices must either be real positive indices or logicals.



Checking the nearest convenient data-sheet,

Microchip's 70286A (covering dsPIC33FJXXXGPX06/X08/X10)

whenever AN21 is present AN22 and AN23 are also present:

that is, on



dsPIC33FJ{64,128}GP708

dsPIC33FJ{64,128}GP310

dsPIC33FJ256GP510

dsPIC33FJ{64,128,256}GP710



all but the GP708 versions continue with

pins AN24 - AN31: the GP708 stops with AN23.



On the other hand, I don't actually get any input on AN22, even

when I modify AD1CSSH to set the bit I want. I don't yet

understand this, and it might be relevant if I did. It is possible

that this is a problem with the hardware (or my understanding

of it), but I thought I should mention it.



Bernard Leak

Dear List,

I am using version 0.98fb of the dsPIC block-set,

dated 21st August 2008, for MatLab R2006b.



The list picRef.AN is wrong: it contains spurious

NaNs at indices 23 and 24 (1-based: 22 and 23 if 0-based)

which cause AN22 and AN23 to "vanish", and all

higher-numbered analogue pins to be numbered

too high by 2. This also smashes the generation of

ADPCFG in dsPIC_PortSetting.m .



Bernard Leak

Hello Lubin,

I would also add to Bernard's post on the ADC the following bug:



I have AN channels 0-16 except for AN2 which is SPI1 SSL in 33FJ256MC710. So in the AN dialog box I have:

[0 1 3 4 5 6 7 8 9 10 11 12 13 15 16]

Just for the sake of completeness I have a digital output block set with infinite sample time (so it just happens once) to high.



But regardless of that the generated code is as follows:

<i>
</i>/* Configuration ADCHS */
  AD1PCFGL = (0& 65535);
  AD2PCFGL = (0& 65535);
  AD1PCFGH = ((0 >> 16) & 65535);

  /* blocks with infinite sample periods */

  /* S-Function "dsPIC_Digital_OutputWrite" Block: <Root>/Drive SSL High */
  LATBbits.LATB2 = TRUE;

Which clearly ignores the fact that the ADxPCFGx bit 2 must be set to 1, in order to make B2 a digital pin. No show-stopper now that I know what the problem is but took me quite some time to figure out what was wrong :-).



Thanks, and I hope this gets corrected in the next version.

Hello,

Citation : Bernard Leak

there is still a problem with the ADC Input block.



Bernard, For dsPIC33FJ256GP710, it gives the permitted

analogue input pins as 0-21 and 24-33, instead of

0-31 (which is certainly correct)

Thanks Bernard for this bug report. The definition (inside the blockset) for the dsPIC33FJxxxGP710 family has an error that may cause problems for ADC pins above 21. It is now corrected in the version 0.98fc of the blockset.



----

Malife,

I find a bug that may affect all PIC or dsPIC on the ADC block that may cause the trouble described.

The correction added in the version 0.98fc should solve it.

This bug has also been reported by Peter but by email.





Thanks for theses bug descriptions.

Lubin

Thanks: all my problems with the ADC block are now with the hardware!