MC9S12DP256 D-Bug12 SCI with NSC200 motorcontroller

[rdelljh]

I am trying to initiate communication between a NSC200 (motorcontroller) and a MC9S12DP256 (HC12 microcontroller) using D-Bug12 4.0.0b29 in EVB mode.
The NSC200 manual states that I need to use CTS/RTS hardware handshake protocol. Do I need to accomadate that in my code?
Below I describe what works and what does not.

Connection 1
Description:
HC12 SCI0 --> Desktop (AsmIDE) 9600 8-N-1
HC12 SCI1 --> Laptop (Hyperterminal) 19200 8-N-1

Purpose: Verify HC12 has correct settings and is sending and receiving data from SCI1

Using the following code

Code:

#include /* derivative information */#include "pll.h" /* defines _BUSCLOCK, sets bus frequency to _BUSCLOCK MHz */#include "sci0.h" /* support for SCI0 */#include "sci1.h" /* support for SCI1 */void main(void) {char myString0[32];/* set system clock frequency to _BUSCLOCK MHz (24 or 4) */PLL_Init();/* initialise serial communication interface SCI0 */SCI0_Init(BAUD_9600);/* initialise serial communication interface SCI1 */SCI1_Init(BAUD_19200);SCI1_OutString("Enter string\n\r");SCI1_InString(myString0, 10);SCI0_OutString("\n\rYou have entered: ");SCI0_OutString(myString0);SCI0_OutString("\n\r\n\r");}

 

Hyperterminal screen:

Enter string
Hello desktop

AsmIDE screen:
You have entered: Hello desktop

Conclusion: Communication settings are correct. C code and serial commands are correct.
**********************************************************************************************

CONNECTION 1
Description: Same
Purpose: Send a motorcontrol command to Hyperterminal

using the following command
SCI1_OutString("1TE?\r");

Hyperterminal screen:
1TE?

Conclusion: It appears that the motorcontrol command is being sent correctly.
**********************************************************************************************
CONNECTION 2
Description:
Laptop (Hyperterminal) 19200 8-N-1 --> NSC200 19200 8-N-1
Purpose:

Send known motorcontrol command to NSC200 and verify output.

using echo and hitting after the command
Hyperterminal:
1VE? 3.5 NSC200
1TE? 0
1OR

1OR sends the motor unit to the "home" position

Conclusion:
Motor works. Commands work. Commucation settings are correct.
**********************************************************************************************

CONNECTION 3 (Trial 1)
Description:
HC12 SCI0 --> Desktop (AsmIDE) 9600 8-N-1
HC12 ScI1 --> NSC200 19200 8-N-1

Using the following code

Code:

#include /* derivative information */#include "pll.h" /* defines _BUSCLOCK, sets bus frequency to _BUSCLOCK MHz */#include "sci0.h" /* support for SCI0 */#include "sci1.h" /* support for SCI1 */void main(void) {char myString0[32];/* set system clock frequency to _BUSCLOCK MHz (24 or 4) */PLL_Init();/* initialise serial communication interface SCI0 */SCI0_Init(BAUD_9600);/* initialise serial communication interface SCI1 */SCI1_Init(BAUD_19200);SCI1_OutString("1OR\r");SCI1_OutString("1VE—\r");SCI1_InString(myString0, 10);SCI0_OutString("\n\rYou have entered: ");SCI0_OutString(myString0);SCI0_OutString("\n\r\n\r");}

 

Only on rare occasions of resetting and unplugging the board and controller will the motor actually move, but it has never sent data back to the board.
One more question what do the RX and TX LED's correspond to?

Here is the relevent code from sci1.c

Code:

// filename *************** sci1.c ******************************// Simple I/O routines to 9S12C32 serial port// Jonathan W. Valvano 1/29/04// Copyright 2004 by Jonathan W. Valvano, valvano@mail.utexas.edu// You may use, edit, run or distribute this file// as long as the above copyright notice remains// Modified by EE345L students Charlie Gough && Matt Hawk// Modified by EE345M students Agustinus Darmawan + Mingjie Qiu//// adapted to the Dragon12 board using SCI1 -- fw-07-04// allows for 24 MHz bus (PLL) and 4 MHz bus (no PLL) -- fw-07-04#include /* derivative information */#include "sci1.h"#include "pll.h" /* macro _SYSCLOCK */#define RDRF 0x20 // Receive Data Register Full Bit#define TDRE 0x80 // Transmit Data Register Empty Bit//-------------------------SCI1_Init------------------------// Initialize Serial port SCI1// Input: baudRate is tha baud rate in bits/secvoid SCI1_Init(unsigned short baudRate) {SCI1BDH=0;SCI1BDL=78;SCI1CR1 = 0;SCI1CR2 = 0x0C;}//-------------------------SCI1_InChar------------------------// Wait for new serial port input, busy-waiting synchronization// Output: ASCII code for key typedchar SCI1_InChar(void) {while((SCI1SR1 & RDRF) == 0){};return(SCI1DRL);}//-------------------------SCI1_OutChar------------------------// Wait for buffer to be empty, output 8-bit to serial port// busy-waiting synchronization// Input: 8-bit data to be transferredvoid SCI1_OutChar(char data) {while((SCI1SR1 & TDRE) == 0){};SCI1DRL = data;}

 
Alban shaped code for lisibility & re-use

Message Edited by Alban on 06-06-2006 01:02 PM

[imajeff]

In response to rdelljh's question,
> One more question what do the RX and TX LED's correspond to?

Good question. It helps me to know that the RX and TX LEDs are indicating the logic level on the actual serial lines. That means that even if your MCU RX is not set up properly, you will still see flicker on RX when serial bytes should be received. That tells you when you should expect the MCU to receive the bytes. Likewise if you send bytes but do not see flicker on TX, you know the MCU is not sending the bytes, at least not on that TX line.

[rocco]

Hi, rdelljh:

I believe what you are asking really has to do with the NSC200, and it comes down to your intended hardware. Here is what I know:

The NSC200 is an RS485 device. It does not speak RS232, like a typical PC's comm port speaks. So Newport provides an RS232->RS485 converter for those who wish to hook the NSC200 up to a PC.

Since RS485 is typically half-duplex, you need some mechanism to tell the converter when to enable it's transmitter, and when to enable it's receiver. Most RS232->RS485 adapters use RTS/CTS for this. Hence, hyperterminal must be doing this for you when you are talking to the NSC200 from the PC.

Now the question becomes, how do you really want to talk to the NSC200?

If you are using pre-existing hardware, like an EVM board, that already contains an RS232 port, you should use the adapter and assert RTS when you need to transmit. Basically, you will do in firmware what hyperterminal is doing.

If you are building hardware for this job, I would suggest that you fore-go the adapter and drive the RS485 directly. Your firmware will still need to assert a bit in order to transmit, but all of the RS232 hardware, which might include +/-12 volt power supplies as well, can go away. Electrically, RS485 is much simpler to implement than RS232.

I hope that was really what you were asking.

[rdelljh]

That's answers part of my question.
For now lets assume I am using an adapter and the RS232 port.
What bit do I assert to RTS?

[imajeff]

I'm trying to understand your situation, and I think you are saying basically "how do I implement hardware flow control on my board containing MC9S12DP256 so that it can control the NSC200 motor controller", right?

I still don't see what the board is containing the MC9S12DP256. You should know that the SCI port does not include any hardware flow control. That means that if the board does not already dedicate specific MCU i/o as RTS/CTS, then you will have to choose your own from the available GPIO. Then you would need to wire them into the correct lines on the RS232 connection. Who knows, maybe you need some more level-converting circuitry also, they need to be RS232 compatible.

[rdelljh]

I'm using a Wytec Dragon 12 Development Board that has a MC9S12DP256.
It has 2 RS232 ports and a RS485.
I have an adapter that converts my NSC200 controller from RS485 to RS232. I thought this would be easier to test code output using another computer/monitor. I have not used the I2C before. Either way it seems I need to implement some flow control. Can I do that using software? How?

[imajeff]

Good, I have Dragon12 (rev D here with me). I'm sorry I don't know RS485 well, and I don't know details how your adapter converts to RS232. I am guessing I could help more if you used RS485 (SCI1) on the Dragon12, and debug through the other serial (SCI0). Basically the Dragon12 would be the converter, from RS485 to the TTL NRZ 8-N-1 format which has been erroneously called "RS-232 format". I think RS485 is at least as simple as RS232 with only two nodes.

My Dragon12 schematic shows in middle of sheet 3 how J22 is connecting to PJ0 to allow control RS485 direction.

P.S. In fact you will see that there are no RS232 level converters for driving the RTS/CTS lines. That is more reason to use the Dragon12's RS485 port.

Also are you the same person on yahoo group 68HC12 who was setting WAKE and ILT bits in SCICR1? I'm just wondering if you could say why you are setting those. Does the NSC200 send an "address mark" at a certain point? Maybe it's RS485 protocol? I've wanted to learn RS485, just never needed to.

Message Edited by imajeff on 06-02-2006 02:07 PM

[rocco]

Hi, rdelljh:

Imajeff has posted everything you need to know. To summarize, and basically update my previous post with current information:

You cannot use an RS232->RS485 adapter, because the Dragon doesn't give you the modem-control lines that are necessary to control it.

You can communicate directly with the motor controller with the Dragon's RS485 port, using the procedure that I outlined above, but asserting and de-asserting PJ0 in those places where I called out RTS.

Hi, Imajeff:

I can describe RS485 in a few sentences. It is not really a protocol, but simply an electrical interface spec, like RS232.

It is usually half-duplex, using two twisted-pair wires, but can also be full-duplex, using two sets of twisted-pair wires. It is multi-drop, and your software has to insure that only one node tries to transmit at any point in time. The two wires are driven differentially: when one is high, the other is low. The cable typically has a characteristic impedance of around 120 ohms, and is terminated with a 120 ohm resistor at each end. It can work over very long runs, up to 4000 feet, and can support baud rates into the mega-bauds. The transceivers requires only 5 volts. Like RS232, you need to define the software protocol, including baud-rate, number of data bits, stop bits, parity and the like.

Message Edited by rocco on 06-02-2006 02:38 PM

[rdelljh]

Thanks a lot guys.
I didnt post on yahoo.
However, I did post a question on here concerning the freescale stationery for I2C and the dragon 12 board.

[rocco]

Hi, rdelljh:

Unless Wytec has this spelled out in their documentation, you will need the schematics of your Dragon board. You would need to verify:
1) That the RS232->RS485 adapter really uses RTS to enable the RS485 transmitter. (It is likely, but not guaranteed).
2) Whether or not Wytec has an RS232-level driver on the RTS line (or whatever line the RS232->RS485 adapter uses).
3) What pin on the microcontroller Wytec has hooked RTS (or whatever) up to.

Then the algorithm for sending is simple:
1) Assert RTS just prior to sending your message to the motor controller.
2) Send each byte on the message.
3) Wait for transmission-complete from the last byte.
4) De-assert RTS.

Hope that helps.

[imajeff]

I didn't think that D-Bug12 used any hardware handshaking. The D-Bug12 4.x.x Reference Guide says it doesn't.