VP 2 UARTs + I2C possible, again.
CCraig
Posts: 163
OK, I need more help. Those unfamiliar with my project.
review: A GPS module piggybacked on Bean's SD data logger. (operates as a stand alone if need be). That unit (GPS/logger) and another (Keyboard/LCD) talk to a main unit SX28. Moving to SX48 or Prop? That's the question by the way.
Problem: In the main unit, I'm running dual VP UARTs. Well, one UART and one SIO. Works fine, thank-you JonnyMac! Now, I'm really going to need a Math Fpu. I don't know if I have the resources to add that inside the ISR. I think my ISR is running fast, so I think I can call it less often to give me more time, but...
Questions:
1. How do you calculate how much time you have left in the ISR. Do you look at the listing and count instructions? I tried SXSim and couldn't get close. I know I read something, but can't find it now.
2. 2 UARTs + 1 I2C master in the ISR is that possible? Even if I want to add another SX to offload some work, I'd have to come up with another VP UART for a total of 3 UARTs at 9600 baud.
3. Am I heading towards a brick wall at 90 miles per hour? (So I guess I'll be using the GPS for a 'X marks the spot' device.)(And does FTD deliver to GPS coordinates?)
4. Is it time to get out the PE kit and get to work? Where I probably don't need a math coprocessor.
I think I know the answer to #4. It seems like last month I was asking if it was possible to put two UARTs in the ISR, now I want more. I just need support and advise. I have it fixed in my mind that this project should use all SXs. Maybe this should be the project that forces me to learn the new platform.
Thanks In Advance, Chris
review: A GPS module piggybacked on Bean's SD data logger. (operates as a stand alone if need be). That unit (GPS/logger) and another (Keyboard/LCD) talk to a main unit SX28. Moving to SX48 or Prop? That's the question by the way.
Problem: In the main unit, I'm running dual VP UARTs. Well, one UART and one SIO. Works fine, thank-you JonnyMac! Now, I'm really going to need a Math Fpu. I don't know if I have the resources to add that inside the ISR. I think my ISR is running fast, so I think I can call it less often to give me more time, but...
Questions:
1. How do you calculate how much time you have left in the ISR. Do you look at the listing and count instructions? I tried SXSim and couldn't get close. I know I read something, but can't find it now.
2. 2 UARTs + 1 I2C master in the ISR is that possible? Even if I want to add another SX to offload some work, I'd have to come up with another VP UART for a total of 3 UARTs at 9600 baud.
3. Am I heading towards a brick wall at 90 miles per hour? (So I guess I'll be using the GPS for a 'X marks the spot' device.)(And does FTD deliver to GPS coordinates?)
4. Is it time to get out the PE kit and get to work? Where I probably don't need a math coprocessor.
I think I know the answer to #4. It seems like last month I was asking if it was possible to put two UARTs in the ISR, now I want more. I just need support and advise. I have it fixed in my mind that this project should use all SXs. Maybe this should be the project that forces me to learn the new platform.
Thanks In Advance, Chris
Comments
· I had a similar problem with my video overlay module. I thought about using 2 SX chips, but in the end I went with the propeller. The SX is an amazing chip, but with 8 processors the propeller is much more capable when you need lots of thing happening at the same time.
P.S. I'm working on a Propeller Dongle development board. Just plug it into a USB port, no power supply or anything. If you interested it is in this thread http://forums.parallax.com/showthread.php?p=653637
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
“The United States is a nation of laws -· poorly written and randomly enforced.” - Frank Zappa
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
I know I'm facing the switch, sooner or later. You know, dreading learning the new platform, change on board supply to feed 3 volts also, interfacing 3 to 5 etc., etc.
Do you calc ISR times by looking at the SRC list and counting?
Thanks, Chris
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
“The United States is a nation of laws -· poorly written and randomly enforced.” - Frank Zappa
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
- Sparks
Yes, I need to pause the screen a fair amount. The LCD is fairly slow, and I need time to see it. I'm more concerned with how big the ISR can get. This app. is processing very slow data streams. The data out of the GPS is once a second, the display runs slow, I'm only logging data every ten seconds and power is no problem, so I'm running the SX fast. I think I can slow down my ISR calls and pack more into the ISR. I'm trying to figure out IF that is possible. I want to add I2C commands therefore it must go into the ISR. I think the limit on how slow will be on the I2C which I believe will have to run faster interrupts than the serial at 9600. Being new to this interrupt stuff, I'm finding it difficult to determine interrupt times needed and how long the interrupt needs to run or is running.
When I first ran some interrupts I had the period too short and got some really wierd results. Interrupting interrupts doesn't work.
Even if I have to change to the Prop. I have learned a lot from this project.
Thanks again, Chris
P.S. also, correct me if I'm wrong, running ISRs, I have to run I2C commands inside the ISR. Or can the clock on the I2C take that hit and keep on working.
Post Edited (CCraig) : 6/9/2007 6:41:07 PM GMT
I'm a bit baffled by some of your questions, but it's probably due to your approach..... using SX/B; and I'm NOT knocking that; it has its place.
In assembler with an RTOS scheduler these problems simply go away. You can have multiple serial UART routines running simultaneously, as well as LCD display drivers, and I2C all operating concurrently. Normally I have very little in the ISR; in fact almost nothing; just a tick counter or an interrupt event flag...... a whopping 3 instructions. The interrupt runs at a fairly fast rate, 1 or 2 uSec, and all application timings are driven from that.
I'm just putting the finishing touches on a co-operative RTOS that would be perfect for applications such as yours. It permits up to 8 active threads and there can be any number of dormant threads that can be launched by an active thread. Each thread can suspend itself or any other thread for any number of the 1 or 2 uSec ISR ticks, and then carry on where it left off, or alternately carry on at some other spot, thereby making state machines a snap.
The overhead of this RTOS is not too cumbersome... it takes about 1.5 uSec for a task switch, less than 50 instructions for the whole RTOS and 2 RAM bytes per active thread. A couple of macros assist in enrolling each thread into the 8 level stack, and suspending a thread while a pause is required, or an alternate thread is to run.
What is so nice about this kind of approach is that you can focus on one task at a time as there is very little timing interaction between active threads.
But, at this time at least, it only works for assembler...... some relatively minor (I believe) changes are required to SX/B to accommodate it.
If you are interested in this method, I'd be happy to share it with you.... there are very few (one in fact) warts left; it's been very nice and stable.
Cheers,
Peter (pjv)
Let me get this last gremlin sorted out, and then I'll get the NERF bat out and we'll have a go!
Cheers,
Peter (pjv)
I think you are confused because I am. I wasn't sure the I2C commands would work out side the ISR like the normal serial commands. I would love to use a RTOS and played a little with one that was posted some months back. I'm still not at ease with assembly, but I'm getting there (slowly).
Thanks again, Chris
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
“The United States is a nation of laws -· poorly written and randomly enforced.” - Frank Zappa
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·
The deal is.... EVERYTHING works outside the ISR; that's the beauty of it. The ISR is only used to create relatively fast accurate clock ticks, and then all applications are driven from multiples of those ticks. That permits every application to run at it's own speed, and be independent of the speed of others.
Quite simple really. I'll post the new RTOS as soon as it is ready. But remember; for now at least, it's assembler only!
Cheers,
Peter (pjv)
Well that last gremlin was a little bit of an SOB..... a case when two or more events dynamically ligned up to run at the exact same clock tick, one would get serviced and the other lost its clock reference for 256 ticks. Anyhow, its been running without any hiccup for half the day. At the end here I arbitrarily expanded the number of UARTs to 5 transmitting and one receiving, all independently and simultaneously at 9600 baud, including generation of their own transmit data set. Every transmitter was triggered repeatedly every 1.2 milliseconds, so there was a bag of data going out.
Then scoping the trivial task routine (essentially the looper that waits for the next task's time to come up), and there are BAGs of cycles left; I'd bet were only consuming 10% or 20% (not calculated just a peek from the scope) of the processor, including the OS!
This is gonna be great!
So I'm doing some polishing now and still will want to do some bullet proofing before I issue a general release. In a new post topic I imagine.
I'd appreciate getting a few guru's to beat up on this..... any takers? My guess is that at this point at least it's certainly not for beginners..... a good scope or logic analyzer will be a huge asset.
Also I still need to create some explanations/limits/rules.
Cheers,
Peter (pjv)
-- Jon
I'm am most certainly NOT a guru. But I do have a LogicPort, and this stuff usually beats up on me, but I have attitude.
Chris
Some more bullet proofing done now.
To check performance, I have 8 simultaneous threads running:
1 UART receiver at 9600
5 UART transmitters @ 9600, each firing a transmission every 1.2 milliseconds (200 uSec idle time between transmissions)
1 6.25 KHz continuous square wave generator
1 5.95 KHz continuous square wave generator
The RTOS scheduler alone consumes approximately 6% of the 50MHz processor cycles, and with all eight of these applications running as specified, it consumes 40%
So there is lots of room left for other applications.
Cheers,
Peter (pjv)
I think that a great barrier for me at the moment is that I do not know how to THINK that way!
When I started learning how to program I was taught how to think about each step required for a certain task and how to proceed through each one either sequentially or conditionally. Then I learned a little bit about how to use interrupts which was great because then I could program TWO things to be happening at the same time! The catch was that whatever was operating in the foreground had to not care too much about being interrupted by the task operating in the background.
After a while, though, it became clear that I could run more than two tasks using interrupts. This was fairly easy if the other ISR task(s) had the same timing or at least some common timing multiple.
So you see, from my perspective it has a lot to do with learning how to think about having multiple tasks running. I would like to agree with JonnyMac in thinking that I ought to be smart enough to think like that but may need some help in doing so.
Do you think you can help up learn to think in the proper way to handle multiple and, even more frightening, co-operative tasks or at least point us to some helpful resources?
I’d like to learn by I am not sure how to think like that yet!
- Sparks