It might be the fault of the list server digesting messages incorrectly, but
the MIT PIC List digests don't get handled properly by ERage X.
They show up as email messages with two enclosures. In the body (they are
plain text digests, no HTML), I get the digest preamble (list of subjects,
etc.), and the first message.
The enclosures are titled, in this example:
PICList Digest - 15 Jan 2002 to 16 Jan 2002 (#2002-17)
Re: [PIC]: Talking to DS1616: Help!
with respective sizes of 3 K and 4K.
I expected one of these to contain the remainder of the digest, but they do
not. The first enclosure contains only the digest preamble. The second
enclosure contains the first message shown in the original received email.
The rest of the messages are not shown.
If you View Source on the incoming email, you can see all the messages. I'll
try quoting the headers and first couple of messages below for analysis
(hope they don't get interpreted by your mail client). You can see the
encompassing message is multipart/digest; don't know if ERage can use that
for anything fancy (like nicer digest browsing?)...
--Rick
> Return-Path: <[EMAIL PROTECTED]>
> Received: from mx.netgate.net (mx.netgate.net [204.145.147.77])
> by vp.netgate.net (8.9.3/8.9.3) with ESMTP id VAA08447
> for <[EMAIL PROTECTED]>; Wed, 16 Jan 2002 21:28:50 -0800 (PST)
> Received: from psmtp.com (exprod5mx12.psmtp.com [64.75.1.152])
> by mx.netgate.net (8.9.3/8.9.3) with SMTP id VAA24636
> for <[EMAIL PROTECTED]>; Wed, 16 Jan 2002 21:28:17 -0800 (PST)
> Message-Id: <[EMAIL PROTECTED]>
> Received: from source ([209.119.0.109]) by exprod5mx12.postini.com
> ([64.75.1.251]) with SMTP;
> Wed, 16 Jan 2002 21:28:17 PST
> Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com
> (LSMTP for Digital Unix v1.1b) with SMTP id
> <[EMAIL PROTECTED]>; Thu, 17 Jan 2002 0:27:01 -0500
> Date: Thu, 17 Jan 2002 00:14:24 -0500
> Reply-To: pic microcontroller discussion list <[EMAIL PROTECTED]>
> Sender: pic microcontroller discussion list <[EMAIL PROTECTED]>
> From: Automatic digest processor <[EMAIL PROTECTED]>
> Subject: PICLIST Digest - 15 Jan 2002 to 16 Jan 2002 (#2002-17)
> To: Recipients of PICLIST digests <[EMAIL PROTECTED]>
> MIME-Version: 1.0
> Content-Type: multipart/digest; boundary="JVPCQTUDKINKSSVeDTJXSZWHMFVWID"
> X-postini-filters: (C:0.0003066 M:0.0214371 P:0.0083663 S:0.0000052 )
> X-UIDL: 2fd252cf1192601718f9843a7b16c857
>
>
> --JVPCQTUDKINKSSVeDTJXSZWHMFVWID
>
> Date: Thu, 17 Jan 2002 00:14:24 -0500
> Reply-To: pic microcontroller discussion list <[EMAIL PROTECTED]>
> Sender: pic microcontroller discussion list <[EMAIL PROTECTED]>
> From: Automatic digest processor <[EMAIL PROTECTED]>
> Subject: PICLIST Digest - 15 Jan 2002 to 16 Jan 2002 (#2002-17)
> To: Recipients of PICLIST digests <[EMAIL PROTECTED]>
>
> There are 170 messages totalling 6891 lines in this issue.
>
> Topics of the day:
>
> 1. [PIC]: Talking to DS1616: Help! (3)
> 2. [PIC]: Calibration Data - JW Types (6)
> 3. [PIC]: Two PIC16F877 Questions
> 4. [SX]: "Real" IRQ driven I2C routines
> 5. [OT]: Segway ( IT ) using alot of pic's apparently :) (4)
> 6. [PIC]: [EE]: Does anyone know ED-9? (2)
> 7. [EE]: Replace old chips ? (4)
> 8. Code examples for I/R receiving
> 9. [PIC]: Code examples for I/R receiving (8)
> 10. [EE]: Good way to make a remote temp sensor? (2)
> 11. [EE]: schematics again
> 12. [EE]: lasers..
> 13. Fwd: [PIC]: [EE]: Does anyone know ED-9?
> 14. Antwort: [EE]: Good way to make a remote temp sensor?
> 15. [PIC]: Calibration Data - JW Types (follow up)
> 16. [PIC]:Ringing signal
> 17. Buffer to drive T1CLK at 5.5Mhz from 1.2v pk-pk source
> 18. [EE] Buffer to drive T1CLK at 5.5Mhz from 1.2v pk-pk source (3)
> 19. [PIC]: Beginners 16C84 programming question
> 20. [OT]: Tektronix O-Scope (3)
> 21. [EE]: Chording keyboards
> 22. Beginners 16C84 programming question (4)
> 23. [OT]: piclist alive?
> 24. [PIC]: Interfacing PIC with SMS (2)
> 25. [PIC]: C Compilers (3)
> 26. [ot]:
> 27. [PIC] C Compilters
> 28. [PIC]: programming PIC16F874 and PIC16F74 (2)
> 29. [ot] : Big John's Rotisserizer.
> 30. [ee]: photodetectors ( tag changed from OT) (9)
> 31. [ot]:keyless entry question (2)
> 32. [PIC]: Talking to 25C040 (2)
> 33. [PIC]: Eagle CAD
> 34. [PIC]:What is the correct way to terminate unused pins 16F877 (4)
> 35. +AFs-EE+AF0-: problem using HT1621 LCD controller
> 36. [OT]:keyless entry question
> 37. photodetectors ( tag changed from OT) (2)
> 38. Good way to make a remote temp sensor?
> 39. SV: [PIC]:What is the correct way to terminate unused pins 16F877
> 40. PICLIST Digest - 13 Jan 2002 to 14 Jan 2002 (#2002-15)
> 41. [EE]: transient specs (6)
> 42. [PIC]: LM7805 (2)
> 43. [PIC:] Baud Rate Generator (7)
> 44. [EE]: photodetectors ( tag changed from OT)
> 45. [PIC]:No dsPIC interrest? (11)
> 46. [OT]:Talk about your mechanically scanned display (7)
> 47. [OT]: transient specs -- jump starts
> 48. [PIC]:No dsPIC interest? (6)
> 49. [EE]: Multiple lcd displays on 1 parallel pors
> 50. [PIC]: 16f628 external resistor frequency (7)
> 51. [PIC] PICALL PIC Programmer
> 52. [PIC]: PICC bit-test methods?
> 53. [PIC]: PICALL PIC Programmer (2)
> 54. [BUY] British Telecomm jacks: where to find them? (2)
> 55. [PIC]: RTC (3)
> 56. [OT]: Memory Card for Engine Fuel Management
> 57. [EE]: What's bootstrap??? (7)
> 58. [BUY]: British Telecomm jacks: where to find them?
> 59. [OT]:Re: Spam a lot?
> 60. [PIC]:Serial Multiplexer
> 61. [EE]: Abacom RTL-DATA-SAW Radio Module (2)
> 62. [OT]: High Pressure Sodium lamp ignitor/starter
> 63. [PIC]: SPI peripheral
> 64. [PIC]: Cheap ICE for PICs
> 65. [OT]: 16f628 external resistor frequency (4)
> 66. [OT]: HNY 20000002
> 67. [BUY]: MPC2120/MCP2150 Development Kit
> 68. [PIC]:In circuit programing site
> 69. [EE]:[PIC]: X10 protocoll and pic, schematics?
> 70. [PIC]: How fast can TMR0 be driven?
>
> --
> http://www.piclist.com hint: PICList Posts must start with ONE topic:
> [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
>
>
> --JVPCQTUDKINKSSVeDTJXSZWHMFVWID
>
> Date: Wed, 16 Jan 2002 00:00:09 -0500
> From: Heinz Czychun <[EMAIL PROTECTED]>
> Subject: Re: [PIC]: Talking to DS1616: Help!
> MIME-Version: 1.0
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
> Hi Michael,
>
>
>
> At 8:05 AM -0800 1/15/02, Michael Vinson wrote:
>
> ...<snip>...
>
>>
>> What is going on? Here is a piece of my "read byte" code:
>
> ....<more snipped>...
>
>> ; The last communication with the DS1616 was sending the low-order byte
>> ; of the address for the "send page" command. The last thing it did
>> ; was cycle the sclk (clock) line high and then low. According to
>> ; the DS1616 data sheet, the next action of the DS1616 is to put the
>> ; first bit (bit 0) of the data to be read on the i/o pin.
>
> I think this may be part of the problem.....
>
> If the DS1616 is like the DS1620 then bit 0 isn't waiting but
> must be clocked out. sclk must be high when entering the read
> routine, and then brought low. The io bit can then be read into the
> PIC. I think your out of sync by one clock.
>
>> ;
>> btfsc PORTA,io ; bit 0 should be waiting for us
>> bsf dsData,0 ; Bit 0 = 1? If so, set it
>> bsf shportA,sclk ; Now cycle the clock high
>> updateA
>> bcf shportA,sclk ; Bring clock back low
>> updateA
>> nop ; Just to be sure
>>
>> ; Done with bit 0. Now read bit 1. Someday I'll make this a loop.
>>
>> btfsc PORTA,io ; Now check if bit 1 is high?
>> bsf dsData,1 ; Yes, so set it
>> bsf shportA,sclk ; Now cycle the clock high
>> updateA
>> bcf shportA,sclk ; Bring clock back low
>> updateA
>> nop ; Just to be sure
>>
>> [ Code continues to shift the bits in one-by-one by
>> repeating the previous 7 lines (with successive..............
>
>
> Also, if I may be so bold, here are my* read and write routines in
> the form of a loop......
>
> * Note: This is converted from a 12c509 fan controller done by Peter
> Lynch in August 1998
>
> ;_____________________________________________
> ; DS1620 Routines
> ;
> ; Basic write routine to output 8 bits
> ; to the DS1620
> ; the byte to send is in the txByte register
> ;_____________________________________________
> ;
> DS1620wrt
> ;
> movlw 0x08 ;
> movwf bitCount ;setup transmit count for 8 bits
> ;
> ; write loop
> ;
> DSwrtLoop
> bcf DS1620_CLK ; clock low
> bcf DS1620_DQ ; data bit lead low
> btfsc txByte, 0 ; check if bit to be transmitted is low
> bsf DS1620_DQ ; no, then data bit lead high
> ; yes, leave lead low
> nop ; short wait
> bsf DS1620_CLK ; clock bit into DS1620 on rising edge
>
> rrf txByte, F ; right shift transmit bit
> decfsz bitCount, F ; decrement bit count
> goto DSwrtLoop ; do it again, if bit count not zero
> ; continue on bit count = zero
> return
> ;_____________________________________________
> ;
> ; Basic read routine, reads 8 bits of data from DS1620
> ; First the read command in txByte has already been sent
> ; Leaves data in the rxByte register
> ;_____________________________________________
> ;
> DS1620rd
> ;
> ; Use rMask to set the DQ bit to an
> ; input to receive the next 8 bits
> ;
> movlw rMask ; set the DQ pin as input
> tris portB
> ;
> ; receive 8 bits
> ;
> movlw 0x08 ; setup transmit counter for 8 bits
> movwf bitCount
> ;
> DSrdLoop
> rrf rxByte, F ; right shift rxByte register
> bcf rxByte, 7 ; clear msb
> bcf DS1620_CLK ; lower clock lead
> nop ; short wait
> btfsc DS1620_DQ ; check DS1620 Data lead
> bsf rxByte, 7 ; no, then set msb
> bsf DS1620_CLK ; raise clock lead
> decfsz bitCount, F ; dec bit count, and check for zero
> goto DSrdLoop ; not zero, go around again
> ; if zero last bit received
> ;
> bcf DS1620_RST ; deselect DS1620
> movlw wMask ; reset 0x00 as output
> tris portB
> return
> ;------------------------------------------------------------
>
> --JVPCQTUDKINKSSVeDTJXSZWHMFVWID
>
> Date: Wed, 16 Jan 2002 16:44:53 +1100
> From: Sean Alcorn - Avion Sydney <[EMAIL PROTECTED]>
> Subject: [PIC]: Calibration Data - JW Types
> MIME-Version: 1.0
> Content-Type: text/plain; charset="US-ASCII"
> Content-Transfer-Encoding: 7bit
>
> Hi all,
>
> When I first started mucking around with PICs, I bought 6 x PIC12C509A/JW
> and 6 x PIC12C671/JW - which are not cheap devices. I have since found out
> that erasing these with a UV Eraser actually erases the OSCCAL data for the
> internal clock.
>
> Apparently, I should have read this data when the chips were new, recorded
> the number for each chip, then re-written the calibration data each time I
> write to that particular chip. This I did not do. :-(
>
> Is there any method of retreiving this data or are the chips useless? I
> assume that I can still use them with an extenal clock, but then that leaves
> less I/O.
>
> Regards,
>
> Sean
>
> --JVPCQTUDKINKSSVeDTJXSZWHMFVWID
[ Remainder deleted; more messages followed ]
--
To unsubscribe:
<mailto:[EMAIL PROTECTED]>
archives:
<http://www.mail-archive.com/entourage-talk%40lists.letterrip.com/>
old-archive:
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
