Strange mplabx behaviour - reply Microchip

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange mplabx behaviour - reply Microchip

John Coppens
Hello all...

As mentioned in my mail, I submitted the strange behaviour I
experienced with mplab x to the Microchip bug list, and got as answer:

<paraphrased>
We believe that this is due to the read-modify-write
nature of the bsf instructions. You should keep an image and update the
image
</paraphrased> (...and closed the bug)

If I understand the RMW behaviour, then the possible problems are due
to either capacitive (or other) loading of the outputs, or having some
internal peripheral enabled which could cause the same loading.

Is there any way this could explain my problem? I even tried the
'image' method to update port A, and the mplab X simulator _still_
doesn't show any change to the port A output.

Am I really that far off my game? Could someone try to run this code and check
if they have the same problems? (MPLAB X is Linux 64bit version 1.30 here)
Gpsim and the actual hardware say I'm right...

John

BSF Code:
                processor pic16f874
                include   P16F874.INC
                                   
                org     0
                                 
                goto    start    
                             
                org     4

start
                banksel TRISA
                movlw   b'00000111'
                movwf   ADCON1    
                             
                movlw   b'00111001'
                movwf   TRISA      
                             
                clrf    TRISB
                             
                banksel PORTA
loop
                bsf     PORTA,1
                bsf     PORTA,2

                bcf     PORTA,1
                bcf     PORTA,2
                goto    loop

                end

Direct modification code (no RMW): ---------------------------

                processor pic16f874
                include P16F874.INC
                                   
                org             0
                                 
                goto    start    
                             
                org             4

start
                banksel TRISA
                movlw   b'00000111'
                movwf   ADCON1    

                movlw   b'00111001' ; Bits 1 & 2 as outputs
                movwf   TRISA      

                clrf    TRISB

                banksel PORTA
loop
                movlw   2              
                movwf   PORTA
                movlw   6
                movwf   PORTA
                movlw   4
                movwf   PORTA
                movlw   0    
                movwf   PORTA

                goto    loop

                end
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Jan-Erik Söderholm


John Coppens wrote 2012-08-24 21:17:

> Hello all...
>
> As mentioned in my mail, I submitted the strange behaviour I
> experienced with mplab x to the Microchip bug list, and got as answer:
>
> <paraphrased>
> We believe that this is due to the read-modify-write
> nature of the bsf instructions. You should keep an image and update the
> image
> </paraphrased> (...and closed the bug)
>
> If I understand the RMW behaviour, then the possible problems are due
> to either capacitive (or other) loading of the outputs, or having some
> internal peripheral enabled which could cause the same loading.
>
> Is there any way this could explain my problem? I even tried the
> 'image' method to update port A, and the mplab X simulator _still_
> doesn't show any change to the port A output.
>

Now, Note that the RWM problem *never* hits the *same pin* as
your are BCF/BSF'ing !!

The RWM problem will show up as random changes of *other* pins
then the one you are targeting with your BCF/BSF. Usualy another
pin changed with a BCF/BSF directly before the other BCF/BSF.
That is when the RMW might reset the first pin since it hadn't
had time to get to a stable level on the pin.

Now, it you are BSF'ing a pin that is configured as an
analog input, it *should* show as "0" in the simulator
because that is how the hardware sees it. But *that*
is *not* a RWM issue ! It's absolutely normal. :-)


Have you given them a reproducer?
That is, actual code that shows the problem?


Jan-Erik.


