The code is not bad but shoud be understoud before trying to
implemend. There are thousends users running trains using this
protocol and it is well doumenten. Better than most other 
Harry 

> -----Oorspronkelijk bericht-----
> Van: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] 
> Namens bathini
> Verzonden: zondag 1 maart 2009 17:08
> Aan: piclist@mit.edu
> Onderwerp: Re: [PIC] RS232 to PIC16F628 to DC Motor
> 
> 
> Hi Olin
> 
> Thanks for your response. The standards I am following is this
> 
> http://www.nmra.org/standards/DCC/standards_rps/S-92-2004-07.pdf 
> 
> I made preamble 8bit to simplify but should be 10 or more 
> bits in reality.
> The idea is to see how a packet gets transmitted.  I am 
> basically controlling trains via motor and PIC. I have been 
> trying to learn the code which is bad, and I am a newbie.
> 
> I will have a read at QQQ_CMD.ASPIC template module to learn 
> from it. Thanks
> 
> Bathini
> 
> 
> 
> 
> Olin Lathrop wrote:
> > 
> > bathini wrote:
> >> I am going to send a packet via PC serial port to control 
> a small DC 
> >> motor via the PIC16F628 microcontroller. The packet is 
> going to be 4
> >> bytes(4 X 8bit).
> > 
> > Where did you dream up this protocol?  Did you copy it from a
radio 
> > link device possibly?  Even then it's poorly designed.  You can 
> > usually ignore errors in direct RS-232 links between a PIC 
> and a PC.  
> > Unless you're going long distances, have possible ground loop 
> > problems, etc, the bytes are going to get to the PIC just 
> as they were 
> > transmitted by the PC.  I've done this many times.
> > 
> > Also, what is the cost of the motor getting the wrong speed 
> command?  
> > Does it get another one every 100mS, every 1S, something else?
How 
> > serious is a outright motor failure?  If it's serious, you
probably 
> > need some talk back.
> > 
> >> Byte 1 is preamble and should all be 8 ones(11111111)
> > 
> > What the heck for?  This is silly.
> > 
> >> Byte 2 is address of motor(Can make up any number)
> > 
> > So there could be multiple motors connected to the PIC?  If 
> so, this 
> > makes sense.  If each PIC only controls a single motor, 
> then there is 
> > no point to this since RS-232 is point to point.
> > 
> >> Byte 3 is data byte, 4 bits for speed and 1 bit for direction
> > 
> > You've got 8 bits, so it would make a lot more sense to use 
> them all 
> > for the speed and direction.  Future implementation might have
more 
> > than 4 bit speed resolution.  It's easy enough to ignore 
> low bits if 
> > you can't use them.  I would probably use a signed 8 bit 
> speed value.  
> > That is trivial to convert to the 4 bit speed and one bit
direction 
> > required by this particular version of the firmware.
> > 
> >> Byte 4 is for error detection, if the address of the motor 
> is not the 
> >> one mentioned on Byte 2, or preamble is not all ones, then 
> drop the 
> >> packet.
> > 
> > Look up something called a "checksum".  If you really want to
spend 
> > bits to deal with bad received data due to a noisy channel, 
> use a real 
> > checksum instead of redundant bits.  Even though the data 
> is sent and 
> > received as whole bytes by the software at each end, it is
actually 
> > sent serially over the noisy channel.  That makes a CRC a good 
> > candidate for a checksum.  You could use some sort of hash
function 
> > based on the other bytes, but judging from your level of expertise

> > designing a protocol, you'd be better off leaving the checksum to 
> > others that actually understand something about error detection
and 
> > correction.
> > 
> >> So I imagine you will OR the packet.
> > 
> > Huh?
> > 
> > Here is what I would use for a protocol.  I've done this many
times 
> > and even have template firmware ready for exactly this type of 
> > protocol:
> > 
> > 1 - All data is transmitted in packets that start with a 
> opcode byte, 
> > which is then followed by data bytes depending on the opcode.
This 
> > allows a easy growth path for sending additional information later

> > that wasn't envisioned originally.  That happens all the time.
> > 
> > 2 - For clarity of documentation, I call packets sent from 
> the host to 
> > the PIC "commands" and packets sent from the PIC to the 
> host "responses".
> > This
> > doesn't mean that all response are in direct response to 
> commands, or 
> > that there are even any at all, but using this wording up 
> front leaves 
> > a clear path for sending and receiving more data and keeps things 
> > straight from the beginning.
> > 
> > 3 - Reserve opcode 0 as a NOP in both directions.
> > 
> > 4 - All numbers are unsigned bytes unless there is a good 
> reason they 
> > have to be something else.
> > 
> > I would make the motor speed command:
> > 
> >   MOTSPEED: 1 adr speed
> > 
> >     Where 1 is the opcode, ADR is the 8 bit motor address, and
SPEED
> >     is the signed 8 bit speed.
> > 
> > If there really is some issue you haven't told us about and 
> you really 
> > do need to protect against corrupted packets, follow each 
> packet with 
> > a 8 or
> > 16
> > bit CRC.  However, you need to actually think this thru.  If you 
> > expect corrupted packets, then you also have to expect dropped and

> > possibly inserted bytes.  That can get very tricky, 
> especially since 
> > the firmware doesn't have access to the low level bits.  
> You have to 
> > implement talk back to deal with this properly, and frankly the 
> > details are over your head.
> > Just send the data as I suggested above and don't worry about data

> > channel errors since there won't be any anyway.
> > 
> > You can take a look at my QQQ_CMD.ASPIC template module.  It is a 
> > template for implementing axactly the kind of opcode/data 
> protocol I 
> > described above.
> > You can see the implementation of it in the HOS example 
> project where 
> > two ASCII characters were defined as opcodes so you have 
> two keys in a 
> > terminal emulator to turn the LED on and off.
> > 
> > My low level program TEST_SIO is very useful for initial testing
of 
> > this kind of protocol.
> > 
> >>          CBLOCK H'0C'
> >>            txreg              ; holds byte to be transmitted
> > 
> > Yikes!  That is really really bad code.  This is a special
function 
> > register and is therefore defined in the include file.  
> Don't try to 
> > define SFRs yourself.  This just goes to show any moron can 
> post code 
> > on the net, and unfortunately all too many do.
> > 
> > Whoever wrote this mess was totally clueless.  Get out of here
now.
> > Commenting on the rest of the code would be pointless.
> > 
> > 
> >
********************************************************************
> > Embed Inc, Littleton Massachusetts,
http://www.embedinc.com/products
> > (978) 742-9014.  Gold level PIC consultants since 2000.
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive View/change your 
> > membership options at 
> http://mailman.mit.edu/mailman/listinfo/piclist
> > 
> > 
> 
> --
> View this message in context: 
> http://www.nabble.com/RS232-to-PIC16F628-to-DC-Motor-tp2226850
> 3p22274492.html
> Sent from the PIC - [PIC] mailing list archive at Nabble.com.
> 
> --
> 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