|
Yep. Your right. I remember that as soon as I read your post. I approached that entire post in general terms based on standards used in any project design, any programming language. If one is conditioning logic as Yes/No, On/Off, or True/False then the variable should be Boolean. .db. -----Original Message----- From: Neil Jepsen [mailto:] Sent: Wednesday, February 04, 2004 12:30 PM To: Subject: Re: [BasicX] BX24 and Pic-Servo (JRKerr) Dan Bielecki wrote: > Change the variable COMMOPEN to be Boolean typed. > Use the keywords True & False. Booleans are 1-bit. Bytes are 8-Bits. Dan My understanding is that each boolian uses 8 bits (unfortunately) unless things have chenged recently neil j <http://rd.yahoo.com/SIGclhvstb/M$3273.4510124.5685162.1261774/D=egroup web/S06554205:HM/EXP76009443/A50744/R=0/*http://servedby.advertisin g.com/click/siteU2006/bnum75923043995142> Click to learn more... <http://us.adserver.yahoo.com/l?M$3273.4510124.5685162.1261774/D=egroupmai l/S=:HM/A50744/randd6478724 _____ > . |
BX24 and Pic-Servo (JRKerr)
Started by ●February 3, 2004
Reply by ●February 4, 20042004-02-04
Reply by ●February 4, 20042004-02-04
|
"Booleans are 8 bit, not 1 bit." Yes, I know, Neil reminded me of that. Now when you guys get around to optimizing the compiler, then a Boolean can be a true Boolean and not a byte under the covers. One byte can hold eight Booleans and if the compiler is instructed correctly, it can use all eight as intended. Mapped to the address in memory and then offset N-Number of bits based on order of definement. The compiler hit is if only one Boolean is defined in a program. The benefit is when the second and third one is defined...ect. *** The Rational: The numerics are fixed length variables. Their length is known. The string of fixed length, the same thing. Known lengths. The other strings are not and flex in size. Map them last so they dont overrun into other memory spaces. *** The Broken Record Delay Zero: There is only one Atmel. There is the BX OS running. Task 1. There is the developer's logic running. Task 2 We've been thru this... Trapdoor, System Functionality, you asking what me what your doing in code....me saying I dont have source....only use the thing. Based on my personal experience with your platform, no-op do loops are a thing to avoid. The Delay call serves or triggers some internal function to smooth out execution-jitter of the instruction-set as it flows thru the Atmel, thereby causing a BX to seize during runtime. We dont all overflow our program stacks or overwrite memory spaces in every program all the users write. I dont know exactly what instruction sets are performed under that Call, but there's something that is done, that is needed, in any task. Personally? Without seeing any source, I think it has to do with the odd timing skips one sees in the RTC, right around the time the Seconds roll into the Minutes. There's this little hiccup, right there in the timing. Between 0-second and 1-second, and then again between 1-second and 2-seconds. After that, the remaining 58-seconds are in time. But in that short span between 0 and 2...there's something there. Its like they are not full seconds and have to play a rounding game internally or something to derive at 0, 1, and 2. It messes with the flow of the instruction-set to Atmel. The Zero Delay smoothes that. Maybe its overrun of the instruction-set itself on its way into core, or a skip in SPI fetching. The delay just smoothes things out, and the loop is not a no-op, a "do" instruction-set and the "loop" instruction-set back-to-back on its way into Atmel. .db. -----Original Message----- From: Frank Manning [mailto:] Sent: Wednesday, February 04, 2004 12:47 PM To: Subject: Re: [BasicX] BX24 and Pic-Servo (JRKerr) From: Dan Bielecki <> > [...] > Change the variable COMMOPEN to be Boolean typed. > Use the keywords True & False. Booleans are > 1-bit. Bytes are 8-Bits. [...] Booleans are 8 bit, not 1 bit. > Define the larger numeric data types first, then > work down in size. From Unsigns, to Longs, ..., > down to Booleans. Define Strings last, fixed > strings first, with the auto-sizing ones the > very last types defined. I don't understand the rationale for this. The program won't run faster, nor will you save any memory by ordering variables like this. > [...] > > Simplify that Do Loop like so: > > DO UNTIL STATUSQUEUE(PicCom3In) > CALL DELAY(0.00) > LOOP > > [...] Forgive me for sounding like a broken record, but why is the zero delay there? A zero delay will slow down the loop by approximately 70 microseconds per cycle. Is there some benefit to be gained that offsets the slower execution time? Do you see fewer data overruns, or is there some other beneficial effect? The system will process the queues with or without the delay statement. As far as I can see, a zero delay is useless unless you have another task running in parallel. For those of you just tuning in, the main purpose of a zero delay is to encourage other tasks to run in a multitasking program. If you have only one task, which is the case here, a zero delay serves no purpose. -- Frank Manning -- NetMedia, Inc. _____ > . |
|
|
Reply by ●February 5, 20042004-02-05
|
--- In , "Dan Bielecki" <Dan.Bielecki@A...> wrote: > ... The other strings are not [of fixed length] and flex in size. > Map them last so they don't overrun into other memory spaces. My understanding is that the so-called variable length strings actually use a fixed amount of space per string (controlled by the "Maximum String Lengh (characters)" setting on the Project Options tab of the Environment dialog. (No, I didn't mis-type Lengh - that's what it says in the dialog. Oops!) The actual amount of space consumed by a string is 2 bytes plus the maximum string length. I suspect that the string functions check the maximum string size and prevent overrunning the allotted space. If you have the maximum string size set to 64, every string you use eats up 66 bytes. Yikes! This is one reason that I avoided using strings in my indexer project that I posted about earlier. If you looked at my page on the project, however, you saw that there are many "strings" displayed on the LCD. Instead of gobbling up RAM, they reside in EEPROM. My menu compiler also builds a string table in a text file which is used by the Source method of the ByteVectorData class. The downside of this approach is that I can't use any of the built in string functions. It's a small price to pay, I think, for all of the RAM that it saves. |
Reply by ●February 5, 20042004-02-05
|
From: Don Kinzer <> > Dan Bielecki <Dan.Bielecki@A...> >> ... The other strings are not [of fixed length] >> and flex in size. Map them last so they don't >> overrun into other memory spaces. If they overrun, the first thing they overrun is the main task frame, which is 15 bytes. After that, they overrun the main stack. Uncontrolled writes to either of those blocks can potentially crash a program. So I doubt that it's worth the trouble. I think it's more productive to prevent overruns in the first place. > My understanding is that the so-called variable > length strings actually use a fixed amount of > space per string (controlled by the "Maximum > String Lengh (characters)" setting on the Project > Options tab of the Environment dialog. True. One alternative is to use bounded strings, which allow you to tailor individual string sizes, rather than depend on a single parameter that applies to an entire program. > (No, I didn't mis-type Lengh - that's what it says > in the dialog. Oops!) Oops is right. Thanks for letting us know about that -- please let us know of any other misspellings you find. > The actual amount of space consumed by a string is > 2 bytes plus the maximum string length. > > I suspect that the string functions check the maximum > string size and prevent overrunning the allotted space. > [...] This is true for fixed-length strings. Unfortunately, for arrays and variable-length strings, there is no checking, which is similar to C in this regard. -- Frank Manning -- NetMedia, Inc. |
|
|
Reply by ●February 5, 20042004-02-05
|
Thank you Frank, I'll try the boolean test you suggest. I had to battle the original code in that BasicX won't test a boolean against a string. Don Lewis --- In , "Frank Manning" <fmanning@n...> wrote: > From: Don Lewis <djlewis@a...> > > > Frank Manning <fmanning@n...> wrote: > > > >> I notice you're using a lot of strings. Possibly a > >> stack overflow is occurring, especially if the > >> default string length is 64 characters. > > > > Is there a better choice for storing the data? > > Ram Pokes? > > Not necessarily. There's nothing wrong with strings themselves -- > you just need to be careful of string sizes, which can easily get > out of hand. > > >> Another thing that looks a little suspicious is this > >> line: > >> > >> IF (CBool(stat) AND CBool(2) ) THEN > > > > Hmmm, this is my hack for doing a Boolean test. THe > > original was from a program named PSTEST.bas a QBasic > > program that JRKerr had available on thier site. I > > have included it below. > > This is good -- it's helpful to have existing code that works. I > assume this is the original line: > > > IF (stat AND 2) THEN 'check status byte [...] > > If you avoid QBasic's implicit type conversions, the code really > does this: > > IF ((stat AND 2) <> 0) THEN > > I suspect the real intent is to check whether bit 1 is set. > Another alternative might make the intent clearer: > > IF ((stat AND bx0000_0010) = bx0000_0010) THEN > > -- Frank Manning > -- NetMedia, Inc. |
Reply by ●February 5, 20042004-02-05
|
My latest: Tuesday night I found I was getting false data when I thought I had made progress. Turns out one should preset variables and strings to null when there is an unkown input. After doing this I found I was not actually reading anything from the GetQueue call. After running Don Kinzer's Ramalizer I managed to cut Ram down from 360 bytes to 240 bytes in my main and PicInit modules. Then more tweaking and I began to get from four to 6 bytes of something, just not what was expected. I am still working on trying to get expected data with the GetQueue. Many thanks to all of you, Dan, Don, Francisco, Frank, Niel for all your input on this thread. I am copying and pasting it so I can take it home for reference as I continue to pound away on this. On the subject of undefined strings, My understanding was that by not declareing their size, auto sizeing would trim them to a dynamic size. My PicInString should not exceed 16 actual bytes. most times it should return two to three bytes. So is it just the queues that have this 9byte overhead? Am I not seeing users define their in / out strings to match the in/out queues size? Thanks, I am getting an education here on how this wonderful product works, Don Lewis --- In , "Frank Manning" <fmanning@n...> wrote: > From: Don Kinzer <dkinzer@e...> > > > Dan Bielecki <Dan.Bielecki@A...> > > >> ... The other strings are not [of fixed length] > >> and flex in size. Map them last so they don't > >> overrun into other memory spaces. > > If they overrun, the first thing they overrun is the main task > frame, which is 15 bytes. After that, they overrun the main stack. > Uncontrolled writes to either of those blocks can potentially > crash a program. > > So I doubt that it's worth the trouble. I think it's more > productive to prevent overruns in the first place. > > > My understanding is that the so-called variable > > length strings actually use a fixed amount of > > space per string (controlled by the "Maximum > > String Lengh (characters)" setting on the Project > > Options tab of the Environment dialog. > > True. One alternative is to use bounded strings, which allow you > to tailor individual string sizes, rather than depend on a single > parameter that applies to an entire program. > > > (No, I didn't mis-type Lengh - that's what it says > > in the dialog. Oops!) > > Oops is right. Thanks for letting us know about that -- please let > us know of any other misspellings you find. > > > The actual amount of space consumed by a string is > > 2 bytes plus the maximum string length. > > > > I suspect that the string functions check the maximum > > string size and prevent overrunning the allotted space. > > [...] > > This is true for fixed-length strings. > > Unfortunately, for arrays and variable-length strings, there is no > checking, which is similar to C in this regard. > > -- Frank Manning > -- NetMedia, Inc. |
|
|
Reply by ●February 5, 20042004-02-05
|
From: Dan Bielecki <> > [...] > Based on my personal experience with your platform, > no-op do loops are a thing to avoid. The Delay > call serves or triggers some internal function to > smooth out execution-jitter of the instruction-set > as it flows thru the Atmel, thereby causing a BX > to seize during runtime. [...] You have some example code that demonstrates this? If a processor seizes, it seems to me that should be easy enough to verify. > Personally? Without seeing any source, I think it > has to do with the odd timing skips one sees in > the RTC, right around the time the Seconds roll > into the Minutes. There's this little hiccup, > right there in the timing. Between 0-second and > 1-second, and then again between 1-second and > 2-seconds. After that, the remaining 58-seconds > are in time. [...] Again, you have some example code that demonstrates this? -- Frank Manning -- NetMedia, Inc. |
|
|
Reply by ●February 5, 20042004-02-05
|
--- In , "Dan Bielecki" <Dan.Bielecki@A...> wrote: > The Broken Record Delay Zero: > > There is only one Atmel. > There is the BX OS running. Task 1. > There is the developer's logic running. Task 2 Why do you think there is BX OS task? I don't know how it's built but an OS task seems very unlikely to me. I would expect the "OS" to be a number of interupt routines. One triggered by the timer that runs 512 times a second to update the RTC and to see if there are any other task to swap in. Then interupts from the COM1 UART when the TX buffer is empty or the RX buffer is full. Other timer interupts for the COM3 bitbanging. That means that all "background" stuff takes care of itself using interupts. I have done lots of IO on both COM1 and COM3 and used buffers both for external and internal communication. I have never used a sleep or delay 0.0 and have never experienced any unexpected behaviour of the BX chip except for my own errors. Rgds Ingvar |
|
|
Reply by ●February 5, 20042004-02-05
|
> ... Why do you think there is BX OS task? Dan, you're on stage again. Where's the beef? Tom Tom Becker --... ...-- www.RighTime.com The RighTime Clock Company, Inc., Cape Coral, Florida USA +1239 540 5700 |
|
|
Reply by ●February 5, 20042004-02-05
|
Because MAIN( ) is a subroutine. ....and subroutines have a caller. .db. -----Original Message----- From: Tom Becker [mailto:] Sent: Thursday, February 05, 2004 3:20 PM To: Subject: RE: [BasicX] Re: BX24 and Pic-Servo (JRKerr) > ... Why do you think there is BX OS task? Dan, you're on stage again. Where's the beef? Tom Tom Becker --... ...-- www.RighTime.com The RighTime Clock Company, Inc., Cape Coral, Florida USA +1239 540 5700 <http://rd.yahoo.com/SIGc8mgfo6/M&8585.4464812.5643763.1261774/D=egroup web/S06554205:HM/EXP76106003/A50448/R=0/*http://ashnin.com/clk/mury utaitakenattogyo?YHD64812&yhad50448> click here <http://us.adserver.yahoo.com/l?M&8585.4464812.5643763.1261774/D=egroupweb /S=:HM/A50448/randD9235811 _____ > . |
|
|
