Re: Driver station power
 

Correct. If you then extend that to using external resources that's an even deeper bottleneck for the Propeller.

However the problem is not horrible. The nature of the Propeller Hub mechanism is such that every Cog gets a fair chance at access to the Hub. Even if a Cog might wait 8 clock cycles to get that chance. For an environment where code might not be stable that unalterable Hub behavior is a great way to stop a hung Cog from stopping other Cogs.

So the nice part is that unlike a single processor or SMP computer you can create a single tight process in the Cogs and not have to worry about random interrupts and task scheduling. You can do task scheduling if you want but it's entirely optional. As a result one can create some impressive artificial peripherals inside the Propeller. Hooking up a monitor to a microcontroller without a real interface even with limited colors is a pretty neat trick and the timing to make it work would be difficult to work out if not for the design of the Propeller itself. The Propeller can not just do that but the left over Cogs can be sent off on other tasks. It's really quite possible to divide up the Cogs and the Hub shared memory between different people's work even within a single Propeller let alone many.

It's very much like how mainframes work and large enterprise networks of computers.

Re: Driver station power
 

I believe that is the main point of the Propeller! Dedicate an entire core to graphics, audio and other things! That stuff is impossible to do with the BASIC stamp! Also, the great speed makes the Propeller suitable for more than just basic computing and running a robot. You can use the power of the processor to create a web interface, or something else.

I remember when I was using a sweeping Ping to do obstacle avoidance on a BASIC stamp. The robot would stop still while it was detecting obstacles and then start back up afterwards. Now, I can have the chip driving the motors while doing the sensors, all at the same time.

I program my Propeller in C. I really like it because it is easier to program than BASIC. The problem in BASIC is that the lack of a god syntax makes it harder to efficiently code a program, and even harder to debug it!

Re: Driver station power
 

PBASIC is really a slightly tweaked version of BASIC. I think BASIC gets a very undeserved bad reputation. I've been writing code in one flavor of BASIC or another for everything from robotics (MegaBASIC, TinyBASIC, PBASIC, PICBASIC Pro, BASCOM-AVR, MikroBASIC) to very important business applications for decades. How important? Important enough to change the world's economy.

It's just another language. Every so often someone decides they've got a better idea and they write up a whole new language. I've worked in so many programming languages now I can hardly remember all their names. Especially with BASIC. Sometimes the justification for the rewrite is to target functionality that someone else does not value. Fine but in reality after you program long enough the whole language of the moment issue becomes quite secondary to whether the language in question is the fastest and most suitable way to achieve something.

I am often confronted by people that have not a clue about a modern version of BASIC but they assume it's no different than say GW-BASIC. BASIC was at one point even Microsoft's answer to the operating system of choice for the Commodore 64/128 family of computers.

I think it's been years since I've seen someone use a GOTO statement which was one of the very concepts that gave BASIC the reputation for disorganized code. However it's funny to note that the concept for the GOTO statement is very much the assembly language jump. Since it's not uncommon for compiled languages to produce assembly language it's not like the concept went away.

The point is not that BASIC is superior.
It's just another option to be explored.

To see the real power of what BASIC can do consider that at one time Microsoft's sales of VisualBASIC were enormous till they changed the syntax and effectively made dysfunctional huge numbers of 3rd party tools in the latest version. I still find VB6 16bit code out in the wild today and effectively that's the model for Microsoft Office's VisualBASIC for Applications which is still alive and well today. I wrote 12 macros this week alone in Excel using VBA. There are Excel APIs and tool kits throughout the financial industry today that can trace their roots back to me and VBA.

That said if you wanna make a living programming it's hard to ignore: C, C++, Java, Perl, Python, .NET

Spin looks a lot like PBASIC but really because of the differences from the PIC to the Propeller it's another BASIC-like language.

Re: Driver station power
 

BASIC is a very good language. As a matter of fact, I do most of my programming in either C or VBASIC! It is nearly plain English! However, it is hard to write long programs in BASIC without making it too confusing.

The revolutionary language would be when:
To drive a motor:
change [motor name] speed to [high/8 bit integer]
To turn on an LED:
turn on [led name]
To do a complex calculation:
[variable name] equals the (square root of 64 plus 8) divided by two

You probably get the gist of it. Preserve all grammar and make it so that pseudocode is the actual code :D. That would be the end of programming language development, especially when we get it to run directly on the processor hardware like assembler!

Re: Driver station power
 

If you want to get very fancy, you could get some sort of x86 dev board, install windows on it and run the computer off 5 volts, from an UBEC! That can also be a feasible solution!

Re: Driver station power
 

Interesting because I wrote a language just like that using the Propeller.
I pointed it out elsewhere.

The idea being that you'd put say: the drive train on one Propeller, the end-effector on another Propeller, some important autonomous systems on a 3rd Propeller.

Then send instructions to say the drive train like:
"Move the front right wheel 2 revolutions."

How does it work?
The string processing knows to expect strings like:
"Move the X wheel Y Z."
The string matching is a bit fuzzy to allow for some minor errors.
So X could be the words: front right, front left, rear right, read left.
Y is the magnitude.
Z are the words: RPM or revolutions (case insensitive).

If you think about this it is now really simple to understand natural language in the exact same way that old instruction based games would do so.

Parse down the natural language to get the relevant details and call the necessary code. That's it.
You can now talk in your natural language of choice to the robot parts.

This works really well on the Parallax Propeller because the Cogs all run separately so a Cog can parse strings at the input and send only the relevant instructions to the Hub shared memory to act upon. So whole strings become simple short numeric variables in the Hub shared memory.

Does this mean the language runs at the same level as assembler?
Not at all and unless you embed a natural language processing system into the hardware it won't. Though with an FPGA this is obviously quite possible and it could still be programmed like microcode. Even the Propeller doesn't have the hardware for this because it is a niche case of design.

There is a high degree of similarity here between voice recognition and some of the algorithms needed for natural language processing.

As a result of using a library to perform floating point calculations on the 1st generation Propeller in effect I am already performing your mathematical calculation as well. It parses the string with the equation, calls the relevant functions in the proper order of operations. When I was in high school I could not see the sense in buying a TI-82 which at the time was very expensive. I already had a Zenith 8086 laptop from my family business work and it was worth thousands with a CGA style display. So I wrote in BASIC a graphing calculator. The teachers did not appreciate that it could show you the work as it worked. Later in college I wrote a program on the TI-85 to do Fourier transforms that could also show the work because at the time only much more expensive HP calculators had the built-in software. It was quite interesting to work with the teacher to address some of the issues in the program logic. I actually think I retained more about the math like that than by doing it by hand.

To put this in historical context I used a programming language called RCL (Robot Control Language) in Mount Olive High School on an RB5X robot. It was a Forth based language that used the structure of the Forth language to create natural language processing for the robot. For example if you had a working arm: "Move elbow 5 degrees". Would move the elbow 5 degrees. How it did that depended on how it was setup. Maybe it had actual feedback or maybe not. So that's a language back from the late 70s and 1980s that could do this. I have an RB5X robot in my garage I am in the process of parting back together with the arm.

In the end though natural language processing is an abstraction. In the same way LabView is an abstraction. You still need to learn how to structure the code or no matter how simple the dialect you won't get the results you expect.

Re: Driver station power
 

What I mean is actually writing an interpretter, so that you can program a propeller chip in Java. Also, with this being an interpretter, it seems as though you will be able to program the propeller from within itself! You would just need to write code and the memory chip would do the rest!

Re: Driver station power
 

SPIN is already a byte code interpreter embedded in the default Propeller and offering a BASIC-like syntax.

Not only can this actually be done, but if you had enough support and the code was optimized enough you could ask Parallax to put it in the actual Propeller as a custom version. Then the custom chips would ship with the Java interpreter.

Without making a custom Propeller you could start off with an assembly language stub to get the Cogs to read from the Hub shared memory as fast as possible for the variables, page code into the Cogs from the Hub shared memory and another assembler program that occupies a Cog for external communication. With that as a framework you can then build basically a JVM optimized for the purpose. Actually at that point you can write any interpreter you really like. You'll need to extend Java to fully make it possible to lock code to specific resources (make a custom threading system that understands more about this architecture).

I am curious do you know about this:
http://propeller.wikispaces.com/Programming+in+Java

Re: Driver station power
 

Yeah. However, my main intention of this is to create a language for the Propeller that is more standardized. I also program on ARM (Raspberry Pi). I use C on there. The only platform that I know uses SPIN is the Propeller. That means that to use the Propeller platform, you must learn a completely new language. That is the reason why I still struggle with SPIN. BASIC is a non-standard language, but there is an implementation of that language on every platform, making it more useable.

Also, creating a Display with the Propeller is easier than it is on different platforms, but is still quite hard, especially if you are programming in Assembly. With a language like this, I could integrate the basics of the SWING package, giving a display toolkit that most users would already be used to!

Some other features that would be nice would be a set of classes, to interface chips like the MCP3204, etc. so that it seems as though that chip's function is build into the Propeller. This class would initialize the chips and have functions to integrate directly!

I did not know about that! That is basically what I am talking about! :D

Re: Driver station power
 

The thing about most of the Propeller langauge ports is that they often don't start from a common foundation. So while that is an implementation of Java with the Propeller as a target it does not necessarily implement all the features we've been going back and forth (Forth :)) about.

Consistency between implementations is an issue. However that issue exists throughout the computing world.

Re: Driver station power
 

I don't understand your goal. Please explain what you mean by "more standardized".

Re: Driver station power
 

What does any of this current discussion have to do with the topic Driver Station Power???

Start a new thread in the appropriate section.

Re: Driver station power
 

Yeah. That's a good point!

Re: Driver station power
 

A more widely used language, like Java. Ask a programmer if he knows SPIN. He will most likely say no. Ask a programmer if he knows Java. He will possible say yes, under most circumstances!

Re: Driver station power
 

Okay. I was confused by your expressed desire to "create" something. It looked to me like you wanted to make a new language, but that's at odds with using something standard.