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-tp22268503p22274495.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