> Am I really that far off my game? Could someone try to run this code and check
> if they have the same problems? (MPLAB X is Linux 64bit version 1.30 here)
> Gpsim and the actual hardware say I'm right...
>
> John
>
> BSF Code:
>                  processor pic16f874
>                  include   P16F874.INC
>
>                  org     0
>
>                  goto    start
>
> org     4
>
> start
> banksel TRISA
> movlw   b'00000111'
> movwf   ADCON1
>
> movlw   b'00111001'
> movwf   TRISA
>
> clrf    TRISB
>
> banksel PORTA
> loop
> bsf     PORTA,1
> bsf     PORTA,2
>
> bcf     PORTA,1
> bcf     PORTA,2
>                  goto    loop
>
>                  end
>
> Direct modification code (no RMW): ---------------------------
>
>                  processor pic16f874
>                  include P16F874.INC
>
>                  org             0
>
>                  goto    start
>
>                  org             4
>
> start
> banksel TRISA
> movlw   b'00000111'
>                  movwf   ADCON1
>
> movlw   b'00111001' ; Bits 1 & 2 as outputs
> movwf   TRISA
>
> clrf    TRISB
>
> banksel PORTA
> loop
> movlw   2
> movwf   PORTA
> movlw   6
> movwf   PORTA
> movlw   4
> movwf   PORTA
> movlw   0
> movwf   PORTA
>
> goto    loop
>
> end
>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Barry Gershenfeld-2
Without looking at the particular problem, I will say that a dead giveaway
to an R/M/W problem is that the same code works properly when you
single-step it.  You can guess how I know this.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

RE: Strange mplabx behaviour - reply Microchip

David Meiklejohn
In reply to this post by John Coppens
John Coppens wrote:

>
> Hello all...
>
> As mentioned in my mail, I submitted the strange behaviour I
> experienced with mplab x to the Microchip bug list, and got as answer:
>
> <paraphrased>
> We believe that this is due to the read-modify-write nature of the bsf
> instructions. You should keep an image and update the image
> </paraphrased> (...and closed the bug)
>
> If I understand the RMW behaviour, then the possible problems are due
> to either capacitive (or other) loading of the outputs, or having some
> internal peripheral enabled which could cause the same loading.
>
> Is there any way this could explain my problem? I even tried the
> 'image' method to update port A, and the mplab X simulator _still_
> doesn't show any change to the port A output.

Microchip's reply sounds like a cop-out to me.  RMW potentially affects
actual hardware, in ways that depend on the hardware.  A simulator can't
take that into account (ok, unless you're using something like Proteus with
a SPICE model of the attached hardware).  RMW should not be the explanation
for what you see in the simulator.

I suspect that Microchip didn't understand what you were getting at (or
didn't take the time to understand...).


Cheers,
David Meiklejohn
www.gooligum.com.au


--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Tamas Rudnai
Actually, it would not be a big deal to detect RMW errors on the emulator -
it is just checking when the last write happened to the actual port, and if
X virtual time tick passed, then it is safe again to read that port,
otherwise log it as RMW error on the console. You may even can control this
by the simulator settings, so one can increase this minimum tick value for
deeper test (sometimes a nop is inserted in between RMW instructions as a
quick fix and that might not enough in some case, so you can go even
further). For this kind of dummy tests you do not need a real SPICE
simulation...

Tamas


On 24 August 2012 15:36, David Meiklejohn <[hidden email]> wrote:

> John Coppens wrote:
> >
> > Hello all...
> >
> > As mentioned in my mail, I submitted the strange behaviour I
> > experienced with mplab x to the Microchip bug list, and got as answer:
> >
> > <paraphrased>
> > We believe that this is due to the read-modify-write nature of the bsf
> > instructions. You should keep an image and update the image
> > </paraphrased> (...and closed the bug)
> >
> > If I understand the RMW behaviour, then the possible problems are due
> > to either capacitive (or other) loading of the outputs, or having some
> > internal peripheral enabled which could cause the same loading.
> >
> > Is there any way this could explain my problem? I even tried the
> > 'image' method to update port A, and the mplab X simulator _still_
> > doesn't show any change to the port A output.
>
> Microchip's reply sounds like a cop-out to me.  RMW potentially affects
> actual hardware, in ways that depend on the hardware.  A simulator can't
> take that into account (ok, unless you're using something like Proteus with
> a SPICE model of the attached hardware).  RMW should not be the explanation
> for what you see in the simulator.
>
> I suspect that Microchip didn't understand what you were getting at (or
> didn't take the time to understand...).
>
>
> Cheers,
> David Meiklejohn
> www.gooligum.com.au
>
>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Isaac Marino Bavaresco
There are three possible causes of RMW issues that may affect PICs:


a) Due to capacitive loading: One instruction modifies a pin then
another instruction reads the pin value and writes it back as a side
effect of modifying another pin in the same port.
Because of the capacitive loading, the first pin didn't have time to
settle to the value set by the first instruction before the second
instruction samples its value.

Ex.:
    clrf    PORTA
    .
    .                            ; some delay...
    .
    bsf    PORTA,0
    bsf    PORTA,1

The 'bsf' instruction reads the entire port, modifies one bit and then
writes the entire port back.
The first 'bsf' reads the already stable value of PORTA and sets its bit 0.
The second 'bsf' reads again the value of PORTA. The bit 0 voltage is
raising but didn't reach the level '1' threshold, so it is read still as
'0'. Then the instruction writes bit 0 as '0' and bit 1 as '1'.


b) Due to a pin being input then changed to output:

    movlw    0x03
    movwf    PORTA    ; here all bits of the latch of PORTA are
initialized to a known value, even the ones that are inputs, because
movwf doesn't have issues with RMW.
    banksel TRISA
    clrf          TRISA    ; bits 0 and 1 change to '1' correctly
    .
    .
    .
    bsf         TRISA,1      ; bit 1 is changed to input. Here we assume
that it is pulled down externally
    banksel PORTA
    bcf         PORTA,0    ; we clear bit 0, that is still an output,
and it works OK, but bit 1 is read also and as it is an input and pulled
low externally, the value written back for bit 1 is '0'
    banksel TRISA
    bcf         TRISA,1      ; change bit 1 back to output. Some would
assume that it would output an '1', but due to RMW it will be a '0'.


c) Due to a pin being an output but configured as analog:

    ; RA0 is configured as output but also as analog and RA1 is a
digital output
    bsf    PORTA,0    ; RA0 changes to '1'
    .
    .
    .                            ; some delay to avoid capacitive RMW
    .
    bsf    PORTA,1    ; RA1 changes to '1', but RA0 changes to '0'
because when the instruction reads the port value, RA0 is read as '0'
because as it is configured as analog its digital input circuitry is
turned off.



Best regards,

Isaac

   


Em 24/8/2012 19:48, Tamas Rudnai escreveu:

> Actually, it would not be a big deal to detect RMW errors on the emulator -
> it is just checking when the last write happened to the actual port, and if
> X virtual time tick passed, then it is safe again to read that port,
> otherwise log it as RMW error on the console. You may even can control this
> by the simulator settings, so one can increase this minimum tick value for
> deeper test (sometimes a nop is inserted in between RMW instructions as a
> quick fix and that might not enough in some case, so you can go even
> further). For this kind of dummy tests you do not need a real SPICE
> simulation...
>
> Tamas
>
>
> On 24 August 2012 15:36, David Meiklejohn <[hidden email]> wrote:
>
>> John Coppens wrote:
>>> Hello all...
>>>
>>> As mentioned in my mail, I submitted the strange behaviour I
>>> experienced with mplab x to the Microchip bug list, and got as answer:
>>>
>>> <paraphrased>
>>> We believe that this is due to the read-modify-write nature of the bsf
>>> instructions. You should keep an image and update the image
>>> </paraphrased> (...and closed the bug)
>>>
>>> If I understand the RMW behaviour, then the possible problems are due
>>> to either capacitive (or other) loading of the outputs, or having some
>>> internal peripheral enabled which could cause the same loading.
>>>
>>> Is there any way this could explain my problem? I even tried the
>>> 'image' method to update port A, and the mplab X simulator _still_
>>> doesn't show any change to the port A output.
>> Microchip's reply sounds like a cop-out to me.  RMW potentially affects
>> actual hardware, in ways that depend on the hardware.  A simulator can't
>> take that into account (ok, unless you're using something like Proteus with
>> a SPICE model of the attached hardware).  RMW should not be the explanation
>> for what you see in the simulator.
>>
>> I suspect that Microchip didn't understand what you were getting at (or
>> didn't take the time to understand...).
>>
>>
>> Cheers,
>> David Meiklejohn
>> www.gooligum.com.au
>>
>>
>> --
>> http://www.piclist.com PIC/SX FAQ & list archive
>> View/change your membership options at
>> http://mailman.mit.edu/mailman/listinfo/piclist
>>
>
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Barry Gershenfeld-2
While thinking about the sequence for an R/M/W error, it occurred to me
that a write (an output change) immediately precedes the R/M/W
instruction.  So, maybe it should be called W+R/M/W, since that's what's
actually happening.

Per Issac's message, changing a TRIS bit to cause an input to become an
output is really another way of writing to a port pin.  And causes the same
trouble if an RMW instruction happens too soon thereafter.

The third example (analog configuration) should be able to be mimicked by
the simulator.
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
ivp
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

ivp
In reply to this post by David Meiklejohn

> I suspect that Microchip didn't understand what you were
> getting at (or didn't take the time to understand...)

I hesitate to contact Microchip Support for that very reason

The last time time I pointed out what eventually was discovered
to be a real silicon fault, I was fobbed off for weeks with bland
answers to irrelevant questions I didn't ask, with no attempt to
actually replicate the fault scenario I described. The problem
was with a dsPIC and yet the reply was "It works on the 24F
I tried". Absolutely pointless

It resulted in me sending a letter to the Support Training manager
at corporate HQ

It wasn't the first time they just didn't try and appear to be
confined to some sort of inflexible checklist. You can tell -
"Is the chip in the right way, what's Vdd, are you sure you've
set such-and-such" etc. The impression I always get is that
they are simply front-office seat-warmers

I'm wondering whether these support people are any good at
programming or really know the chips. More than once I've
been instructed to do something which has already clearly been
done in the snippets I send

Joe
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Tamas Rudnai
On 24 August 2012 17:17, IVP <[hidden email]> wrote:

> The last time time I pointed out what eventually was discovered
> to be a real silicon fault, I was fobbed off for weeks with bland
> answers to irrelevant questions I didn't ask, with no attempt to
> actually replicate the fault scenario I described. The problem
> was with a dsPIC and yet the reply was "It works on the 24F
> I tried". Absolutely pointless
>

I have not tried this with Microchip yet, but usually this magic phrase
works in all customer care or technical support services: "I would like to
escalate this problem".

"Escalation" is somehow a magic word in modern aftermarket services and
it immediately goes to the manager or a higher level stuff who usually
understands what you are saying or meaning -- they pay more for these
people and they are trained well usually. Last time I used this
"sorcery" was a month ago with Apple, where I realized my questions never
got real attention -- after I expressed this word I ended up talking to
senior advisers and did save a huge amount of time and they did actually
care about my issue afterwards.

Tamas
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
ivp
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

ivp
> usually this magic phrase works in all customer care or
> technical support services: "I would like to escalate this
> problem"

Thanks, I'll remember that

Don't get me wrong - the support staff are probably ordinary
decent people, but they really seem to have been trained only
up to a certain level and I appreciate that they must receive a
veritable mountain of bunny questions with easy answers. I
would just like them to realise that occassionally they will face
a question that needs technical beyond their training and pass
it on a bit quicker

Joe
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Tamas Rudnai
On 24 August 2012 17:54, IVP <[hidden email]> wrote:

> I would just like them to realise that occassionally they will face
> a question that needs technical beyond their training and pass
> it on a bit quicker
>

As far as I know they are forced to do the numbers (how many customers they
handle per day, and how many was escalated etc which they have to keep to a
minimum of course). So I can understand this, although it does not really
help us sometimes.

Tamas




>
> Joe
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

John Coppens
In reply to this post by Jan-Erik Söderholm
On Fri, 24 Aug 2012 21:46:42 +0200
Jan-Erik Soderholm <[hidden email]> wrote:

> Now, Note that the RWM problem *never* hits the *same pin* as
> your are BCF/BSF'ing !!
>
> The RWM problem will show up as random changes of *other* pins
> then the one you are targeting with your BCF/BSF. Usualy another
> pin changed with a BCF/BSF directly before the other BCF/BSF.
> That is when the RMW might reset the first pin since it hadn't
> had time to get to a stable level on the pin.

Hi Jan.Erik...

Yes... I am (old) electronics engineer, so I really understand the
mechanics of the RMW problem. After 35-odd years with
various microprocessors, I've had my share of (even stranger)
problems!

> Now, it you are BSF'ing a pin that is configured as an
> analog input, it *should* show as "0" in the simulator
> because that is how the hardware sees it. But *that*
> is *not* a RWM issue ! It's absolutely normal. :-)

Yep... But the A/D _was_ switched off.

> Have you given them a reproducer?
> That is, actual code that shows the problem?

I sent them the code, and I even sent them a screen grab showing actual
single stepping through the execution and showing the results.

I tried to re-open the issue, but didn't find how. So I re-submitted
the report.

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

John Coppens
In reply to this post by David Meiklejohn
On Sat, 25 Aug 2012 08:36:22 +1000
"David Meiklejohn" <[hidden email]> wrote:

> Microchip's reply sounds like a cop-out to me.  RMW potentially affects
> actual hardware, in ways that depend on the hardware.  A simulator can't
> take that into account (ok, unless you're using something like Proteus with
> a SPICE model of the attached hardware).  RMW should not be the explanation
> for what you see in the simulator.
>
> I suspect that Microchip didn't understand what you were getting at (or
> didn't take the time to understand...).

Or, maybe, they took my mentioning 'simulator' as being the in-circuit
emulator or -debugger. Though English is not my native language, I
believe the bug report was clear enough.

I can believe they're somewhat stressed. In one week, the ticket number
went up by 350! That's about 70 tickets per working day.

Anyway, #235011 is the new ticket.

John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Jan-Erik Söderholm
In reply to this post by Barry Gershenfeld-2


Barry Gershenfeld wrote 2012-08-25 02:14:

> While thinking about the sequence for an R/M/W error, it occurred to me
> that a write (an output change) immediately precedes the R/M/W
> instruction.  So, maybe it should be called W+R/M/W, since that's what's
> actually happening.
>
> Per Issac's message, changing a TRIS bit to cause an input to become an
> output is really another way of writing to a port pin.  And causes the same
> trouble if an RMW instruction happens too soon thereafter.
>
> The third example (analog configuration) should be able to be mimicked by
> the simulator.

I have never seen MPLAB/MPSIM missing the last case (analog pin),
which is the most simple one, of course. That is a well
documented behavour.

I'm not sure of the the middle case (writing to an digital-input
pin). When reading from an input pin (without a stimulus setup)
the value is "undefined", I guess.

The first case (capactive loading) is hard (if not impossible)
to simulate using something like MPSIM.

Jan-Erik.




>
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

Tamas Rudnai
On 25 August 2012 02:40, Jan-Erik Soderholm <[hidden email]>wrote:

> The first case (capactive loading) is hard (if not impossible)
> to simulate using something like MPSIM.
>

I have to disagree with that, already explained that a simple time stamp on
the port would do that for you. So you store the actual time tick when the
port was written, then next time you do an RMW instruction it checks if at
least 4 ticks (or any other configurable value) passed since. Knowing the
simulated fosc frequency you may even could setup the constrain of
simulated time instead of the ticks.

Also a compiler could detect RMW instructions right after each others and
display a warning, that's not a rocket science either.

With this latter one maybe Microchip could provide a kind of static
analysis tool such as lint or splint, which would help us detecting obvious
mistakes or bogus code...

http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Tamas




>
> Jan-Erik.
>
>
>
>
> >
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



--
int main() { char *a,*s,*q; printf(s="int main() { char *a,*s,*q;
printf(s=%s%s%s, q=%s%s%s%s,s,q,q,a=%s%s%s%s,q,q,q,a,a,q); }",
q="\"",s,q,q,a="\\",q,q,q,a,a,q); }
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Reply | Threaded
Open this post in threaded view
|

Re: Strange mplabx behaviour - reply Microchip

John Coppens
In reply to this post by John Coppens
On Sat, 25 Aug 2012 01:37:36 -0300
John Coppens <[hidden email]> wrote:

> Anyway, #235011 is the new ticket.

In order not to maintain the suspense, I got a reply from the bug
report yesterday, in which the (same) tech apologizes, and confirms
having sent the report to the development people.

Let's see if anything comes from it. He did indicate that the GPSIM
from MPLAB X is beta, and as such not too reliable. And that I
shouldn't use the f874 (too old) ;-)

Greetings,
John
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist