Searching \ for '[PIC] RS232 to PIC16F628 to DC Motor' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/ios.htm?key=motor
Search entire site for: 'RS232 to PIC16F628 to DC Motor'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] RS232 to PIC16F628 to DC Motor'
2009\02\28@191148 by bathini

picon face

Friends

I am having a hard time programming in assembly.


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

Byte 1 is preamble and should all be 8 ones(11111111)
Byte 2 is address of motor(Can make up any number)
Byte 3 is data byte, 4 bits for speed and 1 bit for direction
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. So I
imagine you will OR the packet.

If the packet passes the above conditions (Byte 1 and Byte 2, byte 3), RA0
pin will go high and the motor will spin in one direction, if RA0 is a low,
the motor will spin in the other direction

Byte 3 will utilize the CCP/PWM module of the PIC16F628 to alter speed, so
that is pin 9 on the PIC.

This is quite tricky for me. Any help? Here is a code I got from
http://www.piclist.com

;-----------------------------------------------------------------------;
; ALPHABET.ASM        Send and Receive serially at 1200 baud to PC      ;
;-----------------------------------------------------------------------;

;-----------------------------------------------------------------------;
;        the next 5 lines are directions to the assembler               ;
;-----------------------------------------------------------------------;

       LIST P=16F628           ;  tells which processor is used
       INCLUDE "p16F628.inc"   ;  defines various registers etc. Look it
over.
       ERRORLEVEL -224        ;  supress annoying message because of tris
       __CONFIG _PWRTE_ON &_LP_OSC &_WDT_OFF   ;  configuration switches

        CBLOCK H'0C'
          txreg              ; holds byte to be transmitted
          rxreg              ; holds byte received
          char               ; holds character to be transmitted
          bitcount           ; holds count of bits when transmitting
          timecnt            ; holds counter for timer
        ENDC

          ORG 0              ; start a program memory location zero
          goto main          ; skip over subroutines

;-----------------------------------------------------------------------;
;          initialization - set up ports and timer options              ;
;-----------------------------------------------------------------------;
init:
        movlw B'00000000'    ; RA0 to output
        tris PORTA           ; contents of W copied to PORT A ...
        movlw 0
        tris PORTB           ; and PORT B
        movlw B'00000001'    ; pull-ups active
                             ; prescalar assigned to TMR0 and set 1:4
        option               ; rolls over each second
        return

;-----------------------------------------------------------------------;
;                        time delay routines                            ;
;-----------------------------------------------------------------------;
eighth:
         movlw 1              ; wait 1/8 th second
         goto $ +2            ; jump over
onesecond:
         movlw D'8'           ; wait one second
         movwf timecnt
         clrf TMR0
         bcf INTCON, T0IF     ; clear the interrupt flag
         btfss INTCON, T0IF   ; wait on T0IF to be set
         goto $ -1            ; loop till it is
         decfsz timecnt, f    ; finished timing?
         goto $ -3            ; not yet
         return               ; yes


;-----------------------------------------------------------------------;
;                     the main program                                  ;
;-----------------------------------------------------------------------;
main:                         ; this is the main program
        call init            ; set up ports
        call onesecond       ; let things settle for 1 second
loop:
        call rx              ; get a character from keyboard
        movwf char           ; save so we can increment it
        incf char, f         ; send back the next 3 characters
        movf char, W
        call tx
        incf char, f
        movf char, W
        call tx
        incf char, f
        movf char, W
        call tx
        goto loop            ; do it forever

;-----------------------------------------------------------------------;
;                 transmit byte in W at 1200 baud out RB7               ;
;-----------------------------------------------------------------------;
; normal rs232 is -V for a high, +V for a low
; this would translate to 0V for high +5 for low
tx:
        movwf txreg          ; set up transmit register
        comf txreg, f        ; flip all bits
        movlw D'8'           ; eight bits to transmit
        movwf bitcount
        bsf PORTB, 7         ; start bit (+5V is 'low')
        nop                  ; a total of 7 instruction cycles
        nop                  ; (one is the rrf at txloop)
        nop
        nop
        nop
txloop:
        rrf txreg, f         ; lsb out of txreg into carry
        rrf PORTB, f         ; bit 7 of port B high or low with carry
        nop                  ; make total loop delay 7 instruction counts
        nop                  ; 7 * 122 usec = 854, (should be 833)
        decfsz bitcount, f   ; 4 instruction cycles to here
        goto txloop          ; total 4 + 3 = 7 instructions cycles in loop
        bcf PORTB, 7         ; 0 Volts is the 'high' state this is
        nop                  ; stop bit
        nop                  ; delay 7 instruction cycles
        nop
        nop
        return

;-----------------------------------------------------------------------;
;             receive byte  at 1200 baud in RB0, put in W               ;
;-----------------------------------------------------------------------;
rx:      movlw 8              ; eight bits to input
        movwf bitcount
waitstart:
        btfss PORTB, 0       ; wait for input to go high, (start bit)
        goto waitstart
        nop                  ; wait 1/2 start bit time 3 including branch
        nop                  ; next four instruction are to make
        nop                  ; 1 bit time delay before first reading of
        nop                  ; input port
        nop
receive:
        nop                  ; make total loop delay 7 instruction counts
        nop                  ; 7 * 122 usec = 854, (should be 833)
        rrf PORTB, f         ; PORT B bit 0 into carry
        rrf rxreg, f         ; rotate carry into receive register
        decfsz bitcount, f   ;
        goto receive         ; total 4 + 3 = 7 instructions cycles in loop
        comf rxreg, W        ; return compliment of value collected
        nop                  ; wait at least one stop bit
        nop
        nop
        nop
        return

        end


Thanks friends

Bathini
--
View this message in context: www.nabble.com/RS232-to-PIC16F628-to-DC-Motor-tp22268503p22268503.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\02\28@220006 by jim

flavicon
face
Bathini,

Do you have an "H" bridge or "Half H" bridge to control the motor?
Or are you going to use the PIC and some pass transistors?
If you want to control direction with just one pin, you'll have to have
some sort of switching arrangement to be able to switch direction.

The remaining details are nothing more than receiving the byte, doing
a comparison to see if it is what you expect, and then sending the
correct portion of the byte to the respective place to be acted upon.

I can work on this a little bit tomorrow.  I don't have time right now
though.
If someone else doesn't already have it figured out for you by tomorrow,
I'll send you what I come up with then.

Regards,   Jim



{Original Message removed}


'[PIC] RS232 to PIC16F628 to DC Motor'
2009\03\01@073053 by Richard Seriani
picon face

----- Original Message -----
From: "bathini" <spam_OUTwozamfethuTakeThisOuTspamyahoo.es>
To: <.....piclistKILLspamspam@spam@mit.edu>
Sent: Saturday, February 28, 2009 7:11 PM
Subject: [PIC] RS232 to PIC16F628 to DC Motor


>
> Friends
>
> I am having a hard time programming in assembly.
>

What part of programming in assembly are you having a problem with?

{Quote hidden}

<snipped code>

Again, what part is tricky for you?
What have you done, so far (other than finding some RS232 code on piclist)?
What part of your project are you having problems with?


Richard



2009\03\01@083346 by bathini

picon face

Hi Jim

Thanks for your response and appreciate it. I have designed the following
circuit

http://home.cogeco.ca/~rpaisley4/HBridge.html - The last circuit from the
bottom with Decoder/motor block

This is the circuit I am trying to control with 4 bytes. I tested the
circuit with square wave function generator and varied the duty cycle and it
worked like a charm.

What I think for design:

RA0 pin on the PIC connected to pin 2 of the LM311 - A high (5V) will turn
the motor, a low(0V) will turn the motor to different direction

CCP pin(PWM) on the PIC connected to one of the strobe, while the other is
connected to a low(0V) - This is for pulse modulation

Thanks

Bathini







jim-142 wrote:
{Quote hidden}

> {Original Message removed}

2009\03\01@083855 by bathini

picon face

Hi Richard

Thanks for your response. I guess my difficulty was knowing where to
incorporate the preamble byte, address and error detection byte. Thanks

Bathini



Richard Seriani wrote:
>
>
> {Original Message removed}

2009\03\01@094123 by olin piclist

face picon face
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.

2009\03\01@110832 by bathini

picon face

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:
{Quote hidden}

> --

2009\03\01@110901 by bathini

picon face

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:
{Quote hidden}

> --

2009\03\01@112549 by olin piclist

face picon face
bathini wrote:
> Thanks for your response. The standards I am following is this
>
> http://www.nmra.org/standards/DCC/standards_rps/S-92-2004-07.pdf

But that is totally different from RS-232.  I don't see how DCC relates to
anything you asked about.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\01@114019 by PPA

flavicon
face

Hi,


bathini wrote:
>
> Thanks for your response and appreciate it. I have designed the following
> circuit
> http://home.cogeco.ca/~rpaisley4/HBridge.html - The last circuit from the
> bottom with Decoder/motor block
>

Warning: these schematics are a bit dangerous. If strobed off, the
darlington output stages inputs are floating and can get noise that may
switch on and damage the bridge. Pullups and pulldowns should be added.

Regards,

Philippe.

-----
Best regards,

Philippe.

http://www.pmpcomp.fr Pic Micro Pascal for all!
--
View this message in context: www.nabble.com/RS232-to-PIC16F628-to-DC-Motor-tp22268503p22274856.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\03\01@121609 by David Harris

picon face
Olin -

DCC was designed to talk to a model train engine equiped with a  
'decoder' through the pair of rails and the engine's wheels. It  
supplies ppwer and signal.  As such it is a very noisy and  
intermittent connection. The packets are send recurrently to mitigate  
this.

The protocol has historic roots and so is rather messy in its details,  
as these developed as extensions, but we are stuck with it. It is a  
standard that lets many manufacturer's products work together.

You may be amused or dismayed by the news that it is being extended to  
be bidirectional.

David




On 1-Mar-09, at 8:25, olin_piclistspamKILLspamembedinc.com (Olin Lathrop) wrote:

{Quote hidden}

> --

2009\03\01@123856 by olin piclist

face picon face
David Harris wrote:
> DCC was designed to talk to a model train engine equiped with a
> 'decoder' through the pair of rails and the engine's wheels. It
> supplies ppwer and signal.  As such it is a very noisy and
> intermittent connection. The packets are send recurrently to mitigate
> this.
>
> The protocol has historic roots and so is rather messy in its details,
> as these developed as extensions, but we are stuck with it. It is a
> standard that lets many manufacturer's products work together.
>
> You may be amused or dismayed by the news that it is being extended to
> be bidirectional.

I have a friend who is into model railroading, and have looked at the DCC
spec before.  I understand what it is, and it basically makes sense for the
original intent.  However, the OP was asking about data from a serial port
from a PC, which has nothing to do with DCC.  I'm thinking the OP
understands neither RS-232 nor DCC nor that the two can't just be
interchanged.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\01@145751 by bathini

picon face

It is true DCC is messy. However, what I am trying to do is emulate decoder.

I went to this site to view the .asm and decided it was too complicated for
my liking.

http://www.merg.co.uk/resources/16f628.asm


I decided to make it simple by imagining receiving bytes on the serial Rx
pin on the PIC16F628, with logic code in the PIC. I enable a high on one of
the out pins e.g RA0  and then the motor spins. If its a low then it spins
the other direction.

Unless if there is a way to send bytes/packet to the PIC16F628 without
serial port? Thanks

Bathini  





Olin Lathrop wrote:
{Quote hidden}

> --

2009\03\01@172432 by Harry H. Arends

flavicon
face
Who, are you getting into DCC or just adopting the protocol.
There are several DCC controller, stations of controlling DCC equipt
locomotives with a DC motor.
If so then you shoul not place yot question here but in come DCC
orientated groups on the net.

DCC is a protocol used with model trains and is as ypu should know for
controlling up to 1024 simple devices on a bus.

Harry
{Quote hidden}

radio
{Quote hidden}

How
> > serious is a outright motor failure?  If it's serious, you
probably
{Quote hidden}

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
{Quote hidden}

SPEED
{Quote hidden}

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

2009\03\01@172615 by Harry H. Arends

flavicon
face
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

{Quote hidden}

radio
{Quote hidden}

How
> > serious is a outright motor failure?  If it's serious, you
probably
{Quote hidden}

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
{Quote hidden}

SPEED
{Quote hidden}

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

2009\03\01@172702 by Harry H. Arends

flavicon
face
Totaly correct

> -----Oorspronkelijk bericht-----
> Van: spamBeGonepiclist-bouncesspamBeGonespammit.edu [TakeThisOuTpiclist-bouncesEraseMEspamspam_OUTmit.edu]
> Namens Olin Lathrop
> Verzonden: zondag 1 maart 2009 17:26
> Aan: Microcontroller discussion list - Public.
> Onderwerp: Re: [PIC] RS232 to PIC16F628 to DC Motor
>
> bathini wrote:
> > Thanks for your response. The standards I am following is this
> >
> > www.nmra.org/standards/DCC/standards_rps/S-92-2004-07.pdf
>
> But that is totally different from RS-232.  I don't see how
> DCC relates to anything you asked about.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014.  Gold level PIC consultants since 2000.
> -

2009\03\01@172901 by Harry H. Arends

flavicon
face
O shit and thats cousing more problems than before.
Harry
{Quote hidden}

wrote:
{Quote hidden}

********************************************************************
> > Embed Inc, Littleton Massachusetts,
http://www.embedinc.com/products
> > (978) 742-9014.  Gold level PIC consultants since 2000.
> > --

2009\03\01@173308 by cdb

flavicon
face
You might want to check around the Elektor website and it's back
issues. They love DCC projects and have had varying amounts of them
over the last few years - code is free download.

Colin
--
cdb, RemoveMEcolinEraseMEspamEraseMEbtech-online.co.uk on 2/03/2009

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359






2009\03\01@173343 by Harry H. Arends

flavicon
face
No DCC is not that a problem but one shuold understand it use and
purpose. The protocol can be used for controlling unidirectional
devices by just sending a command sequnce to a decoder. Just google
for DCC and manufac. And you wil find many threats and als schematics
for both decoders and encoders.

Harry
{Quote hidden}

two
> > can't just be interchanged.
> >
> >
> >
********************************************************************
> > Embed Inc, Littleton Massachusetts,
http://www.embedinc.com/products
> > (978) 742-9014.  Gold level PIC consultants since 2000.
> > --

2009\03\01@174049 by Harry H. Arends

flavicon
face
Yes command station code but no decoder code

{Quote hidden}

> -

2009\03\01@190417 by David Harris

picon face
Hi-

You need to describe more exactly what you are trying to do.  We can
help, but need to know more.   For example, where are you getting your  
DCC-feed from:  The track?  From a PC program?

David


bathini wrote:
{Quote hidden}

>> --

2009\03\01@212003 by William \Chops\ Westfield

face picon face

On Mar 1, 2009, at 9:39 AM, Olin Lathrop wrote:

> I understand what [DCC] is ... However, the OP was asking about data  
> from a serial port from a PC, which has nothing to do with DCC.  I'm  
> thinking the OP understands neither RS-232 nor DCC nor that the two  
> can't just be interchanged.

I think it makes a lot of sense to prototype the motor drive code that  
the OP is asking about with a "simpler" communications channel in  
front of it (rs232 serial instead of DCC.)  After the packet handling  
and motor chip control is working ok, you can "drop in" a known  
working DCC module in place of the rs232.

I do things like this all the time, all the way up to compiling  
microcontroller C code under linux and running it in a mode where what  
will eventually be pin inputs is provided via keyboard or debugger.  
It's very useful.

All that said, it ISN'T clear that this is the sort of thing that the  
OP has in mind, but I don't THINK any of his questions are about the  
protocol design, either?  Improved clarity in the questions would be  
nice, but we don't have to go off chasing non-issues either...

BillW

2009\03\02@002907 by William \Chops\ Westfield

face picon face

On Feb 28, 2009, at 4:11 PM, 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).
     :
> This is quite tricky for me. Any help? Here is a code I got from http://www.piclist.com

The code you quote (shown partially below), is for a software "bit-
banged" serial implementation, and apparently one designed for a very  
slow pic (32786 Hz Crystal) as well.  This would require significant  
effort to convert for a more typical 16f628 setup (although you can  
probably find an example for faster clock rates.)  Moreover, the 628  
has a hardware USART peripheral, and it would almost certainly be much  
easier to use that (and you can find examples of how to set THAT up as  
well.)

This is assuming that the serial communications part is where you are  
having problems, which I think you STILL haven't clarified...

BillW

>
> ;-----------------------------------------------------------------------;
> ; ALPHABET.ASM        Send and Receive serially at 1200 baud to  
> PC      ;
> ;-----------------------------------------------------------------------;
       :
{Quote hidden}

A 122 usec instruction time implies (4 * (1 / 122E-6)) clock rate:  
32768 kHz.
{Quote hidden}

2009\03\02@034443 by bathini

picon face

BillW

Thanks for your response. It is true I want to implement something simple
than DCC. If
you notice my first post on top I did not even mention DCC, because I know
its tricky. However,
I wanted to implement and learn simpler communication and then go to DCC
when I am comfortable.  

E.g byte 1 is 8 bits ones - Preamble  (DCC is 14 ones)
    byte 2 is 8bits - address of the motor
    byte 3 is 8bits - speed and direction
    byte 4 is 8bits - Checksum or error detection

I was going to use this utility to send the bytes to the PIC:

http://www.pololu.com/docs/0J23 - Serially control the motor, I would
probably use the 4byte command, to satisfy the above condition.

To alter speed and direction the bits on byte 3 will change,

I think they have something close to similar here -
http://www.pololu.com/catalog/product/276/resources but the code they have
is for python and .NET and do not believe they have preamble etc.

Thanks

Bathini




William &quot;Chops&quot; Westfield wrote:
{Quote hidden}

> --

2009\03\02@080149 by olin piclist

face picon face
William Chops" Westfield" wrote:
> but I don't THINK any of his questions are about the
> protocol design, either?

Yes, his stated question didn't appear to be about that, but his true
problem may be all about that.  You've been around here long enough to know
that a good chunk of the time someone asks the wrong question, especially
when it's as poorly described as this OP's.

> Improved clarity in the questions would be nice,

Or essential.

> but we don't have to go off chasing non-issues either...

You can't tell what is a issue and what isn't until the OP clarifies what he
really wants.  From the little bit of information the OP has provided, it
seems to me he glanced at the DCC spec, didn't bother undrestanding it, and
thinks he can send the same data from a PC via a COM port.  If so, there are
so many misconceptions in there it's hard to know where to begin.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\03@020721 by James Alspach

flavicon
face
It may be more work than all of the above but, the MIT model train club
controls their trains without DCC.  They use a PWM type setup to control
blocks of track.  By switching the polarity they can reverse the trains and
by checking the resistance between the rails (between pulses) they can
determine block occupancy.  What is really nice is that it uses dumb
locomotives.
http://tmrc.mit.edu/sys3/

Just a thought.  If nothing else it is a cool system to read about.

James

On Mon, Mar 2, 2009 at 5:01 AM, Olin Lathrop <KILLspamolin_piclistspamBeGonespamembedinc.com>wrote:

{Quote hidden}

> -

2009\03\03@060956 by bathini

picon face

Hello James

I am from the MIT model train club. It is interesting, I thought DCC was the
only one out there.It
is a cool read in deed.

Regards



James Alspach-2 wrote:
{Quote hidden}

>> --

2009\03\03@112327 by James Alspach

flavicon
face
Since I found your site a year or two ago I have thought off an on about
trying something similar although more scaled back and perhaps lacking  a
few of the features.
Right now I just don't have the space but one of my longer term plans is to
set up the couple of trains and little bit of track that I have and start to
work towards this.
For now though, I have enough projects in the queue to worry about.  I need
to finish my Cub Scout PIC controlled water rocket launcher, before summer
rolls around.
Anyway, thanks for the long term goal.  T
Talk to you later;

James

P.S. While I would prefer to build it my self, I am surprised that you have
not commercialized your control system. It sounds like each of the modules
could be packaged and sold in hobby shops and then just added to a system as
needed.  Maybe it requires more tweaking than is immediately obvious though.



On Tue, Mar 3, 2009 at 3:09 AM, bathini <@spam@wozamfethu@spam@spamspam_OUTyahoo.es> wrote:

{Quote hidden}

2009\03\03@121126 by William \Chops\ Westfield

face picon face

On Mar 2, 2009, at 12:44 AM, bathini wrote:

> I was going to use this utility to send the bytes to the PIC:
> http://www.pololu.com/docs/0J23


What a cute little app!  Thanks for bringing it to my attention!

(It's a little GUI form with "single byte" through "6-byte" fields and  
"send" buttons that you can fill in to have "commands" sent to a  
configurable serial port.  Utterly "trivial", but ... very handy  
looking for any sort of "serial peripheral" that isn't actually text  
based.)

BillW

2009\03\03@125301 by olin piclist

face picon face
William Chops" Westfield" wrote:
> What a cute little app!  Thanks for bringing it to my attention!
>
> (It's a little GUI form with "single byte" through "6-byte" fields and
> "send" buttons that you can fill in to have "commands" sent to a
> configurable serial port.  Utterly "trivial", but ... very handy
> looking for any sort of "serial peripheral" that isn't actually text
> based.)

I didn't look at the app you described, but I use my TEST_SIO program for
manual testing of binary protocols over a serial port.  You can send ASCII
characters and bytes in HEX, decimal, or with explicit radix.  Received
bytes are shown in HEX, decimal, and ASCII.

I've got something similar, called TEST_TCP, for TCP connections.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\03@140402 by Mark Rages

face picon face
On Tue, Mar 3, 2009 at 11:53 AM, Olin Lathrop <.....olin_piclistspam_OUTspamembedinc.com> wrote:
> HEX, decimal, and ASCII.

ASCII is an acronym, but why do you capitalize hex?

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
TakeThisOuTmarkrages.....spamTakeThisOuTmidwesttelecine.com

2009\03\03@151658 by Charles Rogers

flavicon
face

----- Original Message -----
From: "Olin Lathrop" <TakeThisOuTolin_piclistKILLspamspamspamembedinc.com>
To: "Microcontroller discussion list - Public."



| I didn't look at the app you described, but I use my TEST_SIO program for
| manual testing of binary protocols over a serial port.  You can send ASCII
| characters and bytes in HEX, decimal, or with explicit radix.  Received
| bytes are shown in HEX, decimal, and ASCII.
|
| I've got something similar, called TEST_TCP, for TCP connections.


Do you do all this from the command prompt ? ?

CR

2009\03\03@152931 by olin piclist

face picon face
Charles Rogers wrote:
>> I didn't look at the app you described, but I use my TEST_SIO
>> program for manual testing of binary protocols over a serial port.
>> You can send ASCII characters and bytes in HEX, decimal, or with
>> explicit radix.  Received bytes are shown in HEX, decimal, and ASCII.
>>
>> I've got something similar, called TEST_TCP, for TCP connections.
>
> Do you do all this from the command prompt ? ?

Of course.  How do you imagine clickety-clicking your way thru sending a
bunch of binary bytes, a drop down menu with 0-255?


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\03@153551 by Richard Prosser

picon face
Bray's Terminal seems to do everything the app does - and a lot more as well!

RP

2009/3/4 Charles Rogers <.....crogersspamRemoveMEtotelcsi.com>:
>
> {Original Message removed}

2009\03\03@161315 by Matt Pobursky

flavicon
face
On Wed, 4 Mar 2009 09:35:50 +1300, Richard Prosser wrote:
> Bray's Terminal seems to do everything the app does - and a lot more as
> well!

I was going to say the same thing -- I pretty much use Bray's Terminal on a
daily basis.

Matt Pobursky
Maximum Performance Systems

2009\03\03@161342 by Bob Blick

face
flavicon
face

On Wed, 4 Mar 2009 09:35:50 +1300, "Richard Prosser"
<RemoveMErhprosserspamspamBeGonegmail.com> said:
> Bray's Terminal seems to do everything the app does - and a lot more as
> well!

The tough thing with Bray's terminal is you don't know what it's going
to do - the layout is so bad and there's no documentation. But I do find
it useful for displaying received binary data. And it is extremely slow.
Send it more than 30 characters per second and it starts buffering.

Cheers,

Bob

--
http://www.fastmail.fm - The professional email service

2009\03\03@181539 by William \Chops\ Westfield

face picon face

>
>>>> http://www.pololu.com/docs/0J23
>>> [Olin's alternative TEST_SIO]
>> Do you do all this from the command prompt ? ?
> Of course.  How do you imagine clickety-clicking your way thru  
> sending a bunch of binary bytes

That's what I thought was so nice about the pololu app; it looked to  
me like they had hit a particularly good compromise between GUI and  
CLI-like behavior.  All too often when I need to do something like  
this, I end up deciding that the easiest way to do what I want is to  
write a quick little C program that outputs exactly the bytes I want  
it to; I suppose that if I did it often I'd wind up with something  
like TEST_SIO.  The pololu app looks to do quite a reasonable job of  
wrapping that sort of functionality into a "modern" (GUI) skin.  (this  
IS just by looking at it briefly.  It might have major annoyances in  
practice...)

BillW

2009\03\03@182446 by olin piclist

face picon face
William Chops" Westfield" wrote:
> The pololu app looks to do quite a reasonable job of
> wrapping that sort of functionality into a "modern" (GUI) skin.

I don't see how that's good other than it looks cool to the casual observer.
You still have to type the byte values, but with a lot more keystrokes
and/or clickty-clicking around them.  Yucc.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\03\04@044520 by Alan B. Pearce

face picon face
>> I was going to use this utility to send the bytes to the PIC:
>> http://www.pololu.com/docs/0J23
>
>What a cute little app!  Thanks for bringing it to my attention!

Me too - I think I will have a use for this in the very near future.

I do like some of the hardware products they have. For a lot of hobbyists
the battery holders with built-in boost regulators for 3.3V & 5V would be a
boon.

2009\03\05@084326 by bathini

picon face

Hello

I think I can make it work with this >> http://www.semifluid.com/?p=11
however the code is in JAL. Anyone know how to convert JAL to assembly? I
will extend the H-bridge from the LED. What do you think?:-)

Bathini
--
View this message in context: www.nabble.com/RS232-to-PIC16F628-to-DC-Motor-tp22268503p22351862.html
Sent from the PIC - [PIC] mailing list archive at Nabble.com.

2009\03\05@121446 by Byron Jeff

flavicon
face
part 1 1405 bytes content-type:text/plain; charset=unknown-8bit (decoded quoted-printable)

On Thu, Mar 05, 2009 at 08:43:22AM -0500, bathini wrote:
> > Hello > > I think I can make it work with this >> http://www.semifluid.com/?p=11
> however the code is in JAL. Anyone know how to convert JAL to assembly?
Usually done by running the JAL compiler. From the JAL FAQ

Is JAL compatible with …

The JAL output is an assembler file and a hex file. The hex file is in
standard Microchip format and should be acceptable to almost any PIC
programmer. The assembler file is compatible with the Microchip assemblers
(I test it with the command line version) so you should be able to assemble
and use it with whatever Microchip compatible tool you want. It is not
possible to use the output of another tool (assembly, object, hex) as input
to the JAL compiler. For the SX targets the hex and assembler files contain
the configuration information at 0x1010 which seems to be the Scenix
standard. Macro's are provided for the SX extensions (page, bank etc.) so
you can still assemble with the Microchip tools.

http://www.voti.nl/jal/faq.html

BAJ

> I will extend the H-bridge from the LED. What do you think?:-)
> > Bathini
> -- > View this message in context: www.nabble.com/RS232-to-PIC16F628-to-DC-Motor-tp22268503p22351862.html
> Sent from the PIC - [PIC] mailing list archive at Nabble.com.
> > --!

2009\03\05@125054 by Harry H. Arends

flavicon
face
Look here for more info http://jal.sourceforge.net/

Harry
{Quote hidden}

> -

2009\03\05@143435 by Tamas Rudnai

face picon face
On Tue, Mar 3, 2009 at 11:24 PM, Olin Lathrop <RemoveMEolin_piclistEraseMEspamspam_OUTembedinc.com>wrote:

> William Chops" Westfield" wrote:
> > The pololu app looks to do quite a reasonable job of
> > wrapping that sort of functionality into a "modern" (GUI) skin.
>
> I don't see how that's good other than it looks cool to the casual
> observer.
> You still have to type the byte values, but with a lot more keystrokes
> and/or clickty-clicking around them.  Yucc.


I agree with you Olin. Even the oldest serial communication software I was
using knows much more than this - like Procomm Plus... It was featured with
scriptic language so that you could write nice apps that was able to
communicate with devices interactively - like waiting for a specific text
and answer with a computed value, timeouts and loads of things I cannot even
remember for.

This small app only sends some bytes that is good only for testing if the
PIC receives the bytes correctly - but for that I use Hyperterm or Brays or
Putty or cat file > /dev/TTYS0 ...

Tamas
--
Rudonix DoubleSaver
http://www.rudonix.com

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...