Yet another "I want to use the Genesis serial port"

For hardware talk only (please avoid ROM dumper stuff)
User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Sun Oct 05, 2014 2:26 pm

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.

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Mon Oct 13, 2014 3:16 pm

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

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Tue Oct 14, 2014 12:08 am

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 :D

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

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Tue Oct 14, 2014 7:18 pm

powerofrecall 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.
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 warned :D

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

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Wed Oct 15, 2014 12:09 am

I sent you a PM with details. I'll give your code a try and see if it works out for me.

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Wed Oct 15, 2014 10:30 am

powerofrecall wrote:I sent you a PM with details. I'll give your code a try and see if it works out for me.
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.
UMDK Fanboy

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Wed Oct 15, 2014 6:16 pm

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:

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;
}
The initialization looks like this:

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 */
	
}

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Wed Oct 15, 2014 7:46 pm

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

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

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?
powerofrecall wrote: 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;
}
The initialization looks like this:

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 */
	
}
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.

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;
}
Does not init pb before you test it.

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;
}
If you still have issues them please email me your code and I will have a look and try to get it working for you.

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

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Wed Oct 15, 2014 8:15 pm

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.

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Wed Oct 15, 2014 8:20 pm

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

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Wed Oct 15, 2014 8:25 pm

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

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

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Wed Oct 15, 2014 8:27 pm

On Exodus at least it appears that _outbyte just hangs waiting on that bit to change.

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
    ...
Other than the odd code choices (I have all optimizations off), this looks right to me.

User avatar
powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Wed Oct 15, 2014 8:31 pm

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

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Wed Oct 15, 2014 9:12 pm

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

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
    ...
Other than the odd code choices (I have all optimizations off), this looks right to me.
Yes, that Assmbly looks right.

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

User avatar
MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Wed Oct 15, 2014 9:16 pm

powerofrecall wrote:
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...
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.
No, no you write 0xB0 to the SCTRL port for port 3.

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

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests