Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Electrical (http://www.chiefdelphi.com/forums/forumdisplay.php?f=53)
-   -   Driver station power (http://www.chiefdelphi.com/forums/showthread.php?t=118330)

yash101 20-11-2013 22:17

Re: Driver station power
 
BTW, for the propeller, I came up with a nifty idea:
To write a Java interpreter, compiler and kernel to be installed to the propeller. This kernel would fetch instructions from an SD card, parts at a time, allowing a large code. Also, the compiler would convert the code to bytecode to run efficiently on the propeller. I am pretty sure that a 128 MB card will be enough to hold Google's Search Engine Code (Not their database or their other services).

I think there are some practical uses for something like this, as it would allow you to access the inaccessible features on the Propeller!

Also, how can I add more RAM for variable space on the propeller? I would like all the user variables to be in an external RAM of 16Mbit, meaning that they do not need to worry about RAM.

The only thing this may not be able to do is image processing (Or maybe it can).

techhelpbb 20-11-2013 23:25

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1303963)
BTW, for the propeller, I came up with a nifty idea:
To write a Java interpreter, compiler and kernel to be installed to the propeller. This kernel would fetch instructions from an SD card, parts at a time, allowing a large code. Also, the compiler would convert the code to bytecode to run efficiently on the propeller. I am pretty sure that a 128 MB card will be enough to hold Google's Search Engine Code (Not their database or their other services).

I think there are some practical uses for something like this, as it would allow you to access the inaccessible features on the Propeller!

Also, how can I add more RAM for variable space on the propeller? I would like all the user variables to be in an external RAM of 16Mbit, meaning that they do not need to worry about RAM.

The only thing this may not be able to do is image processing (Or maybe it can).

Let's break this idea into smaller parts.

There is already a stub you can put into a Propeller Cog that will load program and variables from the Hub memory. At the cost of waiting for the round-robin Hub mechanism.

One could load the Hub memory via Cog(s) to contain segments of code and variables interchanged from some of the remaining Cogs then sent back and forth to external memory or devices.

The price you pay for this from the perspective of any single otherwise unassigned Cog is waiting for the Hub mechanism to move data into the shared memory. Waiting for the Hub mechanism to give access to the Cogs that transact the data with the external devices. However let us not underestimate that the greatest delay will be to get the data into and out of the I/O pins on the Propeller to whatever else is out there.

This is no different than the way I created a control system as a network of interconnected Propellers. The greatest delay is at the I/O to the other chips (other Propellers, memory, sidecars...whatever they might be). You can cheat some. You can use more than 1 bit at a time. Making a parallel communications bus. You can make the transactions synchronous eliminating slow asynchronous timing issues. If you do this right you can pump data fast...but still not as fast as what you can do inside the Propeller itself.

The point: ideally you want to avoid moving data external to the Propeller for any purpose where speed is critical. In those cases you are far better off say: consuming 7 Cogs for a purpose, confining the process to those Cogs and then using the left over Cog to spew less critical communications to the rest of the system.

It would be ideal if there was a massive amount of Hub shared memory. Then again that is static memory. Most PCs use dynamic memory which is effectively slower and more tricky because large quantities of static RAM would get expensive. I hesitate to say just what the perfect balance here is. Even x86 CPU pay dearly in performance when they reach outside to access the system RAM. That's why the CPU cache is so important. So think of the shared Hub memory as a shared CPU cache. As most modern CPU are actually running a program you can't alter called microcode there's further similarity there to be explored. The loss created by the external I/O does come at a price but it's a price common to other computing designs as well. The massive difference in favor of the Propeller is that you can control aspects of the cost for the external access (add more bits to the bus, compress data, change the segmentation, alter the timing) something there are very real limits on in other architectures as they are more general purpose oriented (you can be great at one thing or mediocre at lots of things).

yash101 21-11-2013 13:04

Re: Driver station power
 
So, could I add a memory buffer method to create a variable in the Built-in RAM, and use that for high speed access? That way, the variable is copied into the internal RAM. The hub can then access the ram quickly

techhelpbb 21-11-2013 13:31

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1304130)
So, could I add a memory buffer method to create a variable in the Built-in RAM, and use that for high speed access? That way, the variable is copied into the internal RAM. The hub can then access the ram quickly

I think this might be beneficial to read:
http://propeller.wikispaces.com/Large+Memory+Model
That assembly code not just copies data from the Hub RAM, that data is actually executable code.
Just data is by comparison pretty simple.

Basically you want to move the private performance critical variables into the internal Cog RAM (not to be confused with internal to the Propeller chip) for the highest speed.

Public performance critical variables within a Cog need to get that Cog to 'export' them into the Hub shared RAM and anything in the Hub shared RAM needs to get a Cog to import it.

The difference between private and public here is important and differs slightly from the way those terms are often used, so I will explain:

A private variable rarely needs to be exposed to the Hub at all so it gets maximum performance.
A public variable is probably being often exchanged with the Hub.
(Who decided on the names public and private in this context? I just did it's part of some code I already wrote.)
To make things easy to see you should group your private variables together within the Cog. The same with the public variables.
Then you can code an 'export' function to periodically take the public variables that are grouped together and move it as a segment sequentially into the Hub (if you think about this these grouped variables are effectively what assembler programmers refer to as a stack so you have multiple stacks being copied as segment to the Hub shared memory at time intervals dictated either by a timer or loop execution).
One might need to have some of the public segment more frequently update than others so if that is desired group the public variables together based on update frequency. The key is to keep the variables together to keep the operations sequential (making the loops simple increments).

This is a software imposed version of memory management for the < 500 longs of memory within each Cog. You pay for it in the performance of each Cog the instant you make anything public (because something has to steal Cog processing time to move the data). However once you design the system you can clone it over and over for each Cog.
This sounds complicated but even in straight assembler it is short.

The highest performance can be demanded from a Cog that never interacts with the Hub round-robin mechanism.
The more the Cog interacts with the Hub the more performance you loose to that interaction.
So if you are setting aside time to move 20 longs to the Hub shared memory: what I described can be done really fast at each opportunity without missing any opportunity, or setup interleaved into other timing critical operations and still be understandable if you need to debug it.

yash101 22-11-2013 15:49

Re: Driver station power
 
That makes sense because the hub is the bottleneck! The hub isn't too fast and is serving so many cogs that there are very few times where the hub will be able to be used well! That's like my computer, where the hard drive (SSD) gets a seven, but the processor gets a three, causing my computer to be veerry slow!

techhelpbb 22-11-2013 16:30

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1304601)
That makes sense because the hub is the bottleneck! The hub isn't too fast and is serving so many cogs that there are very few times where the hub will be able to be used well! That's like my computer, where the hard drive (SSD) gets a seven, but the processor gets a three, causing my computer to be veerry slow!

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.

yash101 22-11-2013 18:34

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!

techhelpbb 22-11-2013 19:14

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1304647)
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!

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.

yash101 22-11-2013 22:09

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!

yash101 22-11-2013 22:17

Re: Driver station power
 
Quote:

Originally Posted by daniel_dsouza (Post 1286650)
you could also use a computer that has the same power requirements as the classmate.

Our Lenovo x61 laptop-tablet computer has a power adapter that uses the same connection just before the power brick.

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!

techhelpbb 26-11-2013 11:04

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1304757)
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!

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.

yash101 27-11-2013 11:29

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!

techhelpbb 27-11-2013 12:20

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1306470)
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!

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

yash101 27-11-2013 12:33

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

techhelpbb 27-11-2013 13:32

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1306494)
I did not know about that! That is basically what I am talking about! :D

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.

Alan Anderson 29-11-2013 11:04

Re: Driver station power
 
Quote:

Originally Posted by yash101 (Post 1306494)
However, my main intention of this is to create a language for the Propeller that is more standardized.

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

Jim Wilks 29-11-2013 12:38

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.

yash101 29-11-2013 16:23

Re: Driver station power
 
Yeah. That's a good point!

yash101 29-11-2013 16:25

Re: Driver station power
 
Quote:

Originally Posted by Alan Anderson (Post 1307028)
I don't understand your goal. Please explain what you mean by "more standardized".

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!

Alan Anderson 29-11-2013 23:31

Re: Driver station power
 
Quote:

Originally Posted by Alan Anderson (Post 1307028)
Please explain what you mean by "more standardized".

Quote:

Originally Posted by yash101 (Post 1307063)
A more widely used language, like Java.

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.

yash101 30-11-2013 01:29

Re: Driver station power
 
I was thinking about making a Java interpretter for the Propeller Chip. Now, I am not so interested anymore because Brian (Techhelpbb), pointed out to me that it already exists, fully developed!


All times are GMT -5. The time now is 16:16.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi