UARTsircs prog

Rsadeika

I am using Jon's program as a starting point for discussion. What I tried to do is add a second UART to the program; I basically added the same code that was used for the first UART, but changed some values like the TX and RX pins. Of course the program did not run as expected, but I was surprised that the sircs section of code worked as expected. So, that means that the interrupt was still in tact, from a timming perspective.

So, the problem is in how the UART code is implemented, any ideas as to what should be looked at first. It seemed to me that it should be as simple as changing the pin assignment, in the code to TX1, RX1, TX2, and RX2. Now the program goes through the code for UART1 and UART2, and it should work.

I looked at the Scenix DUAL UART code as a reference, but of course it's in asm, and it discussed some things like threading. Now I am not sure as to how you could achieve that using SX/B. I am already starting to run into variable space problems, and the code size is still very small, I am using an SX52 proto board. Any ideas or comments.

Thanks

Ray

JonnyMac

All you need to do is create a second serial array so that you have a new set of variables for the second UART. With the SX52, variable space is not the problem. You should probably have a second set of bit-timing divider constants so that each UART can run at its own rate.

Post Edited (JonnyMac) : 4/2/2007 2:17:24 PM GMT

Rsadeika

I am running into a problem that I can not figure out how solve. If you take the example code, UART_SIRCS.SXB, and just change the values so it will run on an SX52 proto board, it will not run correctly. The program runs correctly on an SX28 chip, but not on an SX52 chip. Now, after playing around with the code for a couple of days, I am getting the feeling that the way the varibles are set up, some of them are getting washed out. Which means the program will not run correctly, that is just my guess.

The only thing that I did was change the device to SX52, OSCXT2, BOR42 in the UART_SIRCS.SXB program. Anybody else having this problem, or do I have to do some other changes to the program to make it work on an SX52 chip. Any ideas or comments.

Thanks

Ray·

Rsadeika

Below is a short snippet of the code where I made the changes. In the variables area I now get a comiler error 3, variable exceed available ram. The cmdCode_MSB var Byte, is high lighted in yellow. I thought the SX52 had over 200 bytes of ram available, I do not think that I have over two hundred variables in the code.



'

---

' Device Settings
'

---

DEVICE········· SX52, OSCHS2, BOR42
FREQ··········· 50_000_000
ID············· "MyBot"


'

---

' IO Pins
'

---

RX············· PIN···· Rd.7 INPUT
TX············· PIN···· Rd.6 OUTPUT

IR············· PIN···· RB.0 INPUT


'

---

' Constants
'

---

' Dividers for ISR UART
' -- values set for 4.34 uS interrupt rate

Baud2400······· CON···· 96
Baud4800······· CON···· 48
Baud9600······· CON···· 24
Baud19K2······· CON···· 12
Baud38K4······· CON···· 6
Baud57K6······· CON···· 4

Baud1x0········ CON···· Baud57K6··············· ' 1 bit period (ISR counts)
Baud1x5········ CON···· Baud1x0 * 3 / 2········ ' 1.5 bit periods


Yes············ CON···· 1
No············· CON···· 0


'

---

' Variables
'

---

flags·········· VAR···· Byte
rxReady········ VAR···· flags.0················ ' serial byte avialable
rxCmd·········· VAR···· flags.1················ ' receiving IR command
rxBit·········· VAR···· flags.2················ ' measuring bit width?
hasKey········· VAR···· flags.3················ ' IR cmd code available

idx············ VAR···· Byte

tix············ VAR···· Word··················· ' (ISR) for DELAY_MS

'serial········· VAR···· Byte (16)·············· ' bank for serial vars
'txCount········ VAR···· serial(0)
'txDivide······· VAR···· serial(1)
'txLo··········· VAR···· serial(2)
'txHi··········· VAR···· serial(3)
'rxCount········ VAR···· serial(4)
'rxDivide······· VAR···· serial(5)
'rxByte········· VAR···· serial(6)
txCount· var Byte
txDivide· var Byte
txLO· var Byte
txHi· var Byte
rxCount var Byte
rxDivide var Byte
rxByte var Byte

'sircs·········· VAR···· Byte (16)·············· ' bank for SIRCS vars
'sircsTix······· VAR···· sircs(0)··············· ' ISR divider
'cmdWork_LSB···· VAR···· sircs(1)··············· ' work space for cmd
'cmdWork_MSB···· VAR···· sircs(2)
'bitCount······· VAR···· sircs(3)··············· ' track bits received
'bitWidth······· VAR···· sircs(4)··············· ' measure bit width
'cmdCode_LSB···· VAR···· sircs(5)··············· ' key code
'cmdCode_MSB···· VAR···· sircs(6)··············· ' device code
'keyCode········ VAR···· sircs(5)
'devCode········ VAR···· sircs(6)
sircsTix· var Byte
cmdWork_LSB· var Byte
cmdWork_MSB var Byte
bitCount var Byte
bitWidth var Byte
cmdCode_LSB var Byte
cmdCode_MSB var Byte
keyCode var Byte
devCode var Byte

tmpB1·········· VAR···· Byte··················· ' work vars
tmpW1·········· VAR···· Word

JonnyMac

The SX52 does have 262 bytes of SRAM, but it is banked (common practice in small micros) so you cannot use it as one contiguous block. In the original program I wrote the SIRCS stuff was in an array (which moves it out of the normal variable area) for a reason: to keep the normal variable area as free as possible.

The SX52 is different from the SX28 and the program may require some updates to make it work on the new platform, especially with manual memory management as is required when using the ISR stuff.

Rsadeika

Thanks,

The SXB compiler flatened out the programming space, but you still have to deal with variable space limitations. So if you have to deal with those limitations, then it sounds to me like you have to go back to the 'bank' method of programming. I think I am going backwards here. Does anybody know, in an SX52 chip, how much programming and variable space you get in a bank. Since it is different than an SX28, that would be good to know. Any other tidbits of info would come in handy for the SX52.

JonnyMac

Per the SX documentation (hint, hint...) banks are 16 bytes each, the SX52 has 16 of them plus the global space. The SX52's architecture allows SX/B to define arrays of greater than 16 bytes, and this may work to your advantage. Make an array and then alias the elements with your desired variable names. This will only work with bytes; SX/B does not support word arrays.

Sparks-R-Fun

Rsadeika,

In the Help file under Reference | Definitions | Variables you should find a table describing the variable space differences between the different SX versions.

I recommend that you define your UART variables in the following way:

' -------------------------------------------------------------------------
' Variables
' -------------------------------------------------------------------------
'This creates a bank to be used with serial
serial      var Byte (16)

tx1Count     var serial(0)
tx1Divide    var serial(1)
tx1Lo         var serial(2)
tx1Hi         var serial(3)
rx1Count     var serial(4)
rx1Divide     var serial(5)
rx1Byte        var serial(6)

tx2Count     var serial(7)
tx2Divide    var serial(8)
tx2Lo         var serial(9)
tx2Hi         var serial(10)
rx2Count     var serial(11)
rx2Divide     var serial(12)
rx2Byte        var serial(13)
' -----------------------

Then change your variable references in each subroutine accordingly. What this should do is provide each UART with its own set of independent variables that are all in the same 16-byte array (or BANK).

I have not tested this but hopefully it will start you in the right direction.

- Sparks

Rsadeika

The building of the arrays is not the problem. When I construct the array, the program compiles correctly, but when the program is run, the thing does not run correctly. I dug out Jon's original SIRCS program to play with, this is a non isr version. It has a subroutine called GET_SIRCS, and two key variables, cmdCode, and devCode. As soon as I put those two variables into an array, and insert the 'bank xxxx', the program does not work as expected. As I take the two variables out of the array, then it works properly. The compiler never shows an error or gives any warning as to potential other problem. I am starting to wonder if this may be a compiler problem.

Sparks-R-Fun

Rsadeika,

Many SX/B commands will work fine with array variables. A few (notably an index into an array) will not.

You do not need to put every variable into an array. Since the UART variables were initially part of an array, they should be happy in an array. Why change them? And if the SIRCS variables do not work as part of an array, why try to change them?

If you followed my previous recommendation, the UART should have 12 variables as part of the Serial VAR BYTE(16) array. (It is ok to think of this as a bank. The BANK Serial statement ensures the proper bank is selected for that subroutine section.) If that is how you have those variables defined, then I count 11 other general-purpose bytes being used by the MyBot.sxb program. It does not appear to me that you should be experiencing a variable space problem yet.

Perhaps I do not understand what you are trying to accomplish.

- Sparks

Rsadeika

I guess I have to restate the problem. I took Jon's program, which is for an sx28, and changed the 'device' to work for an sx52, the program does not work. I did not change any 'bank' arrays, I just ran it straight up. That is the problem. I was trying to narrow down the problem to see if I could determine why it was not running correctly. As an experiment,·with a smaller amount of code to deal with, I ran into the possible problem with the 'bank' array. So, as of right now, if I try to use the 'bank' method with my SX52, the program, any program,·does not run correctly.

Sparks-R-Fun

Ahhh...

You changed nothing but the device line and now it seems the program is not working? Bummer.

It looks like I will not be of much help. All I can offer is generic advice to check and test all of your connections and to make sure you are using SX/B version 1.51.03 and not another version.

Sorry.

- Sparks

Rsadeika

Just to clarify the hardware aspect, the hardware does not change, only some values in the program change. I already went through that debacle, checking for a hardware problem, its been narrowed down to a software problem. The biggest problem could be that, using SX/B, on the·SX52, I am limited to 16 bytes of variable space. I cannot think of any other easy way of getting around that, at this moment. I could fall back to 'paging', but that would be going backwards, and I want to use SX/B as a quick prototyping tool. Asm·would just take to much time, to evaluate, and verify some simple concepts.·I had high hopes, again, for the SX52.

Sparks-R-Fun

Rsadeika,

I do not think the UART_SIRCS.SXB program is running out of variable space. I count three general-purpose byte variables and two word variables. So seven general-purpose variable locations are being used. You should have several left by any count!

Likewise utilizing only two sixteen-byte arrays should leave plenty of room for more on any SX version.

I regret that I can not tell you what is wrong... but I do not think it is a lack of variable space.

- Sparks

Sparks-R-Fun

Rsadeika,

I have been trying to understand how to best utilize memory and variable space myself. So here is what I have concluded based upon what others are saying.

That is this. The key to this problem will likely be found in the understanding of where your variables reside in relation to the SX memory and how to access them properly when using assembly language subroutines. All of the mental gymnastics involving in tracking memory locations and banks is conveniently handled when using pure SX/B code. Jumping to assembly sometimes requires this to be known and sometimes not.


Here is what I did to try to coax the program you supplied into working properly.

1.) I made the changes I recommended previously creating independent variables for each UART and placed them together into a 16 byte array, a.k.a. a bank. This bank is selected by the UART code with "BANK Serial" commands that were already in place.

2.) I added a "BANK tix" command at the start of your SIRCS subroutine to select the memory bank holding the tix variable (and hopefully all of the other SIRCS variables as well) and a "BANK 0" at the end to place the bank selection back to 0. My hope was that all of the SIRCS variables would conveniently happen to reside within the same bank. Unfortunately, they did not as evidenced by "File register not in current bank" compiler errors.

This is where the whole trick to getting everything to work together comes into play. You need to understand where your variables are when you access then in assembly. (I am so glad SX/B takes care of this automatically!)

If you want to see what I am talking about, download the attached program but move the variable assignments for tmpB1 and tmpW1 back to their previous location, which was right after the SIRCS variable definitions and just before the interrupt statement. Then examine the compiler listing (CTRL-L) of the modified program. You should see the following: (NOTE: Any other program will likely produce a different output.)

   161  =0000000F       tix           EQU  0x0F          ;tix  var word
   162  =0000000F       tix_LSB       EQU  tix          
   163  =00000010       tix_MSB       EQU  tix+1        

