Yet another "I want to use the Genesis serial port"
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
That's my assumption too. I guess it's just the 3 pins then?
I suppose I can just 'cat' the output of the device in linux and code something up to try writing to the port, see if anything comes back.
I suppose I can just 'cat' the output of the device in linux and code something up to try writing to the port, see if anything comes back.
my album - last thursday died last week
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Apologies to all on this Thread. I have been really ill with a fever, cold and something not fit for public consumption
I shall jump onto my machine tonight and put together some information for any MD Developer looking to do things with the MD's Serial Ports.
Apologies but at least I have only been ill once this year.
Cheers,
Minty.
I shall jump onto my machine tonight and put together some information for any MD Developer looking to do things with the MD's Serial Ports.
Apologies but at least I have only been ill once this year.
Cheers,
Minty.
UMDK Fanboy
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
I have some issues with Ubuntu on my Laptop once again - seriosuly, Ubuntu is gescrewed as hell and I will pick a more stable and decent Distro that does not SPY on us.
Anyway...
I have written some basic guide but it is still very rough and I need to upload it to my GitHub.
PowerOfRecall and any one else who wants to read the PDF send me a PM for now giving me some way to send a PDF file to you, cheers.
The Routines that do the work are part of AXLIB that I have not gotten to the stage of being happy to release but you can see it here first
I thought that I'd put some of the code here:
Anyway...
I have written some basic guide but it is still very rough and I need to upload it to my GitHub.
PowerOfRecall and any one else who wants to read the PDF send me a PM for now giving me some way to send a PDF file to you, cheers.
The Routines that do the work are part of AXLIB that I have not gotten to the stage of being happy to release but you can see it here first
I thought that I'd put some of the code here:
Code: Select all
;###################################################################
;# Name: mdrs232_tx_demo.asm
;# Author: MintyTheCat.
;# Purpose: Very simple Demo used as part of the 'Quick-Guide to MD RS232'.
;# Date-First: 13/10/2014.
;# Date-Last: 13/10/2014.
;# Notes: TS=8.
;# Project-File-Version=0.01.
;# Changes:
;# Initial Version.
;#
;# 13/10/2014.
;#
;###################################################################
; * All your other system initialisation code/etc. here *
even
; [Constants]
SerialMessage: dc.B "Hello from MD.",0
even
MDRS232_TxDemo:
; Port 3 Serial Init:
move.B #$B0,axl_md_io_port3_ser_sctrl ; Baud=1200, TR:serin, TL:serout.
;
; (*) I am going to do this in the most simple way one could imagine so do not expect anything 'efficient' code wise for any of you still in High-School who have issues (*)
; [MD RS232 Quick-Guide Demo Code: Start]
;MD232GuideTxSerialMessage
lea SerialMessage,a1
; Tx 'H':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'e':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'l':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'l':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'o':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx ' ':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'f':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'r':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'o':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'm':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx ' ':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'M':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx 'D':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; Tx '.':
move.B (a1)+,d0
jsr AXL_IO_Port3_Serial_TxChar
; [MD RS232 Quick-Guide Demo Code: End]
;##########################################################
;# Routine Name: AXL_IO_Port3_Serial_TxChar.
;# Synopsis: None.
;# Module: None.
;# Routine-Type: None.
;# Input-Regs: None.
;# Output-Regs: None.
;# Regs used: d0: Character to Transmit.
;# d1: Not-Used.
;# d2: Not-Used.
;# d3: Not-Used.
;# d4: Not-Used.
;# d5: Not-Used.
;# d6: Not-Used.
;# d7: Number of Characters Transmitted.
;# a0: Not-Used.
;# a1: Not-Used.
;# a2: Not-Used.
;# a3: Not-Used.
;# a4: Not-Used.
;# a5: String to Transmit.
;# a6: Not-Used.
;# Description: None.
;# Cautions: None.
;# Notes: None.
;# Comments: None.
;##########################################################
even
AXL_IO_Port3_Serial_TxChar:
AXL_IO_Port3_Serial_TxChar_Init:
movem.L d1-d6/a0-a4/a6,-(sp) ; Save the Regs.
AXL_IO_Port3_Serial_TxChar_Exec:
AXL_IO_Port3_Serial_TxChar_NotReady:
move.B axl_md_io_port3_ser_sctrl,d1
btst #1,d1
bne AXL_IO_Port3_Serial_TxChar_NotReady
move.B d0,axl_md_io_port3_ser_tx
; (*) handling of 'Add to Characters Transmitted count' in the TxString Routine:
AXL_IO_Port3_Serial_TxChar_Exit:
movem.L (sp)+,d1-d6/a0-a4/a6 ; Restore the Regs.
rts
;##########################################################
;# Routine Name: AXL_IO_Port3_Serial_RxChar.
;# Synopsis: None.
;# Module: None.
;# Routine-Type: None.
;# Input-Regs: None.
;# Output-Regs: None.
;# Regs used: d0: Character received.
;# d1: Not-Used.
;# d2: Not-Used.
;# d3: Not-Used.
;# d4: Not-Used.
;# d5: Not-Used.
;# d6: Number of Characters received.
;# d7: Not-Used.
;# a0: Not-Used.
;# a1: Not-Used.
;# a2: Not-Used.
;# a3: Not-Used.
;# a4: Not-Used.
;# a5: Not-Used.
;# a6: Received Character.
;# Description: None.
;# Cautions: None.
;# Notes: None.
;# Comments: None.
;##########################################################
even
AXL_IO_Port3_Serial_RxChar:
AXL_IO_Port3_Serial_RxChar_Init:
movem.L d1-d5/d7/a0-a5,-(sp) ; Save the Regs.
AXL_IO_Port3_Serial_RxChar_Exec:
AXL_IO_Port3_Serial_RxChar_RxRdyWait:
move.B axl_md_io_port3_ser_sctrl,d1
btst #1,d1
beq AXL_IO_Port3_Serial_RxChar_RxRdyWait
bra AXL_IO_Port3_Serial_RxChar_GotData
AXL_IO_Port3_Serial_RxChar_NotRRDY:
move.W #$8703,vdp_control_port
bra AXL_IO_Port3_Serial_RxChar_Exit
AXL_IO_Port3_Serial_RxChar_RdDError:
move.W #$8704,vdp_control_port
bra AXL_IO_Port3_Serial_RxChar_RdDError
AXL_IO_Port3_Serial_RxChar_GotData:
move.B axl_md_io_port3_ser_rx,d0
; (*) handling of 'Add to the Characters received count' in the RxString Routine:
AXL_IO_Port3_Serial_RxChar_Exit:
movem.L (sp)+,d1-d5/d7/a0-a5 ; Restore the Regs.
rts
;##########################################################
;# Routine Name: AXL_IO_Port3_Serial_TxString.
;# Synopsis: None.
;# Module: None.
;# Routine-Type: None.
;# Input-Regs: None.
;# Output-Regs: None.
;# Regs used: d0: Character to Transmit.
;# d1: Not-Used.
;# d2: Not-Used.
;# d3: Not-Used.
;# d4: Not-Used.
;# d5: Not-Used.
;# d6: Not-Used.
;# d7: Number of Characters Transmitted.
;# a0: Not-Used.
;# a1: Not-Used.
;# a2: Not-Used.
;# a3: Not-Used.
;# a4: Not-Used.
;# a5: String to Transmit.
;# a6: Not-Used.
;# Description: None.
;# Cautions: None.
;# Notes: None.
;# Comments: None.
;##########################################################
even
AXL_IO_Port3_Serial_TxString:
AXL_IO_Port3_Serial_TxString_Init:
movem.L d0-d7/a0-a4/a6,-(sp) ; Save the Regs.
move.L #$0,d7 ; Clear the count of Characters transmitted.
move.L #6000,d4
AXL_IO_Port3_Serial_TxString_DUMMYWAIT:
nop
dbf d4,AXL_IO_Port3_Serial_TxString_DUMMYWAIT
AXL_IO_Port3_Serial_TxString_TxLoop:
move.L #$00000000,d0
move.B (a5)+,d0
cmp.B #0,d0
beq AXL_IO_Port3_Serial_TxString_Exit
jsr AXL_IO_Port3_Serial_TxChar
addi.B #1,d7 ; Increment the count of Characters transmitted.
bra AXL_IO_Port3_Serial_TxString_TxLoop
AXL_IO_Port3_Serial_TxString_Exit:
movem.L (sp)+,d0-d7/a0-a4/a6 ; Restore the Regs.
rts
;##########################################################
;# Routine Name: AXL_IO_Port3_Serial_RxString.
;# Synopsis: None.
;# Module: None.
;# Routine-Type: None.
;# Input-Regs: None.
;# Output-Regs: None.
;# Regs used: d0: Character received.
;# d1: Not-Used.
;# d2: Not-Used.
;# d3: Not-Used.
;# d4: Not-Used.
;# d5: Not-Used.
;# d6: Number of Characters received.
;# d7: Not-Used.
;# a0: Not-Used.
;# a1: Not-Used.
;# a2: Not-Used.
;# a3: Not-Used.
;# a4: Not-Used.
;# a5: Not-Used.
;# a6: Received String.
;# Description: None.
;# Cautions: None.
;# Notes: None.
;# Comments: None.
;##########################################################
even
AXL_IO_Port3_Serial_RxString:
AXL_IO_Port3_Serial_RxString_Init:
movem.L d1-d5/d7/a0-a5,-(sp) ; Save the Regs.
move.L #$0,d6 ; Clear the count of Characters received.
AXL_IO_Port3_Serial_RxString_Exec:
AXL_IO_Port3_Serial_RxString_RxLoop:
jsr AXL_IO_Port3_Serial_RxChar ; Get a Character.
move.B d0,(a6)+
addi.B #$1,d6 ; Increment the count of Characters received.
cmp.B #0,d0
beq AXL_IO_Port3_Serial_RxString_Exit
cmp.B #$0D,d0
beq AXL_IO_Port3_Serial_RxString_Exit
bra AXL_IO_Port3_Serial_RxString_RxLoop
AXL_IO_Port3_Serial_RxString_Exit:
move.B #$0A,d0
jsr AXL_IO_Port3_Serial_TxChar ; Transmit a Linefeed.
movem.L (sp)+,d1-d5/d7/a0-a5 ; Restore the Regs.
rts
Last edited by MintyTheCat on Tue Oct 14, 2014 11:41 pm, edited 1 time in total.
UMDK Fanboy
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
No, that in itself will not work. I had some issues 'getting' the MD to receive correctly that I managed to solve through hooking my logic-analyser, disassembling the MD Modem ROM and scratching my head for a while - I ended watching an entire Bolt-Thrower concert in the process of working it out so be warnedpowerofrecall wrote:That's my assumption too. I guess it's just the 3 pins then?
I suppose I can just 'cat' the output of the device in linux and code something up to try writing to the port, see if anything comes back.
Also, I know that my code starts with a baud of 1200 but use the lowest at first and if you have decent tools then use them.
Please try out my AXLIB code as given below. AXLIB is not ready for release as yet but will in time be an Open-Source Library for MD devevelopers.
UMDK Fanboy
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
I sent you a PM with details. I'll give your code a try and see if it works out for me.
my album - last thursday died last week
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
No worries - I am happy that someone else wants to bring RS232 on the MD to the masses as it is for many their only way to send data to and from the MD and their PC and as such can be a real advantage when developing for the MD.powerofrecall wrote:I sent you a PM with details. I'll give your code a try and see if it works out for me.
UMDK Fanboy
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
I'm not getting any output. I'm assuming there is no way I have wired this wrong. Should RX be wired to TX and vice versa? I'm not using your exact code Minty but my code duplicates it and running it through the MESS debugger, it looks "proper."
For my serial in and out functions, I need to be waiting for RRDY bit to go low before reading a byte, and RRDY to go high before writing a byte, yes?
I'm using a FTDI usb serial adapter with TTL level, I have TX, RX and GND connected. It appears as a normal serial (/dev/ttyUSB0) in linux and I'm assuming functions like one.
I'm using cutecom as my terminal, are there any particular serial settings I need other than Baud = 1200?
My C code looks something like this:
The initialization looks like this:
For my serial in and out functions, I need to be waiting for RRDY bit to go low before reading a byte, and RRDY to go high before writing a byte, yes?
I'm using a FTDI usb serial adapter with TTL level, I have TX, RX and GND connected. It appears as a normal serial (/dev/ttyUSB0) in linux and I'm assuming functions like one.
I'm using cutecom as my terminal, are there any particular serial settings I need other than Baud = 1200?
My C code looks something like this:
Code: Select all
#define PORT3_SCTRL 0xA1001F
#define PORT3_TX 0xA1001B
#define PORT3_RX 0xA1001D
uint8_t _inbyte(void) {
volatile uint8_t *pb;
uint8_t byte;
/* wait for RRDY low */
while(*pb & 0x02) pb = (volatile uint8_t *) PORT3_SCTRL;
pb = (volatile uint8_t *) PORT3_RX;
byte = *pb;
return byte;
}
void _outbyte(uint8_t c) {
volatile uint8_t *pb;
uint8_t byte;
byte = c;
/* wait for RRDY high */
while(!(*pb & 0x02)) pb = (volatile uint8_t *) PORT3_SCTRL;
pb = (volatile uint8_t *) PORT3_TX;
*pb = byte;
}
Code: Select all
void serial_init(void) {
volatile uint8_t *pb;
pb = (volatile uint8_t *) PORT3_SCTRL;
/* S-CTRL is for the status, etc. of each port's mode change, baud rate and SERIAL.
7 6 5 4 3 2 1 0
S-CTRL BPS1 BPS0 SIN SOUT RINT RERR RRDY TFUL */
*pb = 0xB0; /* 1200bps serial in/out enable */
}
my album - last thursday died last week
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Yes, that is correct from memory. I may well put down the steps as Psuedocode to ensure that we are all on the right page.powerofrecall wrote:I'm not getting any output. I'm assuming there is no way I have wired this wrong. Should RX be wired to TX and vice versa? I'm not using your exact code Minty but my code duplicates it and running it through the MESS debugger, it looks "proper."
For my serial in and out functions, I need to be waiting for RRDY bit to go low before reading a byte, and RRDY to go high before writing a byte, yes?
Just a silly question: the connections and directions are from the perspective of the PC.
One option here to try out Tx from the MD which is Rx ONLY for the PC is to wire up ONLY the connections for the PC_Rx and see how that goes.
The MD_Tx is a lot more forgiving than to attempt MD_Rx first so try that first of all please.
Yes, I use an FTDI device but I also have the MAX232 connected to that so that only the MAX232 is connected directly to the MD.powerofrecall wrote: I'm using a FTDI usb serial adapter with TTL level, I have TX, RX and GND connected. It appears as a normal serial (/dev/ttyUSB0) in linux and I'm assuming functions like one.
I'm using cutecom as my terminal, are there any particular serial settings I need other than Baud = 1200?
Silly question: you have tried out your /dev/ttyUSB0 with another DevBoard or something that has an RS232 Port and it worked right?
I have not used cutecom I actually used Putty but I sampled the output from the transmission using my Logic-Analyser to see what was going on the lines too.
I could try that on Linux and see if I hit any issues for comparison but will have to do it tomorrow.
Can you confirm your RS232 Terminal Settings please?
8,1 stop?
Ok, what's the scope of the volatile uint8_t *pb ? What about if you have it as a global then pass it in to the serial_init.powerofrecall wrote: My C code looks something like this:
The initialization looks like this:Code: Select all
#define PORT3_SCTRL 0xA1001F #define PORT3_TX 0xA1001B #define PORT3_RX 0xA1001D uint8_t _inbyte(void) { volatile uint8_t *pb; uint8_t byte; /* wait for RRDY low */ while(*pb & 0x02) pb = (volatile uint8_t *) PORT3_SCTRL; pb = (volatile uint8_t *) PORT3_RX; byte = *pb; return byte; } void _outbyte(uint8_t c) { volatile uint8_t *pb; uint8_t byte; byte = c; /* wait for RRDY high */ while(!(*pb & 0x02)) pb = (volatile uint8_t *) PORT3_SCTRL; pb = (volatile uint8_t *) PORT3_TX; *pb = byte; }
Code: Select all
void serial_init(void) { volatile uint8_t *pb; pb = (volatile uint8_t *) PORT3_SCTRL; /* S-CTRL is for the status, etc. of each port's mode change, baud rate and SERIAL. 7 6 5 4 3 2 1 0 S-CTRL BPS1 BPS0 SIN SOUT RINT RERR RRDY TFUL */ *pb = 0xB0; /* 1200bps serial in/out enable */ }
void
serial_init(volatile uint8_t *pb)
Just a check as I cannot determine the variables scope from your code snippet.
Also, using an Emulator can you determine what the value of the SCTRL Register is after you have set it and also does your program essentially sit in the Super-Loop after you have executed all your Init code or does it simply fall through?
Your Code:
Code: Select all
void _outbyte(uint8_t c) {
volatile uint8_t *pb;
uint8_t byte;
byte = c;
/* wait for RRDY high */
while(!(*pb & 0x02)) pb = (volatile uint8_t *) PORT3_SCTRL;
pb = (volatile uint8_t *) PORT3_TX;
*pb = byte;
}
Code: Select all
void _outbyte(uint8_t c) {
volatile uint8_t *pb;
uint8_t byte;
pb = (volatile uint8_t *) PORT3_SCTRL; //<-------------Init Port before checking its Status.
byte = c;
/* wait for RRDY high */
while(!(*pb & 0x02)) pb = (volatile uint8_t *) PORT3_SCTRL;
//Do you ever get to this point here?
pb = (volatile uint8_t *) PORT3_TX;
*pb = byte;
}
Update:
Sorry! I have forgotten to state and omitted that in my little Demo but the Port3-Control Port also needs to be configured for directions - let me get back to you on that as I need to boot my main machine but nothing will work without the CTRL being set - sorry!
For now set everything to Output and DO NOT try to transmit anything from the PC to the MD so disconnect the MD_Rx pin for now.
#define PORT3_SCTRL 0xA1000D
volatile uint8_t * gpb_p3ctrl=NULL;
gpb_p3ctrl = (volatile uint8_t *) PORT3_CTRL; //(!) call this in your init Function but make sure it is some kind of global or ensure that the scope is within the init and usage and never changes once initialised.
*gpb_p3ctrl =0x7F; //That will get you: Port 3: TH-Int:OFF, PC6..PC0: OUTPUT.
Sorry! That should now get you MD_Tx working
Cheers,
Minty.
Last edited by MintyTheCat on Wed Oct 15, 2014 8:27 pm, edited 2 times in total.
UMDK Fanboy
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
Those volatile pointers are just local temporaries to hold the #define'd addresses, to cut down on casting & make sure that the compiled code doesn't try to use word or long addressing when dealing with the port. It's a style thing I picked up from SGDK and it's a little easier to read than just referencing the raw addresses, too.
I actually had the line init'ing pb before testing it but in a moment of me thinking I was being smart or something, took it out. My line of thinking was something like making sure that the value was being read for every check (during the while loop) would help make sure that the compiler didn't optimize that read out. Which is what volatile is supposed to do anyway, so I don't know what I was thinking.
You know, you say it's a silly question but I really don't know if the cable is even working. I'm assuming it is as my OS recognizes it, and the LED's flash a bit when you plug it in. I don't really have any other way to test it unfortunately.
My cable seems to be correct so I will look over some things and muddle with this some more. So far the only output I get in the terminal at all is a random NULL when switching the power off to the console, so I'm assuming the chip works and gets something from the transitional state of cutting power.
I actually had the line init'ing pb before testing it but in a moment of me thinking I was being smart or something, took it out. My line of thinking was something like making sure that the value was being read for every check (during the while loop) would help make sure that the compiler didn't optimize that read out. Which is what volatile is supposed to do anyway, so I don't know what I was thinking.
You know, you say it's a silly question but I really don't know if the cable is even working. I'm assuming it is as my OS recognizes it, and the LED's flash a bit when you plug it in. I don't really have any other way to test it unfortunately.
My cable seems to be correct so I will look over some things and muddle with this some more. So far the only output I get in the terminal at all is a random NULL when switching the power off to the console, so I'm assuming the chip works and gets something from the transitional state of cutting power.
my album - last thursday died last week
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Actually, no - the OS has no idea what your Cable is set to. You could have a loopback - in fact try that first! From a loopback you will know if your Cable is good or not connections wise. From memory if is Pin 2 connected to Pin 3 on the PC side and that will get you loopback.powerofrecall wrote:Those volatile pointers are just local temporaries to hold the #define'd addresses, to cut down on casting & make sure that the compiled code doesn't try to use word or long addressing when dealing with the port. It's a style thing I picked up from SGDK and it's a little easier to read than just referencing the raw addresses, too.
I actually had the line init'ing pb before testing it but in a moment of me thinking I was being smart or something, took it out. My line of thinking was something like making sure that the value was being read for every check (during the while loop) would help make sure that the compiler didn't optimize that read out. Which is what volatile is supposed to do anyway, so I don't know what I was thinking.
You know, you say it's a silly question but I really don't know if the cable is even working. I'm assuming it is as my OS recognizes it, and the LED's flash a bit when you plug it in. I don't really have any other way to test it unfortunately.
My cable seems to be correct so I will look over some things and muddle with this some more. So far the only output I get in the terminal at all is a random NULL when switching the power off to the console, so I'm assuming the chip works and gets something from the transitional state of cutting power.
Well, when in doubt find out what the pre-processed Assembly is before it being compiled to see what decisions the Compiler is making and how it affects your code.
It is -S in GCC but not sure for your Compiler.
Yes, the explicit Casting is used and I would even advise you to use Constant-Pointers too so that once they are assigned to addresses you are not permitted to change what they point to.
UMDK Fanboy
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
On Exodus at least it appears that _outbyte just hangs waiting on that bit to change.
The assembly in the disassembler looks like
Other than the odd code choices (I have all optimizations off), this looks right to me.
The assembly in the disassembler looks like
Code: Select all
...
move.l #$A1001F,(a7)
.loop:
movea.l (a7),a0
moveq #0,d0
move.b (a0),d0
and.l #2,d0
beq.b .loop
...
my album - last thursday died last week
-
- Very interested
- Posts: 237
- Joined: Fri Apr 17, 2009 7:35 pm
- Location: USA
Forgive me for asking but what am I needing to do with it? I haven't done anything to initialize it other than write 0xB0 to it.MintyTheCat wrote:Hi,
I just added a bit to the post before: sorry, I had forgotten to tell you to set the Port 3's CTLR port - that specifies the Interrupt on Ext-Int and the Port's Directions.
Naughty me...
my album - last thursday died last week
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
Yes, that Assmbly looks right.powerofrecall wrote:On Exodus at least it appears that _outbyte just hangs waiting on that bit to change.
The assembly in the disassembler looks like
Other than the odd code choices (I have all optimizations off), this looks right to me.Code: Select all
... move.l #$A1001F,(a7) .loop: movea.l (a7),a0 moveq #0,d0 move.b (a0),d0 and.l #2,d0 beq.b .loop ...
Without having a serial device connected to Exodus t will carry on like that forever.
Last edited by MintyTheCat on Wed Oct 15, 2014 9:19 pm, edited 1 time in total.
UMDK Fanboy
-
- Very interested
- Posts: 484
- Joined: Sat Mar 05, 2011 11:11 pm
- Location: Berlin, Germany
No, no you write 0xB0 to the SCTRL port for port 3.powerofrecall wrote:Forgive me for asking but what am I needing to do with it? I haven't done anything to initialize it other than write 0xB0 to it.MintyTheCat wrote:Hi,
I just added a bit to the post before: sorry, I had forgotten to tell you to set the Port 3's CTLR port - that specifies the Interrupt on Ext-Int and the Port's Directions.
Naughty me...
You write 0x7F to CTRL port for port 3.
First one sets the baud for port set as RS232 port.
Second sets Ext-Interrupt and pin directions: either input or output direction relative to MD port.
Make sense?
UMDK Fanboy