A BYTE array question

idbruce

Hello All

Here is my question.· Actually 2 questions.

Can the number of elements in a byte array be set dynamically or is the number of elements·always a constant?

If it is possible, what is the proper way to accomplish this, and get the count of elements?

Bruce

idbruce

Let me be a little more specific.

Assuming·the number of elements can be dynamically changed, let's also assume that the value of this dynamic change is unknown, but must be acquired.

Mike G

Sure, allocate enough memory for the largest amount of data. Take a look at the Propeller manual DAT section.

Your code should count the items placed in memory.

Post Edited (Mike G) : 7/14/2010 12:53:06 PM GMT

Mike Green

The number of elements in an array is set at compile time (always a constant) and is not dynamic. The number of elements is not recorded anywhere, so you can't get it at run time although, since the number of elements is set by a constant expression, you can refer to the same constant expression elsewhere in your program by defining a named constant (CON section) and using that name later.

That said, you don't have to use the whole array and you can have a variable somewhere that contains a count of the number of items you're keeping in the array. Sometimes array[noparse][[/noparse] 0 ] is used to hold that while the data elements themselves start at array[noparse][[/noparse] 1 ].

In my programs, I'll typically have a constant "tableSize" for an array called "table" and declare things like this:

CON tableSize = 25

VAR byte table[noparse][[/noparse] tableSize ]

That way, I can use "tableSize" in my REPEAT statements.

Post Edited (Mike Green) : 7/14/2010 2:17:12 PM GMT

idbruce

Mike

Thanks for the reply.· Going back to my C++ programming days with TCHAR[noparse]/noparse, I remember that the number of elements was a constant.· I figured SPIN was the same, but I thought I would ask anyway.··My proposed solution is similar to what you suggest.· In my case, the number of elements will always be less than 8.· So something along the lines of:

VAR
  Byte table[noparse][[/noparse]8]  
  Byte nTableElements
PUB main
  nTableElements := 0
 
  'If an element is added to "table" then nTableElements++

Here is the real deal.· I am writing an Eagle (PCB layout software) drill file (*drd) parser for a CNC PCB drilling machine that I am building.· Most of it is complete except for parsing the coordinate lines of the file, eg:

X14401Y1901
X22151Y5151
X25151Y5151
X26151Y4401

I am thinking that the best alternative is to declare·x and y variables and parse each line from x till y and store the data in between (converted·into a whole number) as a long, and then parse the remainder from y until "Carriage Return" and store it similarly.



Can you offer any suggestions on accomplishing this task?



Thanks once again for your previous reply, and thanks in advance to any further advice or comments you may provide.



Bruce

Mike Green

I think it will be simplest to have an X word array and a Y word array and store the numeric values for each pair. There are plenty of examples of routines to parse numeric values. ExtendedFullDuplexSerial has one example. In your case, you want to skip input until your program sees an "X", then convert the digits that follow into a number (and store it in the X array). The non-digit character that terminates the number will have to be a "Y" and you'll convert the digits that follow into a number to be stored into the Y array. The non-digit character that terminates the Y value will have to be a Carriage Return. At that point, you increment the X/Y index you're using and process the next line. I don't know what you're using to indicate the end of the coordinate list, but you'd find that instead of an "X" eventually and you can stop at that point.

Note that I'm assuming that X and Y values will fit in a word (0-65535). If not or if you need signed numbers, you'll need to change things.

Phil Pilgrim (PhiPi)

One way to expedite your parsing would be to use my regular expression object: http://forums.parallax.com/showthread.php?p=855253.

For your case, the regex would be "X($1\d+)Y($2\d+)" for each line in the file.

-Phil

idbruce

Mike

Thanks once again.· I will have to take a look at that example.· X and Y are both temporary variables.· When I reach a coordinate line, parsing is paused and·the machine moves to the acquired coordinates and drills the hole returning a task completed result, parsing·then continues·until the next set of coordinates is found.· So on and so forth until·fileline = "M30" (End of file, no more coordinates).

Your assumtion is correct, word assignment should be adequate for Eagle *drd files, dependent upon the math used for machine movement.· However, Eagle only allows for a certain size board, and my machine will do much larger boards, so I must provide a solution for·values larger than 65535 for homemade *drd files.

Thanks so much Mike, I will take a good look at that example.

Bruce

idbruce

Phil

Yes, I have had my eye on that object for sometime.· Now you are taking me back to my Perl programming days.· I loved parsing with regular expressions.· A very powerful tool indeed.· I just have not taken the time to examine it closely, but rest assured, I will be using that object in the future.· Perhaps·for this project.·

And you even spelled it out for me "X($1\d+)Y($2\d+)"· [noparse]:)[/noparse]

Now that's·some cool cryptography!· Eliminates all the necessary ciphering and deciphering.

I am tempted.· Thanks Phil

T Chap

You are going to have to account for the decimals in the XY Eagle output, parsing the individual bytes of each XY "string" and not using numbers. If X = a string instead of a number, then you can parse out the decimal and convert it to whole number that represents distance in pulses. In other words, lose the decimal and have a whole number represent the number of pulses required for the X move. Say that you set Eagle to always export 4 decimal points in the XY output, then you always know where the decimal is. An example, X from Eagle is 0.1000, and you have a 20 TPI screw and using 10 micro steps, 200 regular pulses per rev on the stepper, then one inch = 40000 pulses. Take the value to the right of the decimal and multiply it by 4 (1000*4) = 4000 pulses to move .1 inch. Then for the values to the left of the decimal, multiply those by 40000, sum the result of the total on the left of the parsed decimal to the result on the right. This will provide the total steps to move. The result is a long, so there will be no limit to be concerned about for board size, and no messing around with floating points.

Another example:

X = 1.1000

Parse the left of the decimal: 1
Parse the right of the decimal: 1000

1*40000 = 40000 steps = 1 inch of travel with 20TPI lead screw.
1000*4 = 4000 steps = .1 inch of travel

Total: 44000 steps, or 1.1 inches of travel.

Store 44000 as a long, using a long array.

Post Edited (T Chap) : 7/14/2010 4:43:07 PM GMT

idbruce

T Chap

That was very interesting!· I have not reached the part of stepper control conversion yet, but I soon will and your input will prove helpful, especially since my steppers have a 1.8 degree step angle and my leadscrews have 20 TPI.· But I am not going to be microstepping, they will either run full or half step.· With full step, I should be at .00025 resolution and with half I should be at .000125.· I figure that should be close enough, provided I get control of the upcoming·backlash.

However my coordinate lines only contain·alpha-numeric characters with·no decimal point.··There must be some type of software setting within Eagle to provide the decimal point, but I·haven't it yet.· Either way, between Mike's, Phil's, and your input, I am certain this machine will be running soon.

Bruce

hover1

Bruce,

RS-274 data does not contain decimal points. The structure is defined in the Format Statement at the beginning of the file. I have not looked at an Eagle Gerber file, but they should conform to the standards. The attached example shows %FSLAX24Y24*%.

FS-Format statement
LA-Leading zeros omitted, Absolute Coordinates
X24-00.0000
Y24-00.0000

You will have to read the format statement and decide how to parse the data, adding the decimal point in the appropriate place.

Jim


A couple of good reads:

http://www.artwork.com/gerber/274x/rs274x.htm

http://en.wikipedia.org/wiki/Gerber_File

idbruce said...
T Chap


That was very interesting! I have not reached the part of stepper control conversion yet, but I soon will and your input will prove helpful, especially since my steppers have a 1.8 degree step angle and my leadscrews have 20 TPI. But I am not going to be microstepping, they will either run full or half step. With full step, I should be at .00025 resolution and with half I should be at .000125. I figure that should be close enough, provided I get control of the upcoming backlash.



However my coordinate lines only contain alpha-numeric characters with no decimal point. There must be some type of software setting within Eagle to provide the decimal point, but I haven't it yet. Either way, between Mike's, Phil's, and your input, I am certain this machine will be running soon.



Bruce

Post Edited (hover1) : 7/14/2010 6:46:20 PM GMT

T Chap

There are a number of ways to get out drill coords from Eagle, here is one simple ULP that will allow you to export the XY for drills, you can then just grab the actual info of value and save it to a text file by itself. I used this when I was drilling boards from Eagle. It uses 3 decimal points, and would require you to parse as described. Maybe there are better ways, but at least this is workable. I am not sure if this ULP works on the newest eagle version.

idbruce

T Chap

It is always nice to have options.· If that ULP does not work with the latest version of Eagle, then I will have to alter it, for possible future use.· However, I am very close to having my parser work the way I want it.· I was looking at another parser from pcb2gcode, which parsed the drill file and determined the decimal location programmatically.· I might include something similar.· Are you still drilling circuit boards?· Your previous post used past tense.

Thanks for the ULP file.

Bruce

T Chap

No, I made boards for protos for a while a few years ago, now just use Sunstone.

idbruce

T Chap

Well thanks for all your input.· I sincerely appreciate it.

Bruce

idbruce

Mike

I know you are busy looking at and answering questions, but if you are still listening, thank you for your guidance.· It appears that two of the functions within ExtendedFullDuplexSerial will prove useful to me.· Thank you so much for your input and guidance.

Bruce

idbruce

Phil

Don't worry, I will put your object to use ·· I know what it can do.· Thankfully someone ("you in this case"), took the time to write such a valuable tool.

Bruce

idbruce

Hey Mike

I did not say it at the time, but during my review of some old stuff, this was a pretty good tip. Thanks.

The number of elements in an array is set at compile time (always a constant) and is not dynamic. The number of elements is not recorded anywhere, so you can't get it at run time although, since the number of elements is set by a constant expression, you can refer to the same constant expression elsewhere in your program by defining a named constant (CON section) and using that name later.

That said, you don't have to use the whole array and you can have a variable somewhere that contains a count of the number of items you're keeping in the array. Sometimes array[ 0 ] is used to hold that while the data elements themselves start at array[ 1 ].

In my programs, I'll typically have a constant "tableSize" for an array called "table" and declare things like this: Code:

CON tableSize = 25VAR byte table[ tableSize ]


That way, I can use "tableSize" in my REPEAT statements.

ksltd

The question makes no sense.

The SPIN language (and C, for that matter) does not support arrays. In fact, there's no support for any data types at all.

Declarations may specify a size multiplier and references may include an offset computation; both use the [] operator to accomplish this.

Once one gets one's head around that subtle distinction, the rest follows pretty quickly.

idbruce

ksltd

You sound like a real smart feller.

The question makes no sense.
The SPIN language (and C, for that matter) does not support arrays. In fact, there's no support for any data types at all.
Declarations may specify a size multiplier and references may include an offset computation; both use the [] operator to accomplish this.
Once one gets one's head around that subtle distinction, the rest follows pretty quickly.

Look up "array" in the dictionary.

Look up "array index indicators" in the Propeller manual.

Do a search for C or C++ arrays on google.

Hint: Orderly arrangement.

Phil Pilgrim (PhiPi)

ksltd wrote:

The SPIN language (and C, for that matter) does not support arrays. In fact, there's no support for any data types at all.

I'm not sure what that statement means. Arrays are sometimes referred to as data types, but they're really data structures, in this case indexable lists of elements that can be of any single data type. In that sense, Spin does support arrays, and it computes the proper address offsets for indexing by byte, word, or long. What it does not do is bounds checking, so the support for arrays is rather thin in that regard. But bounds checking takes machine cycles for every array access, so there's a performance tradeoff that would probably be unacceptable for most Propeller apps.

-Phil

ksltd

SPIN and C are untyped.

The definition of array (you really mean vector) that you're attempting to use is a layman's definition, not very applicable to computer science. Case in point, your definition applies to any hunk of memory that's sequentially addressable. In other words, consider the following declarations:

dat
A byte 0, 0, 0
B byte 0 [3]
C byte 0
D byte 0
E byte 0

You'd claim that A, B and C are all identical arrays (vectors) of size 3 (or more!) because they are names for the addresses at which three successive addressable locations exist. I suppose you can adopt that position, but it's pretty perverse, and it wouldn't get you far in a class on compiler construction

Languages that supported typed variables are considerably different than those which do not. Typing allows compile and runtime detection of programming errors and allows dramatic improvements in compile-time optimization that are not possible in languages like C and SPIN. They're also far better at capturing the semantics of programs in a manner that's easy to read and understand and maintain.

Dave Hein

For the most part I agree with your statements about Spin. The Spin language does not allow for types. It only allows specifying storage size (i.e., byte, word and long). One-dimensional arrays (or vectors) are not explicitly defined in Spin, except for possibly the syntax used in VAR sections, such as "byte buffer[100]". One-dimensional indexed addressing can be applied to any variable, so this is really no concept of explicit array access at compile-time or run-time.

Clearly, the C language does support types. Type specifications are used at run-time to check for consistency in variable usage. Multi-dimensional arrays are also supported in C, so it is inaccurate to say that C does not support arrays. However, C does not include any type or array-bounds checking at runtime. At run-time you can pretty much do anything you want with a pointer and index without any error checking. So in that sense there is no type or array support at run-time.

idbruce

Both SPIN and C, refer to arrays with [], with plenty of documentation about arrays. Apparently you must have hidden knowledge that Parallax, Microsoft, Borland, etc... is unaware of. And perhaps you are correct in a hidden meaning type sense, but if they are commonly called arrays, I will refer to them as arrays, instead of being an oddball.

ksltd

Exactly what runtime checks does C do? To the best of my knowledge, none.

And despite the fact that the [] operator can be applied several times and create the illusion of multi-dimension arrays, the languages remain untyped with no support for vectors or arrays at all.

Let's come at this another way - think of an assembly language program for almost any architecture. Sure, you can create abstract data structures and operate on them endlessly - but the assembler and the assembly language and the instruction set have no support for arrays. This is the same situation with C and with SPIN.

Here's another example of how you can conclude there's no support for arrays:

dat
A long 0 [3]
B long 0 [3]

if I have the statement

A := B

That moves a single 32-bit long. Because A and B are declared as scalar variables, not arrays. There is no array type. There's just some syntax for allocating blocks of storage and doing some addressing math with the [] operator.

Similarly, if I have a subprogram declaration:

pub foo (N)

And I call foo with

foo (A)

The array isn't passed - either by value or by reference. Instead, the scalar variable A is passed by value to Foo - again, there's no array object, there are no array types. There's just scalars, block allocations at declaration time and addressing math with [].

Taken another way, think about floats. There's no float type even though there are several abstract class libraries that implement floating point. But within those libraries, there's no exported type definition for double precision float - because there's no types.

Finally, allow me to quote from the Kernighan and Ritchie (p 120 of 2nd edition of The C Programming Language) explanation of the travesty they created:

It must be emphasized that a typedef declaration does not create a new type in any sense; it
merely adds a new name for some existing type. Nor are there any new semantics: variables
declared this way have exactly the same properties as variables whose declarations are spelled
out explicitly. In effect, typedef is like #define, except that since it is interpreted by the
compiler, it can cope with textual substitutions that are beyond the capabilities of the
preprocessor.

C has no types.

Tor

Typedef does not create new types. But that does not mean that C has no types. It's just that you are stuck with the predefined types. As C actually checks that at compile time C is considered a typed language. There's no requirement that there must be runtime checking too, that's a different field.

edit: p.s. runtime checking has even less to do with it. It's not necessary to specify that in the language. I have used two C compiler/runtime systems with array bounds checking, one was the native C on a minicomputer and the other was a special GCC variant.

Dave Hein

ksltd wrote: »

C has no types.

Troll alert!!!

Phil Pilgrim (PhiPi)

What does it matter whether Spin's or C's support or non-support of types or arrays fits a particular definition? Both do what they do, and both are useful in their respective arenas. As long as programmers understand what each can and can't do, that's really all that matters. The rest is just a tempest in a teacup and not worth our time.

-Phil