Basic questions.

FORD

Hello All, just a few more queries that may help some of us basic users ...

1- Can·a·Propeller program be in a combination of spin code and assembly code ?
2- Can objects be·programmed in Spin, or·only assembly ?
3-·What is the performance downside of Spin compared to Assembly ?
4-·At 80 Mhz in Spin language, roughly how many instructions per second can be executed ?
5- Does the editor have an Eeprom (RAM) map ?

-·Am I correct in thinking...

- All of the variable and program space is on the 32kByte Eeprom.
- The more variables I declare, the less program space I will have, and vice - versa.
- The program on the Eeprom·is copied completely into the Prop RAM at power up.
- If the Eeprom is removed without a battery backup, the Prop will still run correctly until powered off.
- If the program and variables are say, only 3K in total, I can use the other 29K for data storage, plus add another 7 x 24LC256 for another 224 Kbyte data space.
- If I have an object that is used to calculate Eg: Miles per gallon, I only need that in the program once and I can call that object from any cogs I have running, simultaneously.
- If the item above is true, is it also·the same·for a Sub (label or whatever you want to call it), or just for Objects ?
- I can change the clock speed to as slow as possible while the system is idle, then following some·event or condition, I can wind the speed up for the time needed, and drop it down again when finished.

Cheers,
Chris Anderson
West Oz.


·

cgracey

FORD said...
Hello All, just a few more queries that may help some of us basic users ...

1- Can·a·Propeller program be in a combination of spin code and assembly code ? Yes.
2- Can objects be·programmed in Spin, or·only assembly ? Both, but a Spin interface is required to connect it to its parent object.
3-·What is the performance downside of Spin compared to Assembly ?·About 1:250.
4-·At 80 Mhz in Spin language, roughly how many instructions per second can be executed ? About 80k.
5- Does the editor have an Eeprom (RAM) map ? Yes.

-·Am I correct in thinking...

- All of the variable and program space is on the 32kByte Eeprom. Yes.
- The more variables I declare, the less program space I will have, and vice - versa. Yes.
- The program on the Eeprom·is copied completely into the Prop RAM at power up. Yes.
- If the Eeprom is removed without a battery backup, the Prop will still run correctly until powered off. Yes.
- If the program and variables are say, only 3K in total, I can use the other 29K for data storage, plus add another 7 x 24LC256 for another 224 Kbyte data space. Yes. You could also begin with a 128k byte EEPROM.
- If I have an object that is used to calculate Eg: Miles per gallon, I only need that in the program once and I can call that object from any cogs I have running, simultaneously. You only need it once, but you can only call it from COGs started within it's parent object, since the scope must be common. You could post·an address of a data structure that it updates, so that ANY other COGs could observe it.
- If the item above is true, is it also·the same·for a Sub (label or whatever you want to call it), or just for Objects ? Not sure what you mean.
- I can change the clock speed to as slow as possible while the system is idle, then following some·event or condition, I can wind the speed up for the time needed, and drop it down again when finished. Yes.

Cheers,
Chris Anderson
West Oz.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

LoopyByteloose

In lieu of using the 24LC256, can we use Ramtron FRAMs to get rid ot the slower write cycles?

I have noticed on their site that they have FRAMS which include fast memory, a RTC, two counters, low power id, etc. in one serial interface
Seems like a great add-on for the Propeller.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Gadgetman

80K?

Is that when using a single COG?
Almost twice as fast as the BS2px if it was running at the same clock, then?
(A BS2px does 19K with a 32MHz clock)
I guess that speaks volumes about the efficency of the interpreter.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...

FORD

Thanks Chip, and good luck with it all.

Cheers,
Chris
West Oz.

Paul Baker

Gadgetman said...
80K?

Is that when using a single COG?
Almost twice as fast as the BS2px if it was running at the same clock, then?
(A BS2px does 19K with a 32MHz clock)
I guess that speaks volumes about the efficency of the interpreter.

Yes, its even more amazing considering the entire interpretor fits in 512 instructions. If they didnt have to optimize for space it would be much faster.

Kramer, the eeprom reading routine is in firmware, so attaching an FRAM wouldn't affect the loading speed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

LoopyByteloose

Thanks Paul, I can stop wondering how to buy one [noparse][[/noparse]they don't have retail distribution channels].

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Paul Baker

www.newarkinone.com, I dont know if they ship to TW.·Ramtron has a list of distributors on thier site.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

Jon Williams

I'm going to try one of those too; while I'm working on a "soft" RTC object, it would be kind of neat to have a hardware RTC that could be easily incorporated into a Propeller design. It looks like the two 16-bit counters can cascaded into one 32-bit value as well. In the end, using this versus a standard 24LC256 (assuming the price is right) is like getting two extra [noparse][[/noparse]specific purpose] Cogs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax

Paul Baker

Yeah, I need to get some 3.3V versions for the propeller myself.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

LoopyByteloose

Ford, please forgive me changing the thread -- you questions are excellent.

It seems silly to be 'lusting for hardware', but this particular Ramtron chip really got my attention. It just seems a natural fit.

It is in the 'Processor Companion Family'. The FM31256 to be more exact.
So many of the right features together. There are a few that I will never use, but just the RTC and fast RAM @ 256K is enough.

I can easily understand that the firmware many have to be more generic and support slower writes from other EEPROM.

Am I correct in thinking this FRAM might be used to accumulate data? [noparse][[/noparse]not just store program instructions]

I asked for free samples and the Taiwanese Ramtron representative called me, but I haven't had the courage to call him back and tell him I only want a few to play with.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 3/12/2006 7:41:39 AM GMT

Paul Baker

Kramer said...


Am I correct in thinking this FRAM might be used to accumulate data? [noparse][[/noparse]not just store program instructions]

I asked for free samples and the Taiwanese Ramtron representative called me, but I haven't had the courage to call him back and tell him I only want a few to play with.

Yes its true for EEPROMS as well, Andre is using a 128K EEPROM instead of a 32K to store data and overlay code (code read into the propeller after intial load in). Samples are just a few, I got 4 from my sample request. I said Im an independent inventor and wanted to evaluate FRAM as a general memory replacement for future designs. It sound to them like the potential exists of you purchasing quite a bit in the future, but you aren't commiting yourself to doing so.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
·1+1=10

FORD

Hello all,
I asked above...
- If the program and variables are say, only 3K in total, I can use the other 29K for data storage, plus add another 7 x 24LC256 for another 224 Kbyte data space.

Chip replied with...
Yes. You could also begin with a 128k byte EEPROM.

I'm not sure on this.
Is it meaning that the Prop can use a 128K instead of a 32K Eeprom for the prop code, and I can use the rest of the space for data ?

Cheers,
Chris
West Oz.

I have taken it that the prop needs to have

CJ

from what I have come to understand, if you use a 128K eeprom, only the first 32K is loaded with your code, the rest is just available to use for whatever, lower parts count

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

FORD

Thanks CJ, perfect.

Are the 128 K Eeproms able to be daisy chained to 4 or 8 devices ?

Cheers,
Chris

Forrest

The 24LC128 (like all the 24LCxxx I2C EEPROM's) has three address lines (A0, A1, A2) to address 8 chips.

Tracy Allen

Eeprom chips are designated by the number of bits they contain, so the 24LC1025 has 128 kbytes, or 1025 kbits. (@1024 per binary kilo).

The Microchip 24LC1025 has addresses A0 and A1 available to support 4 chips on one I2C buss, for a total of 512 kbytes. However, the Atmel part, 24C1025, only has A0 so can only support one additional chip on the buss.

The FM31256 memory is 32k by 8 (256kbits), and the memory part in all respects seems to follow the same protocol as the 24LC256, so it should work fine. It has address lines A0 and A1 active for 4 devices with that slave ID on one I2C buss. The memory and the companion functions have separate slave addresses.

Eeproms have 64 or 128 byte pages that can be written as a block. Using that capability speeds things up immensely.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

FORD

Thanks Tracy, you just saved me heaps of time chasing stuff.

Cheers,
Chris

cgracey

There's one very handy benefit to having the 32k of Propeller RAM loaded verbatim from an EEPROM on boot-up:

By writing back to the EEPROM at the same address of a variable (@varname), you can make any variable non-volatile. Next time you boot, that re-written value will be loaded instead of the default 0.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

LoopyByteloose

Am I correct to believe that is what some other people call a 'persitent variable'?

And if so, the FRAM may again be superior [noparse][[/noparse]because of nearly unlimited writes].

Others that have used more generic EEPROM for persistent variables have had to be very careful not to program these into looped writes as you can easily loop over the 1,000,000 10,000 [noparse][[/noparse]pls. forgive the significantly low number, Mircochip's 25lc256 claims 1 million erase/write cycles] or so write limit.


At that point, you being to have 'dead addresses' in your EEPROM [noparse][[/noparse]simply worn out from excessive writes].

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"When all think alike, no one is thinking very much.' - Walter Lippmann (1889-1974)

······································································ Warm regards,····· G. Herzog [noparse][[/noparse]·黃鶴 ]·in Taiwan

Post Edited (Kramer) : 3/14/2006 4:01:07 PM GMT

Kaos Kidd

All this talk about spinning up and down (pun intended) of the speed of the Propeller chip leads me to one fundimental question:
Are the objects currently being designed take into account the CURRENT clock speed for speed sensitive functions.

It would appear that someone could get real "hung up" if something were to change the clock speed enough at the wrong time.
If you were designing objects that are "timing sensitive", then that object would have a need to read the current clock speed, and
then adjust it's contants (no longer constants), it uses for timing.
It would either be that or, read the speed, set to a known speed, do the function, the return the speed.
Either way you approch it, Objects that rely on clock speed need to be 'speed' awair, right?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Martin Hebel

Any code that relies on clock speed has access to the speed, such as value:=data/clkfreq.

True, changing the speed from one cog, while another is in the middle of an operation, such as a count based on time, would lead to error. It would take some coding by the developer to ensure this would be taken into account, such as maybe a shared flag that is set prior to performing a time critical operation and the other cog waiting until that flag is clear.
-Martin

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Perform an Employer's Survey of Electronic Technologies Graduates· - Click here!
Personal Links with plenty of BASIC Stamp info
and SelmaWare Solutions - StampPlot - Graphical Data Acquisition and Control

Kaos Kidd

I would assume along thoes lines Martin. I could see a complex line using time criticle functions is different cogs. More then likely at different times, but the possability (or probility) of a timing error can cerently creep into a complex program.
I could see the programmer being responsible for determining the chip's speed, and then the objects use the current speed to adjust them selves, as that would lead to the least problematic approch to the issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Just tossing my two bits worth into the bit bucket


KK
·

Tracy Allen

If it has the possibility to change, the current clock speed has to enter into the calculations. For example, to get a fixed time delay independent of clock speed, you would enter something like this:

waitcnt(clkfreq/5 + cnt) ' delay a little while, independent of clock.

So the number of counts delay is exactly proportional to clock speed. The RC clocks, 12 megahertz and 20khertz have quite a large tolerance range, so they cannot be used for time-critical tasks, except through a ratiometric scheme.

I don't see it as being a big issue, having to change clock speeds for one cog while another is in the middle of a time-critical routine. Usually changing gears will be a system level, global function that will be carried out by a high level supervisory routine. But who knows what will come up. A cog could enter a routine and store the current value of clkfreq, then check to see that it is the same when the routine finishes, if not, then, redo.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Tracy Allen

Chip Gracey said...

FORD said...

Hello All, just a few more queries that may help some of us basic users ...

1- Can a Propeller program be in a combination of spin code and assembly code ?
2->Both, but a Spin interface is required to connect it to its parent object.

This was a very confusing point to me, at first. You miight be used to other languages and compilers, like SX/B, for example, where assembly code is linked in line with code from the higher level language. In Propeller, it works differently. An individual cog runs either the spin interpreter or your application assembly code. Once booted up by a Spin command, the assembly program can run completely on its own in a cog, with no connection to anything going on in the other cogs, or, it can use the pointers that it receives when it starts up to connect to the other cogs to provide services or methods by passing data back and forth through the hub or through the i/o pins. The Spin code that starts it up assigns it the buffer space and pointers and those can be global to cogs started within its parent object.

The spin interpreter itself is a machine language program that occupies every single byte in the cog (or several instances of it in multiple cogs), and we have to be amazed how Chip and Jeff fit it all that functionality in there. How much can you do with 512 bytes? Well, that shows that you can do a lot. The Spin interpreter interprets code that resides in the main ram, so several cogs can share the methods and the data space there.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com