You can see that when arranged as I just described tix begins at address $0F, the last address of Bank 0. (The Most Significant Byte (MSB) of tix actually resides one address higher at the start of the next bank!) The rest of the SIRCS variables also reside in the next bank, which is not quite so convenient for quick and easy access.

3.) What I did to provide a "quick fix" for this ("fixing" was not really required as there are ways to deal with variables in different banks) was to move the variable assignments for tmpB1 and tmpW1 so that they occurred earlier in the program listing. That way when variable space is being assigned, all the SIRCS variables happen to fall into the same memory bank! That makes things more convenient, a key element to keeping things simple when using assembly subroutines.

4.) I moved the bit flags for the UARTS to a byte within the same array as Step 1.

5.) Since there are now two UARTS I created duplicated subroutines to access them. This is probably not the most compact way to access them but it was a "quick fix."

I do not know if the modified program I have supplied actually works. I hope you will let us know.


- Sparks

Rsadeika

Thanks for the time and effort Sparks, but it is a no go. There was no activity with sircs or the serial. This is getting to be tough nut to crack. When I looked at your code arrangement of the variables, it looks like it should work, but it did not. In the help file it says that the SX52 has 17 bytes for general variables, the code uses less, so where is the program going wrong.

Thanks again

Sparks-R-Fun

Rsadeika,

I discovered that you altered the SIRCS interrupt routine from the original posting when you included it in your MyBot.bas program. I was not previously aware of that. It may make a difference. Are you sure your version of it is working fine? It can be very difficult to fix something that has been subject to multiple changes.

At any rate, I am posting an altered version of your program using the original SIRCS subroutine and a slight modification to how you examine the key code. If this should happen to work in some way, so much the better. Otherwise further clarification may be needed if you desire additional help.

- Sparks

Rsadeika

Sparks,

I started from scratch, putting together two UARTS, and I have a program that runs DUAL UARTS. I just got through testing it to make sure it works in real time, and not·just in theory. What I wanted to do is make sure I got some code that works, now I will play around with the SIRCS to see if I can get that code inserted, and working. I am happy that I got the DUAL UART to work, at least if the SIRCS does not pan out, I can still use the board in some different manner. Your examples helped me alot. More to come ...

Ray

Rsadeika

I have included a working DUAL UART program. I tried my best to get the sircs to work, but was unable to do so. One way to resolve the problem, I think, is to increase the amount of variables from 17 to maybe 48, or some number along those lines. For the SX52, there seems to be something weird going on when you start to implement 'bank' arrays. In all fairness, the code does implement the serial 'bank' array, and the DUAL UART works. It is when you add the sircs code that the problem shows up.

It was mentioned that there might be some problem with the sircs asm code, so the code listing below reflects the use of non asm sircs code. I just wanted to see if it really was the sircs asm code that was the problem. This code does not work either. So, the conclusion is, on an SX52 chip, if you mix uart with some sircs code neither one works. I do not have enough variable space to try a non serial 'bank' situation.

I am also looking for a UART asm program thats works on an SX52 chip. I tried the example in Gunther's book, but could not get that to work. The example in the download area does not work either. I have not tried the Al Williams example just yet, but I think that will not work either. I have run his UART example on an SX28, and it worked.

Thanks Sparks and Jon for the help.

Ray

Sparks-R-Fun

Ray,

Have you considered the run rate differences between the UART and SIRCS ISRs? The UART code specifies an interrupt run rate of 4.34 uS. The SIRCS ISR code from Jon Williams specifies a run rate of 26 uS.

If you have not already considered this you may want to adjust the run rate of the SIRCS code. (26 uS) / (4.34 uS) = 5.99. So you should call the SIRCS code once for every six times the ISR is processed.

Maybe this will help.

- Sparks

Rsadeika

Thanks Sparks,

There is delay in the interrupt to slow it down to the proper speed.

Ray