I see Spin as a procedural relatively typeless system programming language related to pre-standard C, BCPL and other early system programming languages. It has some object-oriented features, particularly its use of object-based name spaces, but no inheritance or operator overloading. It's very well matched to the hardware facilities and instruction set. The indenting scheme for statement nesting I think is borrowed from Python.
I learned programming back in the "golden age" of programming languages, so I'm kind of biased towards creating new and modified languages to fit unique hardware systems and operating systems' features. Languages do need some thought and need to be based on "generally accepted principles", but not slavish devotion to specific rules or conventions that don't necessarily match the underlying systems. Witness the result of any attempt to use standard C I/O libraries for any implementation on a microcontroller with no display or keyboard or other "system console". On the other hand, if you're going to attach a pretty conventional keyboard and display to such a microcontroller and provide a standard library for it, you'd better have some good reasons for not implementing the official standard I/O library calls. I can imagine some good reasons, but you'd need the justifications.
Thanks for that Mike....I am also a firm believer that a fundamental problem with modern software (I won't say it by name) is the reliance of bloated code stacked on bloated code....and on a fundamental level I have some serious issues with simply stacking objects (with no basis in understanding them). There is the issue of reality though. I mean why reinvent the wheel, to perform a simple task. If one needs to perform general high level function, I think we would all agree that a modern CPU/computer is far superior. So this is kind of where I am coming from. Why build such a device? This is what really dumbfounds me about SPIN/prop. I can respect the desire and "fun" factor in building from scratch. That is totally illogical though. That is why I can't marry the term "fun" with anything other than a toy. In a truly logical system, fun is not a concern. Only function (no I am not german, bad joke?),
I do understand your points better than the others presented. They are logical, and seem to come from a cold dark place (I mean that as a compliment). Maybe the better term is your rebuttal is blunt and logical? I appreciate it.
So here is a proposal. Is it possible to simply provide a translator for SPIN? I mean something that runs off the prop? I would have no troubles with that (does that exist?). I.E. can I run simple code translations on a fast powerful computer to create SPIN objects? This is not something I can comment on, because I have no knowledge of such a product. My goal is not to spend the necessary tedium on hand coding the kitchen sink. Some minor correction would be acceptable.
I know that migrating assembly into C is possible (in a verrrrry loose sense). Also migrating basically anything under the Sun (another pun) into Java is quite available. This was also my case for NET framework. I guess I am getting lazy with age. I just want to string enough Smile together to get a prototype up and running. I can always go back and lean things out later (I did mention I am more concerned with hardware?)
To me your points about C are quite good. I would be happy with a object translator on a real computer, and then tiny basic on the prop (yes I have a HYDRA)
yeah yeah I know I am probably dreaming again....but I need ways to test hardware quickly....I can't tear down and rewrite every time my hardware evolves (remember that thing I mentioned about being a hardware guy). If it helps I rebuild my desktop system ever few weeks (sickness?). That's never going to change. I do think the open CL implementation from view port is a step in the right direction, maybe others disagree. I would gladly give up cogs and pins to speed up development....by the time my concept is mature, prop 2 will be out anyhow....
hope this isn't off the topic of SPIN too much....I can't see having a discussion about it w/o mentioning all of this stuff....
Let me give you some background on my Prop/SPIN experience....I am most certainly a SPIN neophyte....would never claim to be more....I am, however VERY well versed in hardware (especially clocking and Voltage references)....I am attempting to gather data on the prop (and SPIN, since they are married) to determine it's validity for my needs....this does not assume that my needs are superior or in any way "innovative"....but to design platforms to fit my needs (must be very very small and low power) I MUST have accurate electrical specifications (such as acceptable deviation in vREF and i/o function)...this is to determine how many sub systems will be needed for my effort....
much to my dismay, I can't find this data....and I can't find any efficient way to compile common objects into SPIN (not denying that there are ways)....i thought this would be a good topic to bring up some of these issues, as it was a topic asking for opinions....I had hoped that my opinions would be heard in a defenseless manner and some information would be returned....this is the basis of my opinions and I try to present some facts that lead me to my opinions (did you look at the vastness of PIC specifications available in my link?)
so you may ask...."well what is your problem Ari, the prop isn't for you"....and that may be wholly valid....but I have enough respect for Parallax as a company (big fan of their business model, and they seem like great people) to investigate their offerings (i have been a stamp fan for a long time)....even though most of my peers have laughed at my notion of using the prop. (it is generally regarded poorly by the elitist crowd)....I would like to think I am giving prop/spin a fair chance here, and simply reporting my findings (never claimed to be anything other than a SPIN neophyte)...
there is validity in the advice "work with SPIN more"....and that is not taken lightly (on my part), but it's hard to work with something that you can't even use your existing object base with, and even more maddening to try to build a physical topology from trial and error (I am used to getting my design right the first time, based on specifications and simple math)
my needs are very tight voltage regulation and the ability to implement energy conservation/harvesting....I have tried almost all of the pre-fab protoboards (etc...). The voltage regulation is poor (at best)....the efficiencies are truly pathetic....9v to see 5v out? where are the switching regulators? where are the LDO's (at the very least)....
this leaves me with the trouble of building my own platform....and power supply, and clock (all of which I am comfortable with, and actually excited by)....but the total lack of schematic (that is acceptable for me to work from) is daunting....props aren't exactly cheap....I can't afford to blow them out to find their limitations....already killed one and a prop plug trying to find a hard limit....
Ah, that last sentence might be relevant.
Le's take a look at a few of those points because I reckon the prop can do what you need it to do.
1)
(and SPIN, since they are married)
not necessarily. PASM and the propeller are married. Spin is an interpreted language that runs in one cog. There other interpreted languages too - eg a version of Basic. heater wrote a Z80 emulator, which also runs on a cog and which replaces Spin. So you are not tied to Spin if you don't like it.
2)
(must be very very small and low power
small - yes, some of the packages are so small that if you sneeze and your workshop is a bit messy (like mine!), then bye bye chip. Low power - yes, because you can shut down parts of the chip that are not needed. How many microwatts are we talking?
3)
and I can't find any efficient way to compile common objects into SPIN
Maybe we have a misunderstanding here - maybe you mean something different with "common objects". To me, that means things like a uart, keyboard driver, display driver, mouse driver, sd card driver, analog I/O, digital I/O. Are there some specific other things you need?
4)
The voltage regulation is poor (at best)....the efficiencies are truly pathetic....9v to see 5v out? where are the switching regulators?
. They are on my board (see link at bottom of post). I wouldn't use anything but a switching regulator, but I admit I am in a minority here. Switchers are perfect for solar applications where the input varies and where watts are precious.
5)
this leaves me with the trouble of building my own platform....and power supply, and clock (all of which I am comfortable with, and actually excited by)....but the total lack of schematic (that is acceptable for me to work from) is daunting
My apologies for misunderstanding your use of the word 'schematic' earlier. To me, a schematic is the wiring diagram of all the chips that go to support the propeller - the power supply etc. But I think you might be using it to mean 'block diagram' of the internal wiring of the chip. If you want the latter, then it does exist, including photographs of the die which nicely illustrates the 8 cogs and the internal ram. However, I am still a bit confused, because knowing all the internal wiring of the chip is not really necessary to build a power supply for the chip. So I still don't quite know what you mean by 'schematic'? More specifically, what do you need to know? Supply voltage (= 3.3V and use a 3.3V regulator, don't try a different voltage), clock (use an external 5Mhz crystal), standard eeprom connection (see various boards). I guess there are the cunning tricks, like how to interface to 5V logic, and the standard stuff like driving a relay, stepper motor, speaker. All of these can be answered with a forum post. Can you describe your project a little more?
6)
ok so what does this have to do with SPIN....well you can't talk about SPIN w/o talking about prop. they are one.
You are not the first person to take a look at the propeller and at a new language and nearly walk away. Dare I say it, but this is where others have been in the past, others who went on to write the other languages. Get angry with the situation, then get coding! (or take advantage of all the clever coding already done).
No Spin in this program. Not one line. No spin behind the scenes either. This compiles straight to assembly code. It prints white text on a blue background on a vga monitor.
/* Traditional first C program */
#include <stdio.h>
void clearscreen() // white text on dark blue background
{
int i;
for (i=0;i<40;i++)
{
t_setpos(0,0,i); // move cursor to next line
t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100
}
}
void main ()
{
clearscreen();
printf("Hello, World!\n");
while (1); // Prop reboots on exit from main()!
}
Le's take a look at a few of those points because I reckon the prop can do what you need it to do.
1)
not necessarily. PASM and the propeller are married. Spin is an interpreted language that runs in one cog. There other interpreted languages too - eg a version of Basic. heater wrote a Z80 emulator, which also runs on a cog and which replaces Spin. So you are not tied to Spin if you don't like it.
2)
small - yes, some of the packages are so small that if you sneeze and your workshop is a bit messy (like mine!), then bye bye chip. Low power - yes, because you can shut down parts of the chip that are not needed. How many microwatts are we talking?
3)
Maybe we have a misunderstanding here - maybe you mean something different with "common objects". To me, that means things like a uart, keyboard driver, display driver, mouse driver, sd card driver, analog I/O, digital I/O. Are there some specific other things you need?
4) . They are on my board (see link at bottom of post). I wouldn't use anything but a switching regulator, but I admit I am in a minority here. Switchers are perfect for solar applications where the input varies and where watts are precious.
5)
My apologies for misunderstanding your use of the word 'schematic' earlier. To me, a schematic is the wiring diagram of all the chips that go to support the propeller - the power supply etc. But I think you might be using it to mean 'block diagram' of the internal wiring of the chip. If you want the latter, then it does exist, including photographs of the die which nicely illustrates the 8 cogs and the internal ram. However, I am still a bit confused, because knowing all the internal wiring of the chip is not really necessary to build a power supply for the chip. So I still don't quite know what you mean by 'schematic'? More specifically, what do you need to know? Supply voltage (= 3.3V and use a 3.3V regulator, don't try a different voltage), clock (use an external 5Mhz crystal), standard eeprom connection (see various boards). I guess there are the cunning tricks, like how to interface to 5V logic, and the standard stuff like driving a relay, stepper motor, speaker. All of these can be answered with a forum post. Can you describe your project a little more?
6)
You are not the first person to take a look at the propeller and at a new language and nearly walk away. Dare I say it, but this is where others have been in the past, others who went on to write the other languages. Get angry with the situation, then get coding! (or take advantage of all the clever coding already done).
No Spin in this program. Not one line. No spin behind the scenes either. This compiles straight to assembly code. It prints white text on a blue background on a vga monitor.
/* Traditional first C program */
#include <stdio.h>
void clearscreen() // white text on dark blue background
{
int i;
for (i=0;i<40;i++)
{
t_setpos(0,0,i); // move cursor to next line
t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100
}
}
void main ()
{
clearscreen();
printf("Hello, World!\n");
while (1); // Prop reboots on exit from main()!
}
thank you for this reply....I see you have taken the time to understand my points of concern. That is very generous of you.
I hope I am not taking this thread off topic....I really think i am (that is rude of me and not my MO)
I should create a blog or new thread around this, but I suppose it is very relevant to the original topic? also it is a reborn thread, so i hope we are within the bounds of decency to go down this path?
so is there a simple way to reflash (slang) the chip? I mean are we forever married to PASM and SPIN terp. on chip? I can't see it any other way. Better yet, could i simply build in my language of choice and then translate that to objects the prop could call from a resource pool? the more I play this out in my head, the less reasonable it seems...but what the heck....it's nice to know my options
I actually really like SPIN....it's so well suited to the hardware.....but I can't stomach the idea of writing an object/resource pool from scratch....I mean the word/long thing is odd, but that is really being picky...I do prefer BASIC....but that isn't Java either....and Java would certainly be somewhere off in outer space on prop...
on the issue of size, I have no issues working with surface mount packages....I have the necessary tools and skills....minus BGA....which I have a real problem with (on so many levels)....but the QFP package seems workable....I actually wish prop was available in a 0.3mm package, but I digress
I will address the power restrictions a bit further down....
by common objects I meant my own proprietary objects....which are a blending of a few disciplines and would probably encompass an entire thread to discuss (which I am happy to do at some point)....I am less concerned with basics things, as my objects rely on a deviation from the norm. Especially when it comes to timing and linearity.....but the main points of concern are PWM and clock ref (which I will address further down)
here is my real passion, PSU. I am going to employ a buck boost for my platform. I need to have this functionality, as my power source will be 11.1v or greater. I already have my PSU prototyped, and the numbers are staggering. Suffice it to say that I want to use my own design, for the sake of size and the amount of R&D I have into it. I am an engineer by trade, so this is the part of my concept I am very confident in. I will employ solar to handle stand-by current and nothing more. I want a design with essentially zero draw at idle. I will employ a x-y tilt axis in the small solar cell which will be built into the device case. It will ideally track the optimal collection position throughout it's "up time". This could prove to be an poor concept (how much power will the photo-optical and servo/positional ref take, vs the output from the cell)....I digress.....in terms of microwatts...it is a moving target....but my battery constraints are roughly 800mah at 11.1v (25c) to 2100mah at 11.1v (40c or better)....yes there are peripherals that will pull in excess of 3 AMPs....but only for extremely short periods of time
on the issue of "schematic". I come from an engineering background. So i use the term in the most raw sense possible. This is why I used the term "on die" schematic. I have no use for any data off the chip pins, as i am comfortable engineering that aspect. I do need to know absolute minimums and maximums for pins....especially the drift in pin regulation (PWM, etc.....)....minimum and maximum thermal and moisture....the ambient shift in impedance etc.. etc etc....like I said i need it to be VERY thorough....as I need to operate at absolute MAXIMUM efficiency....every last bit counts
my main concern isn't learning the language.....I am pretty quick with logical operations (currently enrolled in CCNA) and I have yet to see anything as complex and convoluted as IPv4 subnetting. I was able to write my first complex SPIN program in a few hours. It was actually very nice to work with. My main concern is having to rewrite everything I am already sitting on. This is especially complex, as I employ a technique I like to call "program bouncing" or "object chunks"....this is where things get really out of hand....this is also where a highly accurate clock ref. and vREF come into play....a crystal clock is nowhere near accurate enough for my needs....I need to employ a precision oscillator or clock that can poll an NTP server....time is one of the single most critical functions of my concept (at least under the surface)....if the clock was to swing at all, my "chunks" would become non-linear and the data running within that polling cycle would become a problem....and possibly cause a catastrophic failure....this would be devastating if the operation was battery management and I had a runaway overcharge or discharge.....it could lead to explosion....
yeah I know, it's a lot to take in....and I am probably in WAY WAY WAY over my head, but that just makes it more rewarding.....
I suppose one way to avoid the misery of thinking about writing my "chunks" is to just do it....employing a cog or 2 as a resource allocator shouldn't be too much of a concern.....as the platform is not intended for computing purposes or data collection....it's simply a power platform for many different peripherals.....but it must be "smart" enough to govern it's own power consumption...and must equal a self balancing load at idle (that's where the solar harvesting comes into play)....
I am also considering cortex series chips....or a network of PIC's.....but for some reason i have a illogical love for the propeller
thanks for taking the time to listen and for your willingness to give me your input/feedback
Ari,
The BYTE, WORD nomenclature for 8 and 16 bit data items has been around since the invention of the micro-procrssor and long before that. It is you that is out of touch here.
Take a look at any assembler code for the Intel 8085 for example. Or the PL/M high level language that Intel provided for that chip.
What do you mean by schematic? I cannot think of any mainstream processor vendor that provides schematics of their processors.
Anyone who has been around micro-controllers and real-time systems would no that .NET and Java are not suitable if you want small size and or speed. There is a Java VM for the prop if you want it.
Ari,
The BYTE, WORD nomenclature for 8 and 16 bit data items has been around since the invention of the micro-procrssor and long before that. It is you that is out of touch here.
Take a look at any assembler code for the Intel 8085 for example. Or the PL/M high level language that Intel provided for that chip.
What do you mean by schematic? I cannot think of any mainstream processor vendor that provides schematics of their processors.
Anyone who has been around micro-controllers and real-time systems would no that .NET and Java are not suitable if you want small size and or speed. There is a Java VM for the prop if you want it.
as I am sure you know the logical term WORD is not fixed in length, and only takes on an attributable length to stop programming complexity and ingestation of existing code....I am not in any way out of touch
....also why are you regurgitating the ideal that I already stated.....which is that I would ideally like Java or .Net to be an option for a front end....yet I stated NUMEROUS times that I understood that was not an option for my timeframe....are you reading my posts entirely or just being reactionary to the first thing that rubs you wrong? Java is the basis of Arduino IDE, so I am not sure where you are coming from.....also I can link you to an in depth article where computer science students used .NET to implement a network stack into a HYDRA based project for full-duplex communication between 2 units....again an example of what I am illustrating.....you just aren't reading what i write....or trying to understand it....here is that write up
I already explained what an on die schematic is, and I provided a link to a company that provides thousands of such schematics for their products.....once again do you read what i write, or are you just being reactionary towards me on purpose?
you are being rude, and I have not made one single negative comment towards you....why do you feel the need to answer in such a tone?
if you can't be courteous, please don't respond to me....I promise you that it does no good
so is there a simple way to reflash (slang) the chip? I mean are we forever married to PASM and SPIN terp. on chip? I can't see it any other way.
The chip must not be "reflashed" to use another language than Spin. The code that the language compiler produces goes anyway into the 32kByte MainRAM when it is loaded to the Propeller. In case of Spin a little Interpreter (VM) is started in a cog from the ROM. In case of C (catalina) the VM is integrated in the code and in case of PropBasic you don't need a VM, its pure Assembly code. For sure you can't change PASM it's the native instruction set of the CPU.
Better yet, could i simply build in my language of choice and then translate that to objects the prop could call from a resource pool? the more I play this out in my head, the less reasonable it seems...but what the heck....it's nice to know my options
I actually really like SPIN....it's so well suited to the hardware.....but I can't stomach the idea of writing an object/resource pool from scratch....
I hope you are aware of the OBEX. If you talk of your special objects - see above.
For exact timings: Every cog has 2 counters with several modes. They can measure an input pulslength with 12.5ns resolution, count pulses up to 40 MHz or generate output pulses with 12.5ns resolution i.e. for PWM.
I have no use for any data off the chip pins, as i am comfortable engineering that aspect. I do need to know absolute minimums and maximums for pins....especially the drift in pin regulation (PWM, etc.....)....minimum and maximum thermal and moisture....the ambient shift in impedance etc.. etc etc....like I said i need it to be VERY thorough....as I need to operate at absolute MAXIMUM efficiency....every last bit counts
.
If this is so important and you don't trust the Propeller pins you can always use well documented external buffers between the pins and your hardware.
I learned programming back in the "golden age" of programming languages, so I'm kind of biased towards creating new and modified languages to fit unique hardware systems and operating systems' features. Languages do need some thought and need to be based on "generally accepted principles", but not slavish devotion to specific rules or conventions that don't necessarily match the underlying systems. Witness the result of any attempt to use standard C I/O libraries for any implementation on a microcontroller with no display or keyboard or other "system console". On the other hand, if you're going to attach a pretty conventional keyboard and display to such a microcontroller and provide a standard library for it, you'd better have some good reasons for not implementing the official standard I/O library calls. I can imagine some good reasons, but you'd need the justifications.
Yes. In shorter terms, it's the right tool for the right job
I learned programming on a TRS-80, and indeed the Propeller reminds me of this era when you had the possibility of fully understanding your system, from top to bottom.
No troll feeding going on here. I don't think, anyway. These are technical questions that I think the prop is more than capable of solving.
1) Current consumption. Interesting discussion here http://forums.parallax.com/showthread.php?104293-Minimising-Propeller-Current-Consumption but there may be an issue with your timing - you can drop the consumption by decreasing the clock but that loses timing accuracy. I am not sure about that, but then again, I am not sure of any other micros that could run at better than xtal accuracy with ultra low power consumption.
Re xtal not being accurate enough, are we talking oven controlled xtal? Hmm - that takes energy, and we don't have much of a budget here.
2)
here is my real passion, PSU. I am going to employ a buck boost for my platform. I need to have this functionality, as my power source will be 11.1v or greater.
What is the boost bit for? Buck will get you to 3.3V but are there some other peripherals we need to know about? Lots of options if there are, especially if they are intermittent. Heck, you could use the prop to turn on a transistor to turn on a relay to turn on a 12V to mains inverter if it was very intermittent.
I use a LM2574 for the 3.3V supply, and a LM2575 for a 5V supply.
3)
.this would be devastating if the operation was battery management and I had a runaway overcharge or discharge.....it could lead to explosion....
. I guess you need to think about failsafe mechanisms there - maybe some old-skool supporting electronics with op amps, fets, transistors? Nothing impossible to design here, and indeed, there are some nifty chips around that support micros and detect under voltage, brownouts, deliver a clean reset pulse etc. I've even resorted to latching relays for undervoltage cutout. More recently though, I've found that with solar it is easier to drop in pre-built modules. 10W panel, charger http://www.futurlec.com/Solar_Charge_Controller.shtml and a 7aH gel cell (cheaper as used in bulk by the security industry). Check the data sheet of the charger - under voltage protection, 4 stages of charging, 6mA self consumption. If that isn't what you want, maybe replicate it on the propeller (maybe a second propeller dedicated to power management?)
I've never been entirely convinced about the cost/benefits of trackers - on any scale. Small ones using servos and you have to work out how much power you make by tracking, the cost at (say) 15c per KwH and how long it takes to pay back the cost of a couple of servos. And at the bigger scale, wind loading becomes the limiting factor. But maybe it can be made to work.
4)
so is there a simple way to reflash (slang) the chip? I mean are we forever married to PASM and SPIN terp. on chip? I can't see it any other way.
. Yes to PASM. No to Spin.
5)
.also I can link you to an in depth article where computer science students used .NET to implement a network stack into a HYDRA based project for full-duplex communication between 2 units....again an example of what I am illustrating.....you just aren't reading what i write....or trying to understand it....here is that write up http://itech.fgcu.edu/faculty/zalews...aReportESP.pdf
That is an interesting article. Just to clarify, I think there is a PC running java.net and acting as the interface. There is code around to do that - I use vb.net but it is not dissimilar to java.net. I also use wireless RS232.
6) word vs byte. Not my area of expertise. Much code on the obex uses "longs" which are 32 bits. Some code possibly over-uses "longs", eg to store "true" or "false", but since this is the native size for the processor it is easier to code that way. In porting code over to C, I am using "unsigned long" as the variable type most of the time - probably not the first variable you would think of using but it makes for easier translation.
7)
I do prefer BASIC....but that isn't Java either....and Java would certainly be somewhere off in outer space on prop...
. I think there is some java somewhere? There certainly is Basic - in many dialects. Propbasic, Interpreted Basic. I'm using BCX Basic at the moment, but in the past I have used SBasic (a language for CP/M that was way ahead of its time, more like C than Basic).
Some BCX basic below (with a bit of inline C). Again, an absolute 100% Spin Free Zone here.
' Big Basic For external memory on the Propeller using BCX Basic To C converter And Catalina
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include <ctype.h>
#include <errno.h>
#include <float.h>
#include <inttypes.h>
#include <limits.h>
'#include <mathconst.h>
' mathconst.h upsets tinyc
$COMMAND
catalina -lcx -lm -x5 -M 128k -D DRACBLADE -D VGA_HIRES
' library cx, library maths (slow, Doesn't use a cog), memory size, board, high res vga, mouse, keyboard
$COMMAND
Call WhiteOnBlue
Dim a As integer
Dim i As integer
For a=1 To 3
Print "hello world";
Print a
Next a
$COMMENT
' file test copied from bcx examples - Files work - commented Out For speed
Print "Opening file For output"
Dim MyFileHandle@ ' BCX Reserves @ For "C" FILE* Data types
Open "new.txt" For OUTPUT AS FP1
MyFileHandle@ = FP1
FPrint MyFileHandle@, "This is a test"
Close FP1
Print "Closing file"
$COMMENT
' ASC Function
Dim Mystring$ As String * 80 ' 80 characters
Dim RetVal%
Mystring$="A"
Print Mystring$
RetVal% = ASC(Mystring$)
Print RetVal%
'CHR$ Function - opposite Of ASC
a=65
Mystring$=Chr$(a) ' declared in asc
Print "Character should be A: ";Mystring$
'VAL Function - converts string To Double number. From the BCX help file
Dim StringNum$ As String * 20
Dim RetDub#
StringNum$="3.1415927"
RetDub#=Val(StringNum$)
Print RetDub#
'STR$ Function - opposite Of VAL. Converts number To string
Dim RetStr$ As String * 20
Dim DoubleNumber#
DoubleNumber# = 1.23456789
RetStr$ = Str$(DoubleNumber#)
Print RetStr$
' Test some inLine C code - pass a value in myarray, C changes it, Print the return value
Dim myarray[5] As integer ' this can be much bigger If you like, eg 50000
myarray[1]=100
Print myarray[1]
Call TestCCode
Print myarray[1]
' test some string functions
Dim lineoftext1$ As String * 80 ' strings must End in $ otherwise compiler Doesn't copy properly
Dim lineoftext2$ As String * 80
lineoftext1$="Hello World" ' string name is Case sensitive
lineoftext2$=Left$(lineoftext1$,4) ' left characters
Print "Left$ test ";lineoftext2$
lineoftext2$=Mid$(lineoftext1$,5,4) ' mid characters
Print "Mid$ test ";lineoftext2$
lineoftext2$=ucase$(lineoftext1$) ' upper case
Print "Upper Case test ";lineoftext2$
lineoftext2$=Right$(lineoftext1$,3) ' right characters
Print "Right$ test ";lineoftext2$
lineoftext1$="Hello"
lineoftext2$="World"
Concat(lineoftext1$,lineoftext2$) ' add two strings - same as + Or & in vb.net
Print "String concat test ";lineoftext1$
lineoftext1$="ABCDEFG"
lineoftext2$=lcase$(lineoftext1$) ' lower case
Print "Lower Case test ";lineoftext2$
a=1000
lineoftext1$=Hex$(a) ' hex$ working
Print lineoftext1$
Dim retval% ' hex2dec = two errors, DWORD (which I think can be changed To unsigned long) And CharLowerA which instr also is unhappy about
retval%=hex2dec("0xFFFF") ' reverse Of hex$, can use 0x Or &H syntax Or even FFFF
Print "Hex2Dec test ";retval%
lineoftext1$="12345abc6789"
lineoftext2$="abc"
a=Instr(lineoftext1$,lineoftext2$,3,0) ' instr search For characters. Last value is needed, use dummy 0 (matches case)
Print "Instr test, string is at position ";a
a=255
lineoftext1$=bin$(a) ' test Binary
lineoftext1$=lpad$(lineoftext1$,32,48) ' test adding leading zeros with lpad so is always 32 char long
Print "Binary value is ";lineoftext1$ ' test Binary To strings And back again
lineoftext1$="0000000001010101"
Print "Binary string To decimal ";Bin2dec(lineoftext1$) ' Binary
lineoftext1$=String$(10,65)
Print "String Function ";lineoftext1$' n characters Of ascii value m
lineoftext1$=" trim test " ' trim off leading zeros, spaces etc
lineoftext1$=trim$(lineoftext1$)
Print "Trim test:";lineoftext1$
' test a string array
Dim Stringarray[5] As String * 80 ' 80 characters
Stringarray[1]="Hello"
Stringarray[2]="World"
Print Stringarray[2]
' bitwise operators - there are many more Of these but they all seem To work ok withOut code changes
a=1
a=a << 10
Print "bitwise shift left";a
a=a >> 4
Print "bitwise shift right";a
a=1
a=a And 0xFF
Print "logical and";a
a=a Or 0xFF
Print "logical or";a
Print "test starting with a Binary string And shifting"; bin2dec("00000001") << 4
' test program control Loops - For is already tested above
a=1
Do
Print a
a=a+1
Loop Until a=3
Print "Do Loop finished"
a=1
While a <3
Print a
Incr(a)' translates To a++ in C
Wend
Print "Wend Loop finished"
a=5
Select Case a
Case 1
Print "1"
Case > 1 And < 6
Print "more than 1 And less than six"
Case Else
Print "something Else"
End select
' test functions
Print addnumbers(5,6)
' test some maths with floating point numbers
Dim number1 As Double
number1=1.2345
Print number1
Print Sin(number1)
Print Log(number1)
$CCODE
while(1); // Loop instead Of finishing
$CCODE
' And exitprocess Does Not work on the propeller. So Don't use End For the moment
' Subroutines And functions
Function addnumbers(a As integer, b As integer)
Dim returnvalue As uint
returnvalue = a + b
function=returnvalue
End Function
Sub TestCCode
$CCODE
// declare the variables:
int nNumber;
int *pPointer;
// now, give a value To them:
nNumber = 15;
pPointer = &nNumber;
// Print Out the value Of nNumber:
printf("nNumber is equal To : %d\n", nNumber);
// now, alter nNumber through pPointer:
*pPointer = 25;
// prove that nNumber has changed as a result Of the above
// by Printing its value again:
printf("nNumber is equal To : %d\n", nNumber);
myarray[1]=110;
$CCODE
End Sub
Sub WhiteOnBlue() ' white text on blue background
$CCODE
int i;
for (i=0;i<40;i++)
{
t_setpos(0,0,i); // move cursOr To Next line
t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100
}
$CCODE
End Sub
Regarding "chip schematics" ... maybe you're referring to the schematics of I/O pin circuitry or occasionally clock oscillator circuitry that are found in most microprocessor manuals and datasheets. Read the fine print ... they're functional schematics. The actual on-chip structures are somewhat different and, in terms of the fine detail that you're concerned about, the schematics are of limited utility. The Propeller datasheet has some similar functional schematics for the "or" chain for the I/O registers.
I know it would be tedious, but you can read some of the (very long) old threads here on the development of the Propeller including the characterizations that make up the datasheet. This chip was developed very deliberately by essentially one person to fill needs unmet by other microcontroller chips. It's striking that the Propeller has not required the kinds of workarounds and/or revisions that litter the landscape. With the exception of one failure mode from supply overvoltage spikes, the chip has proven to be extremely robust.
Just out of curiosity, and not to start anything, has anyone ever used >= and <= for their defined purposes? If so, how and why? They're rather odd in that they change the intrinsic type of a "number" variable to "boolean", which is a strange thing for any modify-and-assign operator to do.
Before the days of C and its many derivatives most languages (including BASIC to this day) used >=, <=, <>, and = as comparison operators. I do not use spin (prop asm is much simpler), Though I would think that the case is:
x >= y ' True if x is greater than or equal to y.
x <= y ' True if x is less than or equal to y.
x <> y ' True if x is not equal to y.
As stated I do not use SPIN, as such I may be completely wrong.
These operators are for conditional math expressions, and or implementing program logic without if then statements. Expressions in SPIN can evaluate to values, or results of comparisons. A good use of these is in the CON section, where a condition defines a value, but there is no run time if-then structure to address that.
The assignment of BOOLEAN to a variable permits making a comparison, and storing the result to be acted on in a future expression, again, without the if-then structure. Generally, a multiply is used to either do something, or not, depending on the result of the comparison. This is one reason why true is -1 on the Prop. Makes that kind of operation easier. The multiply can be replaced with boolean AND. Because all the bits are set, a value can be made active in a expression or not, based on true or false. False is 0, producing 0 after the boolean AND, or true -1, delivers the value after the boolean AND is complete.
It's kind of old school these days, but very similar to how expressions would be done in PASM. I like that SPIN permits this because there is a greater mapping between it and PASM, if the programmer desires.
If Y is greater than, or equal to 5, add 100 to X.
Oh, potatohead, you've succumbed to the same trap that catches me from time to time (and which prompted my original post cited above): greater-than-or-equal, of course, is =>.
y >= 5 means assign the value true to y if it's greater than 5; otherwise, assign false. I actually used this once. Just once. But, IMO, Spin would be better off without it and the confusion it causes.
Yeah, I get that all the time. Smile. Perhaps there is a reason I chose potatohead for a handle, besides the fact that I really liked my "Mr Potatohead" toy as a kid!
The idea is the same though. Let's say Y is used as some accumulator, which will be compared. Doing it with the assignment operator means storing the comparison and performing it all at one time, which sets things up for the logical AND to follow. Could also be several logical AND operations too, with Y carried over from one to the next. I still see it as being similar to how things would be done in PASM.
So then:
Y := x + z * 3 'Perform transient computation
Y >= 5 'evaluate and store comparison result
a := a + Y & 50 'add 50 to A on result = TRUE
b := b + Y & 48 'add 48 to B on result = TRUE
carry on...
That construct can be more efficient in spin than the if - then constructs are, and it runs in a consistent amount of time, again the parallel to PASM can be seen, IMHO.
Thanks Phil, for once again, digging me outta the SPIN trap. It's a common trap for me, because it reads in such a tempting way, LOL!!
Re: Better off. Maybe! I deffo see your point, because I have been caught by that multiple times. But... I'm kind of in the UNIX camp, so that means give me the tools to get into trouble. I'll get into trouble, and be sorry for it, but I'll also do great things too! Over time, the great things will trump the trouble.
BTW: I think my expression in the post above works, with the comparison left in Y, for subsequent operations to follow. Not at a prop right now though.
I've used it in a form similar to the above sometimes, as well as in CON sections, where the sequential processing doesn't allow for decisions without using these kinds of constructs. It's then possible to have conditional constants, which is of value, IMHO.
If TRUE was simply 1 and not -1, then a multiply would be required for the conditional math. Props have no multiply. Maybe somebody can remember to ask Chip about this at the next get together. I've often wondered about why TRUE was -1. I think these kinds of constructs are the reason, but it would be great to hear what Chip was thinking at the time.
If true were 1, inline conditionals would be more expensive to compute. Having it equal -1 is not without precedent. The various flavors of Microsoft BASIC have always done it that way.
I didn't know that. Mostly I've not used Microsoft basic, but for the Color Computer 2, and 3. I'll have to fire that one up and see what TRUE is, and whether or not it does these kinds of constructs. Not all BASIC environments will.
IIRC, HP BASIC derivatives used 1 for true. My first computer, a Poly 88, came with an HP BASIC variant that had to be loaded from audio cassette tape.
I will start a blog about my concept of "program bouncing" and "chunks"....please be patient with me for a couple of days to get a technical description put together....I would like to illustrate a unique concept for parallel processing of small objects....that equal an output value of one large nested object....
you could consider this multi-threaded or parallel, but neither is a correct description of the actions at play....
the problem with my process/concept lies in timing and collective allocation/pool of the "chunks"
I am probably just duplicating something very common, or at least conceptualized, by other process....but for me to accomplish tasks in an environment which i have limited experience (prop/SPIN) it's what I have to resort to....maybe someone can shed light on the topic once I properly describe it
and it will possibly be back to school for me as well.....I think (in this case) my own naivety could lead to a larger benefit for others (once everything has been properly sussed out)
Regarding "chip schematics" ... maybe you're referring to the schematics of I/O pin circuitry or occasionally clock oscillator circuitry that are found in most microprocessor manuals and datasheets. Read the fine print ... they're functional schematics. The actual on-chip structures are somewhat different and, in terms of the fine detail that you're concerned about, the schematics are of limited utility. The Propeller datasheet has some similar functional schematics for the "or" chain for the I/O registers.
I know it would be tedious, but you can read some of the (very long) old threads here on the development of the Propeller including the characterizations that make up the datasheet. This chip was developed very deliberately by essentially one person to fill needs unmet by other microcontroller chips. It's striking that the Propeller has not required the kinds of workarounds and/or revisions that litter the landscape. With the exception of one failure mode from supply overvoltage spikes, the chip has proven to be extremely robust.
Mike you touch on some specific areas of interest. The detailed i/o block schematic (including complete thermal, and current deviations) would be most helpful.
I have no real use for schematics of any "legs" of the chip beyond there.....as you said, that would not be very useful....since i can't do much about interacting with those structures (unless you have access to a "shrink ray")
Be aware of the time required to start a COG. On COG new, the memory image for the COG to operate in is copied from the HUB to the COG, prior to program execution. 512 hub to cog memory operations take place. I don't have that cycle count handy. Somebody here does though.
This thread is offtopic since post #12 or so. And it is so old that I think the original poster don't expect any on-topic responses anymore.
The chip must not be "reflashed" to use another language than Spin. The code that the language compiler produces goes anyway into the 32kByte MainRAM when it is loaded to the Propeller. In case of Spin a little Interpreter (VM) is started in a cog from the ROM. In case of C (catalina) the VM is integrated in the code and in case of PropBasic you don't need a VM, its pure Assembly code. For sure you can't change PASM it's the native instruction set of the CPU.
I hope you are aware of the OBEX. If you talk of your special objects - see above.
For exact timings: Every cog has 2 counters with several modes. They can measure an input pulslength with 12.5ns resolution, count pulses up to 40 MHz or generate output pulses with 12.5ns resolution i.e. for PWM.
.
If this is so important and you don't trust the Propeller pins you can always use well documented external buffers between the pins and your hardware.
Andy
thanks for that Andy,
I see, from your description that the terp. is what it is....and I have no issue with that (I suppose) since each hardware discipline relies on a native instruction set....I would love to know more about how PASM translates it's code to physical topologies (for purely academic reasons)....but I understand that we are married to PASM, and the on chip terp. (you have helped clarify that for me, so thanks)
I would have a look at Mr. Heins translator, but I fear it would vanish into thin air....since his accusation is that I am somehow "trolling" (it's a joke Mr. Hein, I am not a troll here)
I have looked at most of the OBEX offerings, and I think it would be pretty easy to deconstruct those objects into usable "chunks" (I know I need to describe that better). I hope everyone offering those objects is open to their modification and inclusion in new/unique code?
the use of external "buffers" would be possible, but impractical, if the prop already is within acceptable ranges. Size is a really big (pun?) concern....and when I say small....I mean small....
thanks again for responding Andy....I especially appreciate the clarification about the on board terp.
Be aware of the time required to start a COG. On COG new, the memory image for the COG to operate in is copied from the HUB to the COG, prior to program execution. 512 hub to cog memory operations take place. I don't have that cycle count handy. Somebody here does though.
7.5 us....it's not acceptable....but I can include an offset for this at the beginning of each "initiator"...
This is where PASM could be handy for me....the allocator could be a residual in centralized memory
am I replying to something that was even directed at me? If not then apologies....
A detailed I/O block schematic really wouldn't be helpful for the sorts of things you're interested in. The components that would be used don't exist the way you might think of them. There are also a lot of "parasitic" relationships, both thermal and electrical, that wouldn't show up ... another part of the transformation from a chip layout to a functional schematic. I suggest you make up a list of the sorts of things you need ... in priority order ... and send a private message to Beau Schwabe about them. He may have some informal measurements that you could make use of. I'm thinking of things like output voltage high vs. current output or output voltage high vs. chip temperature and supply voltage. These are things that are very resource intensive to do formally where you need to sample chips and characterize them over a wide variety of conditions, but he may have done some spot checking that he could share.
BTW, Parallax does have a "shrink ray" in the form of an electron beam probe that was used to debug the Prop. You might read "Why the Propeller Works" here if you haven't already.
No, that was directed your way Ari. COG start time is significant, as is fetching overlays. LMM helps here, because it's possible to execute and fetch at a low latency, requiring only a small kernel to be running in what I like to call the "supervisor" COG. That supervisor can provide services to the running LMM program, which is really just a subset of PASM residing in the HUB, instead of in the COG. Services could be threading, I/O, math, etc... The resulting program is PASM, with custom opcodes, understood by the kernel. Necessary for jumps at a minimum.
I don't understand how the "allocator" could reside in central memory. The only place things are executed is in the COG space. Everything else must either be fetched into the COG, using a HUB operation (LMM), or pins (XMM), or interpreted byte code style (SPIN, others...). Unless that allocator is really just one COG acting as the control COG, which is probably what you meant.
As for the code in the OBEX, it's MIT, so do what you will, but also do consider contributing back to the pool for others. That's the default expectation with the OBEX and the code found there.
You can shave some time off the COG init time with a higher clock. The reference clock is 80Mhz, but our shared experience basically shows Propellers running nicely at 100Mhz. Parallax sells some 6.25 Mhz xtals for this purpose. (thanks Bill Henning for pushing that). The alternative is probably 96 Mhz with a standard 6Mhz xtal.
Just talking Prop stuff. That's what we do. Not a challenge, or anything else. You will find this group kind of synergistic that way. It's natural for people to toss in what they know, because there is a lot of interesting things to know, that might not be obvious at first glance, compared to a more traditional CPU. That's all.
In particular, the idea that programs only execute in the COG memory space is worth noting. It's missed by a lot of people new to the Prop, as is the init time. One of the most common misunderstandings is that HUB / COG relationship, with the idea that the COG executes directly from the HUB, which is why I wrote what I did just now.
No troll feeding going on here. I don't think, anyway. These are technical questions that I think the prop is more than capable of solving.
1) Current consumption. Interesting discussion here http://forums.parallax.com/showthread.php?104293-Minimising-Propeller-Current-Consumption but there may be an issue with your timing - you can drop the consumption by decreasing the clock but that loses timing accuracy. I am not sure about that, but then again, I am not sure of any other micros that could run at better than xtal accuracy with ultra low power consumption.
Re xtal not being accurate enough, are we talking oven controlled xtal? Hmm - that takes energy, and we don't have much of a budget here.
2) What is the boost bit for? Buck will get you to 3.3V but are there some other peripherals we need to know about? Lots of options if there are, especially if they are intermittent. Heck, you could use the prop to turn on a transistor to turn on a relay to turn on a 12V to mains inverter if it was very intermittent.
I use a LM2574 for the 3.3V supply, and a LM2575 for a 5V supply.
3) . I guess you need to think about failsafe mechanisms there - maybe some old-skool supporting electronics with op amps, fets, transistors? Nothing impossible to design here, and indeed, there are some nifty chips around that support micros and detect under voltage, brownouts, deliver a clean reset pulse etc. I've even resorted to latching relays for undervoltage cutout. More recently though, I've found that with solar it is easier to drop in pre-built modules. 10W panel, charger http://www.futurlec.com/Solar_Charge_Controller.shtml and a 7aH gel cell (cheaper as used in bulk by the security industry). Check the data sheet of the charger - under voltage protection, 4 stages of charging, 6mA self consumption. If that isn't what you want, maybe replicate it on the propeller (maybe a second propeller dedicated to power management?)
I've never been entirely convinced about the cost/benefits of trackers - on any scale. Small ones using servos and you have to work out how much power you make by tracking, the cost at (say) 15c per KwH and how long it takes to pay back the cost of a couple of servos. And at the bigger scale, wind loading becomes the limiting factor. But maybe it can be made to work.
4). Yes to PASM. No to Spin.
5)
That is an interesting article. Just to clarify, I think there is a PC running java.net and acting as the interface. There is code around to do that - I use vb.net but it is not dissimilar to java.net. I also use wireless RS232.
6) word vs byte. Not my area of expertise. Much code on the obex uses "longs" which are 32 bits. Some code possibly over-uses "longs", eg to store "true" or "false", but since this is the native size for the processor it is easier to code that way. In porting code over to C, I am using "unsigned long" as the variable type most of the time - probably not the first variable you would think of using but it makes for easier translation.
7) . I think there is some java somewhere? There certainly is Basic - in many dialects. Propbasic, Interpreted Basic. I'm using BCX Basic at the moment, but in the past I have used SBasic (a language for CP/M that was way ahead of its time, more like C than Basic).
Some BCX basic below (with a bit of inline C). Again, an absolute 100% Spin Free Zone here.
[code]
' Big Basic For external memory on the Propeller using BCX Basic To C converter And Catalina
]
as much as I would love to use a rubidium clock for timing, it's impossible (I am sort of joking, if you know what a rubidium clock is....you will appreciate the humor)
my idea for external clock was an oscillator and a NTP polling program....then a simple comparator for both....a corrector would be beyond the scope of my engineering know how....
there are a few MCU's out there which are more specific to my needs for power, but lose some benefits of propeller
the boost leg or the regulator is for external peripherals....so essentially I will be running a single power source....with multiple buck/boosts (adjustable with a digital pot and pins from prop) stemming from it....the supply for propeller will need to be adjustable dependent on the originator PSU....once fixed it shouldn't be something of concern, but I do like the idea of some control over it's character (without having to solder each time I desire a new value)
the issue of failsafe is something I was hoping to use propr for. A simple relay switch would do. So when Vsense sees a low variable it would just cut the mains....a simple transistor switched relay would be able to do this, and a trimmer should allow me to preset a range....or with a digital trimmer and foldback I could use prop to do that....I would like to avoid TTL
I agree about the issue of the tracker....according to my math it's added harvest is trumped by it's complexity and cost....relatively speaking, unless the engineering is more careful and the cell used is of high quality....the other option I considered was a fresnel lens based solar turbine (but I know of none small enough)
the linked HYDRA project isn't as simple as using a PC as a server....there are implementations of the compiled network stack on board....in the article they said that Java rxtx became unusable, so they adopted .NET (microsoft)....it would be acceptable for me to have to interface my platform with a PC on occasion to synch clock and maybe provide a more substantial GUI for some fun stuff (diagnostics)
I appreciate your feedback, you have been very helpful and understanding....I also appreciate the examples of code....
the more I think about it, the more I can see why SPIN is in place....and also the possible benefits of sticking with it....maybe rewriting my objects is less work than trying to cobble together 3rd. party solutions (one of my original complaints about the prop/spin)
it looks like prop can do what I need, but I am still not convinced it's worth the added trouble (and the "Smile of mate" and "you are out of touch" comments really have me cautious about this community)
I think Potatohead's usage of >= was perfectly valid:
x := 30 + (y >= 5) & 100
returns 130 when y > 5,and 100 otherwise.
It provides a quick way to implement a thermostat:
tooHotfan := temperature >= 79 ' turns on fan when temperature exceeds 79
You might expect true for y=>5, but no, it returns true (-1) when y>5, and false otherwise.
I used to use that kind of thing on the old Tandy 100 BASIC, and was kind of disappointed that PBASIC on the Stamp did not support it. And despite the trap of >= vs =>, I've used it on occasion to keep an expression on one line without use of multiple IFs that would otherwise be required (and admittedly using the IFs would make the code more transparent).
Well Ari, just know there is a very diverse crowd here, and also know that's a very good thing. Again, we've got everybody here from self-taught tinkerers to some people I would easily characterize as doctorate level contributors. Additionally, on the business end there is everything from people selling a few gadgets to the prop community as a whole, to full on enterprises shipping real products.
Consideration due you is simply consideration given. In this, we all are equal, despite our varied experiences.
A safe default is to assume somebody is wanting to help, rather than devalue you, and when that default is in place, we all get along just fine. That's been my general observation after being here a considerable length of time. Others can contribute their observations, if somehow I have that wrong.
A safe secondary default assumption is that most participants in this community are passionate about what they are doing, and to them, it's a big deal. That is simply enough to warrant granting the same consideration expected.
Edit: Ari, I'm bothering to write that for one reason only; namely, the intent to see you get some value out of this community. The more the merrier, and there is a lot of value. Count on it. Lots of us do. If you are here successfully getting that value, the product of those interactions benefit everybody, and that is simply all good.
How much of a rewrite do you have? Is it thousands of lines of code, or a smaller amount? Could be a few well placed discussions would sort out the key things you need to move it to SPIN, PASM, or something else. Also, how fast does it need to run? You might take a look at some of the XMM capable offerings. We've got good support for the better boards, and perhaps you could run the stuff as is, using C. That's the beauty of the Prop. You really aren't locked in, unless the trade-offs involved put something out of scope.
@Tracy, yeah except for I botched "equal to or greater than" 5. It's really just greater than 5, which is the mistake I get caught on regularly... And I guess that answers the Tandy question. I've got a model 100, and a CoCo, both sitting idle right now, because of the Prop, LOL!!!
Comments
Thanks for that Mike....I am also a firm believer that a fundamental problem with modern software (I won't say it by name) is the reliance of bloated code stacked on bloated code....and on a fundamental level I have some serious issues with simply stacking objects (with no basis in understanding them). There is the issue of reality though. I mean why reinvent the wheel, to perform a simple task. If one needs to perform general high level function, I think we would all agree that a modern CPU/computer is far superior. So this is kind of where I am coming from. Why build such a device? This is what really dumbfounds me about SPIN/prop. I can respect the desire and "fun" factor in building from scratch. That is totally illogical though. That is why I can't marry the term "fun" with anything other than a toy. In a truly logical system, fun is not a concern. Only function (no I am not german, bad joke?),
I do understand your points better than the others presented. They are logical, and seem to come from a cold dark place (I mean that as a compliment). Maybe the better term is your rebuttal is blunt and logical? I appreciate it.
So here is a proposal. Is it possible to simply provide a translator for SPIN? I mean something that runs off the prop? I would have no troubles with that (does that exist?). I.E. can I run simple code translations on a fast powerful computer to create SPIN objects? This is not something I can comment on, because I have no knowledge of such a product. My goal is not to spend the necessary tedium on hand coding the kitchen sink. Some minor correction would be acceptable.
I know that migrating assembly into C is possible (in a verrrrry loose sense). Also migrating basically anything under the Sun (another pun) into Java is quite available. This was also my case for NET framework. I guess I am getting lazy with age. I just want to string enough Smile together to get a prototype up and running. I can always go back and lean things out later (I did mention I am more concerned with hardware?)
To me your points about C are quite good. I would be happy with a object translator on a real computer, and then tiny basic on the prop (yes I have a HYDRA)
yeah yeah I know I am probably dreaming again....but I need ways to test hardware quickly....I can't tear down and rewrite every time my hardware evolves (remember that thing I mentioned about being a hardware guy). If it helps I rebuild my desktop system ever few weeks (sickness?). That's never going to change. I do think the open CL implementation from view port is a step in the right direction, maybe others disagree. I would gladly give up cogs and pins to speed up development....by the time my concept is mature, prop 2 will be out anyhow....
hope this isn't off the topic of SPIN too much....I can't see having a discussion about it w/o mentioning all of this stuff....
Ah, that last sentence might be relevant.
Le's take a look at a few of those points because I reckon the prop can do what you need it to do.
1)
not necessarily. PASM and the propeller are married. Spin is an interpreted language that runs in one cog. There other interpreted languages too - eg a version of Basic. heater wrote a Z80 emulator, which also runs on a cog and which replaces Spin. So you are not tied to Spin if you don't like it.
2)
small - yes, some of the packages are so small that if you sneeze and your workshop is a bit messy (like mine!), then bye bye chip. Low power - yes, because you can shut down parts of the chip that are not needed. How many microwatts are we talking?
3)
Maybe we have a misunderstanding here - maybe you mean something different with "common objects". To me, that means things like a uart, keyboard driver, display driver, mouse driver, sd card driver, analog I/O, digital I/O. Are there some specific other things you need?
4) . They are on my board (see link at bottom of post). I wouldn't use anything but a switching regulator, but I admit I am in a minority here. Switchers are perfect for solar applications where the input varies and where watts are precious.
5)
My apologies for misunderstanding your use of the word 'schematic' earlier. To me, a schematic is the wiring diagram of all the chips that go to support the propeller - the power supply etc. But I think you might be using it to mean 'block diagram' of the internal wiring of the chip. If you want the latter, then it does exist, including photographs of the die which nicely illustrates the 8 cogs and the internal ram. However, I am still a bit confused, because knowing all the internal wiring of the chip is not really necessary to build a power supply for the chip. So I still don't quite know what you mean by 'schematic'? More specifically, what do you need to know? Supply voltage (= 3.3V and use a 3.3V regulator, don't try a different voltage), clock (use an external 5Mhz crystal), standard eeprom connection (see various boards). I guess there are the cunning tricks, like how to interface to 5V logic, and the standard stuff like driving a relay, stepper motor, speaker. All of these can be answered with a forum post. Can you describe your project a little more?
6)
You are not the first person to take a look at the propeller and at a new language and nearly walk away. Dare I say it, but this is where others have been in the past, others who went on to write the other languages. Get angry with the situation, then get coding! (or take advantage of all the clever coding already done).
No Spin in this program. Not one line. No spin behind the scenes either. This compiles straight to assembly code. It prints white text on a blue background on a vga monitor.
/* Traditional first C program */ #include <stdio.h> void clearscreen() // white text on dark blue background { int i; for (i=0;i<40;i++) { t_setpos(0,0,i); // move cursor to next line t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100 } } void main () { clearscreen(); printf("Hello, World!\n"); while (1); // Prop reboots on exit from main()! }thank you for this reply....I see you have taken the time to understand my points of concern. That is very generous of you.
I hope I am not taking this thread off topic....I really think i am (that is rude of me and not my MO)
I should create a blog or new thread around this, but I suppose it is very relevant to the original topic? also it is a reborn thread, so i hope we are within the bounds of decency to go down this path?
so is there a simple way to reflash (slang) the chip? I mean are we forever married to PASM and SPIN terp. on chip? I can't see it any other way. Better yet, could i simply build in my language of choice and then translate that to objects the prop could call from a resource pool? the more I play this out in my head, the less reasonable it seems...but what the heck....it's nice to know my options
I actually really like SPIN....it's so well suited to the hardware.....but I can't stomach the idea of writing an object/resource pool from scratch....I mean the word/long thing is odd, but that is really being picky...I do prefer BASIC....but that isn't Java either....and Java would certainly be somewhere off in outer space on prop...
on the issue of size, I have no issues working with surface mount packages....I have the necessary tools and skills....minus BGA....which I have a real problem with (on so many levels)....but the QFP package seems workable....I actually wish prop was available in a 0.3mm package, but I digress
I will address the power restrictions a bit further down....
by common objects I meant my own proprietary objects....which are a blending of a few disciplines and would probably encompass an entire thread to discuss (which I am happy to do at some point)....I am less concerned with basics things, as my objects rely on a deviation from the norm. Especially when it comes to timing and linearity.....but the main points of concern are PWM and clock ref (which I will address further down)
here is my real passion, PSU. I am going to employ a buck boost for my platform. I need to have this functionality, as my power source will be 11.1v or greater. I already have my PSU prototyped, and the numbers are staggering. Suffice it to say that I want to use my own design, for the sake of size and the amount of R&D I have into it. I am an engineer by trade, so this is the part of my concept I am very confident in. I will employ solar to handle stand-by current and nothing more. I want a design with essentially zero draw at idle. I will employ a x-y tilt axis in the small solar cell which will be built into the device case. It will ideally track the optimal collection position throughout it's "up time". This could prove to be an poor concept (how much power will the photo-optical and servo/positional ref take, vs the output from the cell)....I digress.....in terms of microwatts...it is a moving target....but my battery constraints are roughly 800mah at 11.1v (25c) to 2100mah at 11.1v (40c or better)....yes there are peripherals that will pull in excess of 3 AMPs....but only for extremely short periods of time
on the issue of "schematic". I come from an engineering background. So i use the term in the most raw sense possible. This is why I used the term "on die" schematic. I have no use for any data off the chip pins, as i am comfortable engineering that aspect. I do need to know absolute minimums and maximums for pins....especially the drift in pin regulation (PWM, etc.....)....minimum and maximum thermal and moisture....the ambient shift in impedance etc.. etc etc....like I said i need it to be VERY thorough....as I need to operate at absolute MAXIMUM efficiency....every last bit counts
my main concern isn't learning the language.....I am pretty quick with logical operations (currently enrolled in CCNA) and I have yet to see anything as complex and convoluted as IPv4 subnetting. I was able to write my first complex SPIN program in a few hours. It was actually very nice to work with. My main concern is having to rewrite everything I am already sitting on. This is especially complex, as I employ a technique I like to call "program bouncing" or "object chunks"....this is where things get really out of hand....this is also where a highly accurate clock ref. and vREF come into play....a crystal clock is nowhere near accurate enough for my needs....I need to employ a precision oscillator or clock that can poll an NTP server....time is one of the single most critical functions of my concept (at least under the surface)....if the clock was to swing at all, my "chunks" would become non-linear and the data running within that polling cycle would become a problem....and possibly cause a catastrophic failure....this would be devastating if the operation was battery management and I had a runaway overcharge or discharge.....it could lead to explosion....
yeah I know, it's a lot to take in....and I am probably in WAY WAY WAY over my head, but that just makes it more rewarding.....
I suppose one way to avoid the misery of thinking about writing my "chunks" is to just do it....employing a cog or 2 as a resource allocator shouldn't be too much of a concern.....as the platform is not intended for computing purposes or data collection....it's simply a power platform for many different peripherals.....but it must be "smart" enough to govern it's own power consumption...and must equal a self balancing load at idle (that's where the solar harvesting comes into play)....
I am also considering cortex series chips....or a network of PIC's.....but for some reason i have a illogical love for the propeller
thanks for taking the time to listen and for your willingness to give me your input/feedback
The BYTE, WORD nomenclature for 8 and 16 bit data items has been around since the invention of the micro-procrssor and long before that. It is you that is out of touch here.
Take a look at any assembler code for the Intel 8085 for example. Or the PL/M high level language that Intel provided for that chip.
What do you mean by schematic? I cannot think of any mainstream processor vendor that provides schematics of their processors.
Anyone who has been around micro-controllers and real-time systems would no that .NET and Java are not suitable if you want small size and or speed. There is a Java VM for the prop if you want it.
ok, thanks for slinging mud ....
http://en.wikipedia.org/wiki/Word_%28computing%29
as I am sure you know the logical term WORD is not fixed in length, and only takes on an attributable length to stop programming complexity and ingestation of existing code....I am not in any way out of touch
....also why are you regurgitating the ideal that I already stated.....which is that I would ideally like Java or .Net to be an option for a front end....yet I stated NUMEROUS times that I understood that was not an option for my timeframe....are you reading my posts entirely or just being reactionary to the first thing that rubs you wrong? Java is the basis of Arduino IDE, so I am not sure where you are coming from.....also I can link you to an in depth article where computer science students used .NET to implement a network stack into a HYDRA based project for full-duplex communication between 2 units....again an example of what I am illustrating.....you just aren't reading what i write....or trying to understand it....here is that write up
http://itech.fgcu.edu/faculty/zalewski/CEN3213/files/HydraReportESP.pdf
I already explained what an on die schematic is, and I provided a link to a company that provides thousands of such schematics for their products.....once again do you read what i write, or are you just being reactionary towards me on purpose?
you are being rude, and I have not made one single negative comment towards you....why do you feel the need to answer in such a tone?
if you can't be courteous, please don't respond to me....I promise you that it does no good
good day
The chip must not be "reflashed" to use another language than Spin. The code that the language compiler produces goes anyway into the 32kByte MainRAM when it is loaded to the Propeller. In case of Spin a little Interpreter (VM) is started in a cog from the ROM. In case of C (catalina) the VM is integrated in the code and in case of PropBasic you don't need a VM, its pure Assembly code. For sure you can't change PASM it's the native instruction set of the CPU.
There is a C to Spin translater from Dave Hein here: http://forums.parallax.com/showthread.php?119342-CSPIN-A-C-to-Spin-Converter&highlight=SPIN
But you dont have said in what language your existing objects are written.
I hope you are aware of the OBEX. If you talk of your special objects - see above.
For exact timings: Every cog has 2 counters with several modes. They can measure an input pulslength with 12.5ns resolution, count pulses up to 40 MHz or generate output pulses with 12.5ns resolution i.e. for PWM.
.
If this is so important and you don't trust the Propeller pins you can always use well documented external buffers between the pins and your hardware.
Andy
Please don't feed the troll. He'll just keep coming back for more. Oh nooooooooo! I think he's lurking just around the corner. I got to run!
Dave
Yes. In shorter terms, it's the right tool for the right job
I learned programming on a TRS-80, and indeed the Propeller reminds me of this era when you had the possibility of fully understanding your system, from top to bottom.
1) Current consumption. Interesting discussion here http://forums.parallax.com/showthread.php?104293-Minimising-Propeller-Current-Consumption but there may be an issue with your timing - you can drop the consumption by decreasing the clock but that loses timing accuracy. I am not sure about that, but then again, I am not sure of any other micros that could run at better than xtal accuracy with ultra low power consumption.
Re xtal not being accurate enough, are we talking oven controlled xtal? Hmm - that takes energy, and we don't have much of a budget here.
2) What is the boost bit for? Buck will get you to 3.3V but are there some other peripherals we need to know about? Lots of options if there are, especially if they are intermittent. Heck, you could use the prop to turn on a transistor to turn on a relay to turn on a 12V to mains inverter if it was very intermittent.
I use a LM2574 for the 3.3V supply, and a LM2575 for a 5V supply.
3) . I guess you need to think about failsafe mechanisms there - maybe some old-skool supporting electronics with op amps, fets, transistors? Nothing impossible to design here, and indeed, there are some nifty chips around that support micros and detect under voltage, brownouts, deliver a clean reset pulse etc. I've even resorted to latching relays for undervoltage cutout. More recently though, I've found that with solar it is easier to drop in pre-built modules. 10W panel, charger http://www.futurlec.com/Solar_Charge_Controller.shtml and a 7aH gel cell (cheaper as used in bulk by the security industry). Check the data sheet of the charger - under voltage protection, 4 stages of charging, 6mA self consumption. If that isn't what you want, maybe replicate it on the propeller (maybe a second propeller dedicated to power management?)
I've never been entirely convinced about the cost/benefits of trackers - on any scale. Small ones using servos and you have to work out how much power you make by tracking, the cost at (say) 15c per KwH and how long it takes to pay back the cost of a couple of servos. And at the bigger scale, wind loading becomes the limiting factor. But maybe it can be made to work.
4) . Yes to PASM. No to Spin.
5)
That is an interesting article. Just to clarify, I think there is a PC running java.net and acting as the interface. There is code around to do that - I use vb.net but it is not dissimilar to java.net. I also use wireless RS232.
6) word vs byte. Not my area of expertise. Much code on the obex uses "longs" which are 32 bits. Some code possibly over-uses "longs", eg to store "true" or "false", but since this is the native size for the processor it is easier to code that way. In porting code over to C, I am using "unsigned long" as the variable type most of the time - probably not the first variable you would think of using but it makes for easier translation.
7) . I think there is some java somewhere? There certainly is Basic - in many dialects. Propbasic, Interpreted Basic. I'm using BCX Basic at the moment, but in the past I have used SBasic (a language for CP/M that was way ahead of its time, more like C than Basic).
Some BCX basic below (with a bit of inline C). Again, an absolute 100% Spin Free Zone here.
' Big Basic For external memory on the Propeller using BCX Basic To C converter And Catalina #include <stdio.h> #include <stdlib.h> #include <string.h> #include <math.h> #include <ctype.h> #include <errno.h> #include <float.h> #include <inttypes.h> #include <limits.h> '#include <mathconst.h> ' mathconst.h upsets tinyc $COMMAND catalina -lcx -lm -x5 -M 128k -D DRACBLADE -D VGA_HIRES ' library cx, library maths (slow, Doesn't use a cog), memory size, board, high res vga, mouse, keyboard $COMMAND Call WhiteOnBlue Dim a As integer Dim i As integer For a=1 To 3 Print "hello world"; Print a Next a $COMMENT ' file test copied from bcx examples - Files work - commented Out For speed Print "Opening file For output" Dim MyFileHandle@ ' BCX Reserves @ For "C" FILE* Data types Open "new.txt" For OUTPUT AS FP1 MyFileHandle@ = FP1 FPrint MyFileHandle@, "This is a test" Close FP1 Print "Closing file" $COMMENT ' ASC Function Dim Mystring$ As String * 80 ' 80 characters Dim RetVal% Mystring$="A" Print Mystring$ RetVal% = ASC(Mystring$) Print RetVal% 'CHR$ Function - opposite Of ASC a=65 Mystring$=Chr$(a) ' declared in asc Print "Character should be A: ";Mystring$ 'VAL Function - converts string To Double number. From the BCX help file Dim StringNum$ As String * 20 Dim RetDub# StringNum$="3.1415927" RetDub#=Val(StringNum$) Print RetDub# 'STR$ Function - opposite Of VAL. Converts number To string Dim RetStr$ As String * 20 Dim DoubleNumber# DoubleNumber# = 1.23456789 RetStr$ = Str$(DoubleNumber#) Print RetStr$ ' Test some inLine C code - pass a value in myarray, C changes it, Print the return value Dim myarray[5] As integer ' this can be much bigger If you like, eg 50000 myarray[1]=100 Print myarray[1] Call TestCCode Print myarray[1] ' test some string functions Dim lineoftext1$ As String * 80 ' strings must End in $ otherwise compiler Doesn't copy properly Dim lineoftext2$ As String * 80 lineoftext1$="Hello World" ' string name is Case sensitive lineoftext2$=Left$(lineoftext1$,4) ' left characters Print "Left$ test ";lineoftext2$ lineoftext2$=Mid$(lineoftext1$,5,4) ' mid characters Print "Mid$ test ";lineoftext2$ lineoftext2$=ucase$(lineoftext1$) ' upper case Print "Upper Case test ";lineoftext2$ lineoftext2$=Right$(lineoftext1$,3) ' right characters Print "Right$ test ";lineoftext2$ lineoftext1$="Hello" lineoftext2$="World" Concat(lineoftext1$,lineoftext2$) ' add two strings - same as + Or & in vb.net Print "String concat test ";lineoftext1$ lineoftext1$="ABCDEFG" lineoftext2$=lcase$(lineoftext1$) ' lower case Print "Lower Case test ";lineoftext2$ a=1000 lineoftext1$=Hex$(a) ' hex$ working Print lineoftext1$ Dim retval% ' hex2dec = two errors, DWORD (which I think can be changed To unsigned long) And CharLowerA which instr also is unhappy about retval%=hex2dec("0xFFFF") ' reverse Of hex$, can use 0x Or &H syntax Or even FFFF Print "Hex2Dec test ";retval% lineoftext1$="12345abc6789" lineoftext2$="abc" a=Instr(lineoftext1$,lineoftext2$,3,0) ' instr search For characters. Last value is needed, use dummy 0 (matches case) Print "Instr test, string is at position ";a a=255 lineoftext1$=bin$(a) ' test Binary lineoftext1$=lpad$(lineoftext1$,32,48) ' test adding leading zeros with lpad so is always 32 char long Print "Binary value is ";lineoftext1$ ' test Binary To strings And back again lineoftext1$="0000000001010101" Print "Binary string To decimal ";Bin2dec(lineoftext1$) ' Binary lineoftext1$=String$(10,65) Print "String Function ";lineoftext1$' n characters Of ascii value m lineoftext1$=" trim test " ' trim off leading zeros, spaces etc lineoftext1$=trim$(lineoftext1$) Print "Trim test:";lineoftext1$ ' test a string array Dim Stringarray[5] As String * 80 ' 80 characters Stringarray[1]="Hello" Stringarray[2]="World" Print Stringarray[2] ' bitwise operators - there are many more Of these but they all seem To work ok withOut code changes a=1 a=a << 10 Print "bitwise shift left";a a=a >> 4 Print "bitwise shift right";a a=1 a=a And 0xFF Print "logical and";a a=a Or 0xFF Print "logical or";a Print "test starting with a Binary string And shifting"; bin2dec("00000001") << 4 ' test program control Loops - For is already tested above a=1 Do Print a a=a+1 Loop Until a=3 Print "Do Loop finished" a=1 While a <3 Print a Incr(a)' translates To a++ in C Wend Print "Wend Loop finished" a=5 Select Case a Case 1 Print "1" Case > 1 And < 6 Print "more than 1 And less than six" Case Else Print "something Else" End select ' test functions Print addnumbers(5,6) ' test some maths with floating point numbers Dim number1 As Double number1=1.2345 Print number1 Print Sin(number1) Print Log(number1) $CCODE while(1); // Loop instead Of finishing $CCODE ' And exitprocess Does Not work on the propeller. So Don't use End For the moment ' Subroutines And functions Function addnumbers(a As integer, b As integer) Dim returnvalue As uint returnvalue = a + b function=returnvalue End Function Sub TestCCode $CCODE // declare the variables: int nNumber; int *pPointer; // now, give a value To them: nNumber = 15; pPointer = &nNumber; // Print Out the value Of nNumber: printf("nNumber is equal To : %d\n", nNumber); // now, alter nNumber through pPointer: *pPointer = 25; // prove that nNumber has changed as a result Of the above // by Printing its value again: printf("nNumber is equal To : %d\n", nNumber); myarray[1]=110; $CCODE End Sub Sub WhiteOnBlue() ' white text on blue background $CCODE int i; for (i=0;i<40;i++) { t_setpos(0,0,i); // move cursOr To Next line t_color(0,0x08FC); // RRGGBBxx eg dark blue background 00001000 white text 11111100 } $CCODE End Subblink...blink...
Back to school for me, I guess.
I know it would be tedious, but you can read some of the (very long) old threads here on the development of the Propeller including the characterizations that make up the datasheet. This chip was developed very deliberately by essentially one person to fill needs unmet by other microcontroller chips. It's striking that the Propeller has not required the kinds of workarounds and/or revisions that litter the landscape. With the exception of one failure mode from supply overvoltage spikes, the chip has proven to be extremely robust.
Before the days of C and its many derivatives most languages (including BASIC to this day) used >=, <=, <>, and = as comparison operators. I do not use spin (prop asm is much simpler), Though I would think that the case is:
x >= y ' True if x is greater than or equal to y.
x <= y ' True if x is less than or equal to y.
x <> y ' True if x is not equal to y.
As stated I do not use SPIN, as such I may be completely wrong.
The assignment of BOOLEAN to a variable permits making a comparison, and storing the result to be acted on in a future expression, again, without the if-then structure. Generally, a multiply is used to either do something, or not, depending on the result of the comparison. This is one reason why true is -1 on the Prop. Makes that kind of operation easier. The multiply can be replaced with boolean AND. Because all the bits are set, a value can be made active in a expression or not, based on true or false. False is 0, producing 0 after the boolean AND, or true -1, delivers the value after the boolean AND is complete.
It's kind of old school these days, but very similar to how expressions would be done in PASM. I like that SPIN permits this because there is a greater mapping between it and PASM, if the programmer desires.
If Y is greater than, or equal to 5, add 100 to X.
x := x + (y >= 5) & 100
y >= 5 means assign the value true to y if it's greater than 5; otherwise, assign false. I actually used this once. Just once. But, IMO, Spin would be better off without it and the confusion it causes.
-Phil
Yeah, I get that all the time. Smile. Perhaps there is a reason I chose potatohead for a handle, besides the fact that I really liked my "Mr Potatohead" toy as a kid!
The idea is the same though. Let's say Y is used as some accumulator, which will be compared. Doing it with the assignment operator means storing the comparison and performing it all at one time, which sets things up for the logical AND to follow. Could also be several logical AND operations too, with Y carried over from one to the next. I still see it as being similar to how things would be done in PASM.
So then:
Y := x + z * 3 'Perform transient computation
Y >= 5 'evaluate and store comparison result
a := a + Y & 50 'add 50 to A on result = TRUE
b := b + Y & 48 'add 48 to B on result = TRUE
carry on...
That construct can be more efficient in spin than the if - then constructs are, and it runs in a consistent amount of time, again the parallel to PASM can be seen, IMHO.
Thanks Phil, for once again, digging me outta the SPIN trap. It's a common trap for me, because it reads in such a tempting way, LOL!!
Re: Better off. Maybe! I deffo see your point, because I have been caught by that multiple times. But... I'm kind of in the UNIX camp, so that means give me the tools to get into trouble. I'll get into trouble, and be sorry for it, but I'll also do great things too! Over time, the great things will trump the trouble.
BTW: I think my expression in the post above works, with the comparison left in Y, for subsequent operations to follow. Not at a prop right now though.
I've used it in a form similar to the above sometimes, as well as in CON sections, where the sequential processing doesn't allow for decisions without using these kinds of constructs. It's then possible to have conditional constants, which is of value, IMHO.
If TRUE was simply 1 and not -1, then a multiply would be required for the conditional math. Props have no multiply. Maybe somebody can remember to ask Chip about this at the next get together. I've often wondered about why TRUE was -1. I think these kinds of constructs are the reason, but it would be great to hear what Chip was thinking at the time.
-Phil
-Phil
I will start a blog about my concept of "program bouncing" and "chunks"....please be patient with me for a couple of days to get a technical description put together....I would like to illustrate a unique concept for parallel processing of small objects....that equal an output value of one large nested object....
you could consider this multi-threaded or parallel, but neither is a correct description of the actions at play....
the problem with my process/concept lies in timing and collective allocation/pool of the "chunks"
I am probably just duplicating something very common, or at least conceptualized, by other process....but for me to accomplish tasks in an environment which i have limited experience (prop/SPIN) it's what I have to resort to....maybe someone can shed light on the topic once I properly describe it
and it will possibly be back to school for me as well.....I think (in this case) my own naivety could lead to a larger benefit for others (once everything has been properly sussed out)
Mike you touch on some specific areas of interest. The detailed i/o block schematic (including complete thermal, and current deviations) would be most helpful.
I have no real use for schematics of any "legs" of the chip beyond there.....as you said, that would not be very useful....since i can't do much about interacting with those structures (unless you have access to a "shrink ray")
thanks for that Andy,
I see, from your description that the terp. is what it is....and I have no issue with that (I suppose) since each hardware discipline relies on a native instruction set....I would love to know more about how PASM translates it's code to physical topologies (for purely academic reasons)....but I understand that we are married to PASM, and the on chip terp. (you have helped clarify that for me, so thanks)
I would have a look at Mr. Heins translator, but I fear it would vanish into thin air....since his accusation is that I am somehow "trolling" (it's a joke Mr. Hein, I am not a troll here)
I have looked at most of the OBEX offerings, and I think it would be pretty easy to deconstruct those objects into usable "chunks" (I know I need to describe that better). I hope everyone offering those objects is open to their modification and inclusion in new/unique code?
the use of external "buffers" would be possible, but impractical, if the prop already is within acceptable ranges. Size is a really big (pun?) concern....and when I say small....I mean small....
thanks again for responding Andy....I especially appreciate the clarification about the on board terp.
:blank:
7.5 us....it's not acceptable....but I can include an offset for this at the beginning of each "initiator"...
This is where PASM could be handy for me....the allocator could be a residual in centralized memory
am I replying to something that was even directed at me? If not then apologies....
BTW, Parallax does have a "shrink ray" in the form of an electron beam probe that was used to debug the Prop. You might read "Why the Propeller Works" here if you haven't already.
I don't understand how the "allocator" could reside in central memory. The only place things are executed is in the COG space. Everything else must either be fetched into the COG, using a HUB operation (LMM), or pins (XMM), or interpreted byte code style (SPIN, others...). Unless that allocator is really just one COG acting as the control COG, which is probably what you meant.
As for the code in the OBEX, it's MIT, so do what you will, but also do consider contributing back to the pool for others. That's the default expectation with the OBEX and the code found there.
You can shave some time off the COG init time with a higher clock. The reference clock is 80Mhz, but our shared experience basically shows Propellers running nicely at 100Mhz.
Just talking Prop stuff. That's what we do. Not a challenge, or anything else. You will find this group kind of synergistic that way. It's natural for people to toss in what they know, because there is a lot of interesting things to know, that might not be obvious at first glance, compared to a more traditional CPU. That's all.
In particular, the idea that programs only execute in the COG memory space is worth noting. It's missed by a lot of people new to the Prop, as is the init time. One of the most common misunderstandings is that HUB / COG relationship, with the idea that the COG executes directly from the HUB, which is why I wrote what I did just now.
as much as I would love to use a rubidium clock for timing, it's impossible (I am sort of joking, if you know what a rubidium clock is....you will appreciate the humor)
my idea for external clock was an oscillator and a NTP polling program....then a simple comparator for both....a corrector would be beyond the scope of my engineering know how....
there are a few MCU's out there which are more specific to my needs for power, but lose some benefits of propeller
the boost leg or the regulator is for external peripherals....so essentially I will be running a single power source....with multiple buck/boosts (adjustable with a digital pot and pins from prop) stemming from it....the supply for propeller will need to be adjustable dependent on the originator PSU....once fixed it shouldn't be something of concern, but I do like the idea of some control over it's character (without having to solder each time I desire a new value)
the issue of failsafe is something I was hoping to use propr for. A simple relay switch would do. So when Vsense sees a low variable it would just cut the mains....a simple transistor switched relay would be able to do this, and a trimmer should allow me to preset a range....or with a digital trimmer and foldback I could use prop to do that....I would like to avoid TTL
I agree about the issue of the tracker....according to my math it's added harvest is trumped by it's complexity and cost....relatively speaking, unless the engineering is more careful and the cell used is of high quality....the other option I considered was a fresnel lens based solar turbine (but I know of none small enough)
the linked HYDRA project isn't as simple as using a PC as a server....there are implementations of the compiled network stack on board....in the article they said that Java rxtx became unusable, so they adopted .NET (microsoft)....it would be acceptable for me to have to interface my platform with a PC on occasion to synch clock and maybe provide a more substantial GUI for some fun stuff (diagnostics)
the device platform will have an on-board oLED display.....(samsung VGA) and it will be another hurdle in itself to implement....so it's low on the list....but here are the specs for it's driver chip
http://www.egochina.net.cn/e-shop/ebay/Datasheet/S6E63D6_SAMSUNG_4163372.pdf
I appreciate your feedback, you have been very helpful and understanding....I also appreciate the examples of code....
the more I think about it, the more I can see why SPIN is in place....and also the possible benefits of sticking with it....maybe rewriting my objects is less work than trying to cobble together 3rd. party solutions (one of my original complaints about the prop/spin)
it looks like prop can do what I need, but I am still not convinced it's worth the added trouble (and the "Smile of mate" and "you are out of touch" comments really have me cautious about this community)
I think Potatohead's usage of >= was perfectly valid:
x := 30 + (y >= 5) & 100
returns 130 when y > 5,and 100 otherwise.
It provides a quick way to implement a thermostat:
tooHotfan := temperature >= 79 ' turns on fan when temperature exceeds 79
You might expect true for y=>5, but no, it returns true (-1) when y>5, and false otherwise.
I used to use that kind of thing on the old Tandy 100 BASIC, and was kind of disappointed that PBASIC on the Stamp did not support it. And despite the trap of >= vs =>, I've used it on occasion to keep an expression on one line without use of multiple IFs that would otherwise be required (and admittedly using the IFs would make the code more transparent).
Well Ari, just know there is a very diverse crowd here, and also know that's a very good thing. Again, we've got everybody here from self-taught tinkerers to some people I would easily characterize as doctorate level contributors. Additionally, on the business end there is everything from people selling a few gadgets to the prop community as a whole, to full on enterprises shipping real products.
Consideration due you is simply consideration given. In this, we all are equal, despite our varied experiences.
A safe default is to assume somebody is wanting to help, rather than devalue you, and when that default is in place, we all get along just fine. That's been my general observation after being here a considerable length of time. Others can contribute their observations, if somehow I have that wrong.
A safe secondary default assumption is that most participants in this community are passionate about what they are doing, and to them, it's a big deal. That is simply enough to warrant granting the same consideration expected.
Edit: Ari, I'm bothering to write that for one reason only; namely, the intent to see you get some value out of this community. The more the merrier, and there is a lot of value. Count on it. Lots of us do. If you are here successfully getting that value, the product of those interactions benefit everybody, and that is simply all good.
How much of a rewrite do you have? Is it thousands of lines of code, or a smaller amount? Could be a few well placed discussions would sort out the key things you need to move it to SPIN, PASM, or something else. Also, how fast does it need to run? You might take a look at some of the XMM capable offerings. We've got good support for the better boards, and perhaps you could run the stuff as is, using C. That's the beauty of the Prop. You really aren't locked in, unless the trade-offs involved put something out of scope.
@Tracy, yeah except for I botched "equal to or greater than" 5. It's really just greater than 5, which is the mistake I get caught on regularly... And I guess that answers the Tandy question. I've got a model 100, and a CoCo, both sitting idle right now, because of the Prop, LOL!!!