Interesting calculations Eric. It was the 877 I had in mind when I first looked at this project, mostly because I have a few of them in my box, but also for some reason I miscalculated that they could give me the data rate I need. The project is a teletext data encoder which takes an existing video stream, extracts the sync pulses, calculates when and where to place the data, and then.. places it. Unfortunately I was a factor of 10 out ( doh! ). The data rate I need is about 6.9Mbits per second (or 144ns per bit), the protocol doesnt use start or stop bits, but synchronises the serial clock at the beginning of every scan line by sending binary 1010101010101010 for the clock and then another 8 bits to get the framing reference.. 11000100 or something like that. The actual data layer of the protocol uses hamming codes for a couple of important pieces of data, not everything needs to be encoded, and it can be done in advance rather than on the fly- probably the best way to do it. The teletext encoder has been done before but not with a single pic/sx processor. I want to do it because I like the idea of writing games that use teletext graphics for the pic, and I had then idea that instead of firing up outlook express I could visit a teletext page when I got home from work to see if I had any emails and read them as necessary. That and a multitude of other projects like weather monitors, so I could watch wind speed and direction etc.. without having to stick an LCD to everything I build. I think the project will end up running on an SX, but I will post any source I come up with to the piclist or sxlist sites. Jon Baker ----- Original Message ----- From: "Eric Smith" To: Sent: Tuesday, February 05, 2002 1:44 AM Subject: Re: [PIC]: Hamming codes > Andrew Warren writes: > > P.S. If you're using 18,24 Hamming, you won't be able to get > > anywhere near 7Mb/s encoding or decoding with a PIC. > > On a 20 MHz PIC (e.g., PIC16F877), it looks like it should be possible > to get over 3.2 Mb/s encoding (4.3 Mb/s output rate). Assume that the > 18 data bits are all supplied in parallel, with a strobe line on port A > that toggles on alternate input frames. Two of the input bits are on > port A. The other 16 input bits are on ports B and C. The 6 error > correction bits are output on port D. > > On a PIC18, the 7 Mb/s is nearly within reach. On a Ubicom SX48, you > could do 7 Mb/s encode AND decode, with cycles left over. > > In practice, a CPLD would probably be a better choice for this > application. > > > movlw table1,w > movwf pclath > > loop0: btfss porta,strobe > goto loop0 > > bcf pclath,1 > > movf portb,w > call table0 > movwf check > > movf portc,w > call table > xorwf check > > movf porta,w > call table > xorwf check,w > movwf output > > loop1: btfss porta,strobe > goto loop1 > > bcf pclath,1 > > movf portb,w > call table0 > movwf check > > movf portc,w > call table > xorwf check > > movf porta,w > call table > xorwf check,w > movwf output > > goto loop0 > > > table: incf pclath > table0: movwf pcl > > > ; [...] > > org 0400h ; must be a multiple of 0400h > > table1: retlw data... ; 256 entries, indexed by port B > > table2: retlw data... ; another 256 entries, indexed by port C > > table3: retlw data... ; final 256 entries, indexed by two bits of port A > ; NOTE: this is 64 duplicate sets of 4 entries, > ; because the port A input byte only contains > ; two data bits - could save 252 words of table > ; space by adding an "andlw" instruction in the > ; loop, at a slight performance penalty > > -- > http://www.piclist.com#nomail Going offline? Don't AutoReply us! > email listserv@mitvma.mit.edu with SET PICList DIGEST in the body > -- http://www.piclist.com#nomail Going offline? Don't AutoReply us! email listserv@mitvma.mit.edu with SET PICList DIGEST in the body