Hello Leon, just to stay a bit aside of you. I really can understand what you say, see the relevance of your arguments and can follow. Indeed, a lot of my coworkers share this opinion. OK, that creates a lot of troubles and headaches to me.
We all here are amateurs and we SPEND money working with the propeller. The UPE are full of those, they even pay to go there, book hotels, have a great time. So, having a cheaper controller: what for? My pleasure is to give propellers away for free. To share the joy I find. Being used to work with gates, starting to make a CPU from gates, I went the way to 8080, Z80, 8051, Z8, Transputers, ... and I finally gave up! Nothing to do what others not had done already, but no longer able to run a V.24 communication line. Then, by lucky accident I found the propeller. All my knowlegde on what to do and NOT to do I could use, having this chip. So let me ask one question: if you make your money with low cost chips, what brings you to here. I have to say: I made my money with low cost solutions, but only the propeller gave me the chance to develop such an solution.
Now to ANN: a lot of research work is done on this field, but I am not aware of any useful product. It might be of academical interest. In this case the performance and realtime behavior is not relevant, so is the price point. But if whenever someone finds the solution to a real problem in form of an ANN, like autonomous housekeeping, and he can show, that this really works, he can raise the funds necessary to make an affordable solution. So my hope is, he needs about 64 analog inputs. And then Prop][ will be unbeatable, because the great designer just decided: I know how to make a multipurpose I/O-Pin, so let there be 64 of them, why not!
And now some words to this great forum: I had used FFT for years and then not for decades. Only the forum here and the discussion on why a FFT works gave me the insight into a very simple relationsship and why a complex number is not a vector. So even if others didn't follow, to me something became clear. That is what you can not count in $.
I do not say, I could not have got such in result in an other place. But: in such a place I can not read about blinking a LED, drive a robot, or share my knowledge in another field, what I sadly do not often enough.
And, not to be misunderstood: we need Leons comments and contributions. I at least feel triggered to write down my positive experience.
ErNa
I actually like the Propeller, and enjoy playing about with it, in common with many other devices; some of them are far more powerful than the Propeller. I'm more interested in the Propeller II, though, which is the main reason why I hang out here.
Now to ANN: a lot of research work is done on this field, but I am not aware of any useful product. It might be of academical interest. ... he needs about 64 analog inputs. And then Prop][ will be unbeatable, because the great designer just decided: I know how to make a multipurpose I/O-Pin, so let there be 64 of them, why not! ... we need Leons comments and contributions. ....
This ANN is getting me interested. The multiprop support I am testing allows as many props as needed to be linked together to provide as many pins and as many chunks of 32k RAM as needed costing three resistors and one capacitor per prop. Also, the SD support I am testing gives me 8 Gig of SD that I can use as expanded RAM (sort of).
What is a demo that I can make to show ANN on the prop or another micro controler? If number of I/O pins and amount of memory are the only obstacles, assume these are solved, or the demo is not to be specific to a particular micro controller.
Can the forum participant create a straightforward ANN example we can code?
Implement the standard back-propagation algorithm and see if you can use it to solve the classic XOR problem. It can't be done without a hidden layer. Don't bother about efficiency at this stage, use floating-point.
Interrupts have their place. When done right and used right they don't complicate things, they simplify things. It does depend a bit on the architecture of course - not all of them makes the most sense everywhere. As for speed, a 16-bit minicomputer I worked with from 1982 had a full set of registers for all of the 16 interrupt levels (and handling priorities between interrupt levels was also done very efficiently). An interrupt simply switched to a fully operating set of registers, including internal registers used by the microcode. Switching to another interrupt level and continuing execution there took 1.7 microseconds, not bad for an architecture which was introduced in 1974.
Later versions of the computer introduced in 1979 was slightly slower to switch levels because the register sets weren't executable, just a set copied from a fast register file: The switch took 5 microseconds. But the CPU was much faster than the earlier version so the price was worth it for most purposes. The interrupt handling was so fast (for the period's requirements) that for a 5-channel I/O board we needed just 2KB of fifo on-board while when we moved the whole thing to a Sun computer around 1990-1991 we had to install 8MB of fifo in the new hardware to keep up.
Parallel processors like in the Propeller also have their place, in a way it's like working with thread programming.. and with the same possibilities for doing it wrong, of course. Threads, when done right, can reduce a complicated program to a very simple thing. Just think of a serial terminal emulator: With threads it's the easiest thing in the world to program: One thread sits and listens to the keyboard input, writes what it receives to the serial output. Another thread listens to the serial input, writes the output to the screen. Very little code. Then there are those who try to split everything into threads because it's fashionable.. or at least it used to be, just a few years back. There was a lot of horrible messy code back then.
A blinking LED certainly gets the point across. However, a traffic light, with each light run by a different cog, would get the point across even further, showing a rudimentary application in parallelism.
Lesson 5 for the QuickStart http://www.parallaxsemiconductor.com/quickstart5
The lessons are short so you get to that point about 10 minutes after starting your first tries with the propeller, which I did only recently. Lovely stuff!
I don't think I have ever said anything like that, it's just that there are many ways of doing things and some are better than others. I've been involved with computing on and off since 1961, and I've seen it all before.
Here is the backprop code for a facial recognition ANN application developed at CMU. I've built the whole thing with gcc and it seemed to work OK when I tested it. I can supply the whole program if anyone is interested.
/*
******************************************************************
* HISTORY
* 15-Oct-94 Jeff Shufelt (js), Carnegie Mellon University
* Prepared for 15-681, Fall 1994.
*
******************************************************************
*/
#include <stdio.h>
#include <backprop.h>
#include <math.h>
#define ABS(x) (((x) > 0.0) ? (x) : (-(x)))
#define fastcopy(to,from,len)\
{\
register char *_to,*_from;\
register int _i,_l;\
_to = (char *)(to);\
_from = (char *)(from);\
_l = (len);\
for (_i = 0; _i < _l; _i++) *_to++ = *_from++;\
}
/*** Return random number between 0.0 and 1.0 ***/
double drnd()
{
return ((double) random() / (double) BIGRND);
}
/*** Return random number between -1.0 and 1.0 ***/
double dpn1()
{
return ((drnd() * 2.0) - 1.0);
}
/*** The squashing function. Currently, it's a sigmoid. ***/
double squash(x)
double x;
{
return (1.0 / (1.0 + exp(-x)));
}
/*** Allocate 1d array of doubles ***/
double *alloc_1d_dbl(n)
int n;
{
double *new;
new = (double *) malloc ((unsigned) (n * sizeof (double)));
if (new == NULL) {
printf("ALLOC_1D_DBL: Couldn't allocate array of doubles\n");
return (NULL);
}
return (new);
}
/*** Allocate 2d array of doubles ***/
double **alloc_2d_dbl(m, n)
int m, n;
{
int i;
double **new;
new = (double **) malloc ((unsigned) (m * sizeof (double *)));
if (new == NULL) {
printf("ALLOC_2D_DBL: Couldn't allocate array of dbl ptrs\n");
return (NULL);
}
for (i = 0; i < m; i++) {
new[i] = alloc_1d_dbl(n);
}
return (new);
}
bpnn_randomize_weights(w, m, n)
double **w;
int m, n;
{
int i, j;
for (i = 0; i <= m; i++) {
for (j = 0; j <= n; j++) {
w[i][j] = dpn1();
}
}
}
bpnn_zero_weights(w, m, n)
double **w;
int m, n;
{
int i, j;
for (i = 0; i <= m; i++) {
for (j = 0; j <= n; j++) {
w[i][j] = 0.0;
}
}
}
void bpnn_initialize(seed)
{
printf("Random number generator seed: %d\n", seed);
srandom(seed);
}
BPNN *bpnn_internal_create(n_in, n_hidden, n_out)
int n_in, n_hidden, n_out;
{
BPNN *newnet;
newnet = (BPNN *) malloc (sizeof (BPNN));
if (newnet == NULL) {
printf("BPNN_CREATE: Couldn't allocate neural network\n");
return (NULL);
}
newnet->input_n = n_in;
newnet->hidden_n = n_hidden;
newnet->output_n = n_out;
newnet->input_units = alloc_1d_dbl(n_in + 1);
newnet->hidden_units = alloc_1d_dbl(n_hidden + 1);
newnet->output_units = alloc_1d_dbl(n_out + 1);
newnet->hidden_delta = alloc_1d_dbl(n_hidden + 1);
newnet->output_delta = alloc_1d_dbl(n_out + 1);
newnet->target = alloc_1d_dbl(n_out + 1);
newnet->input_weights = alloc_2d_dbl(n_in + 1, n_hidden + 1);
newnet->hidden_weights = alloc_2d_dbl(n_hidden + 1, n_out + 1);
newnet->input_prev_weights = alloc_2d_dbl(n_in + 1, n_hidden + 1);
newnet->hidden_prev_weights = alloc_2d_dbl(n_hidden + 1, n_out + 1);
return (newnet);
}
void bpnn_free(net)
BPNN *net;
{
int n1, n2, i;
n1 = net->input_n;
n2 = net->hidden_n;
free((char *) net->input_units);
free((char *) net->hidden_units);
free((char *) net->output_units);
free((char *) net->hidden_delta);
free((char *) net->output_delta);
free((char *) net->target);
for (i = 0; i <= n1; i++) {
free((char *) net->input_weights[i]);
free((char *) net->input_prev_weights[i]);
}
free((char *) net->input_weights);
free((char *) net->input_prev_weights);
for (i = 0; i <= n2; i++) {
free((char *) net->hidden_weights[i]);
free((char *) net->hidden_prev_weights[i]);
}
free((char *) net->hidden_weights);
free((char *) net->hidden_prev_weights);
free((char *) net);
}
/*** Creates a new fully-connected network from scratch,
with the given numbers of input, hidden, and output units.
Threshold units are automatically included. All weights are
randomly initialized.
Space is also allocated for temporary storage (momentum weights,
error computations, etc).
***/
BPNN *bpnn_create(n_in, n_hidden, n_out)
int n_in, n_hidden, n_out;
{
BPNN *newnet;
newnet = bpnn_internal_create(n_in, n_hidden, n_out);
#ifdef INITZERO
bpnn_zero_weights(newnet->input_weights, n_in, n_hidden);
#else
bpnn_randomize_weights(newnet->input_weights, n_in, n_hidden);
#endif
bpnn_randomize_weights(newnet->hidden_weights, n_hidden, n_out);
bpnn_zero_weights(newnet->input_prev_weights, n_in, n_hidden);
bpnn_zero_weights(newnet->hidden_prev_weights, n_hidden, n_out);
return (newnet);
}
void bpnn_layerforward(l1, l2, conn, n1, n2)
double *l1, *l2, **conn;
int n1, n2;
{
double sum;
int j, k;
/*** Set up thresholding unit ***/
l1[0] = 1.0;
/*** For each unit in second layer ***/
for (j = 1; j <= n2; j++) {
/*** Compute weighted sum of its inputs ***/
sum = 0.0;
for (k = 0; k <= n1; k++) {
sum += conn[k][j] * l1[k];
}
l2[j] = squash(sum);
}
}
void bpnn_output_error(delta, target, output, nj, err)
double *delta, *target, *output, *err;
int nj;
{
int j;
double o, t, errsum;
errsum = 0.0;
for (j = 1; j <= nj; j++) {
o = output[j];
t = target[j];
delta[j] = o * (1.0 - o) * (t - o);
errsum += ABS(delta[j]);
}
*err = errsum;
}
void bpnn_hidden_error(delta_h, nh, delta_o, no, who, hidden, err)
double *delta_h, *delta_o, *hidden, **who, *err;
int nh, no;
{
int j, k;
double h, sum, errsum;
errsum = 0.0;
for (j = 1; j <= nh; j++) {
h = hidden[j];
sum = 0.0;
for (k = 1; k <= no; k++) {
sum += delta_o[k] * who[j][k];
}
delta_h[j] = h * (1.0 - h) * sum;
errsum += ABS(delta_h[j]);
}
*err = errsum;
}
void bpnn_adjust_weights(delta, ndelta, ly, nly, w, oldw, eta, momentum)
double *delta, *ly, **w, **oldw, eta, momentum;
{
double new_dw;
int k, j;
ly[0] = 1.0;
for (j = 1; j <= ndelta; j++) {
for (k = 0; k <= nly; k++) {
new_dw = ((eta * delta[j] * ly[k]) + (momentum * oldw[k][j]));
w[k][j] += new_dw;
oldw[k][j] = new_dw;
}
}
}
void bpnn_feedforward(net)
BPNN *net;
{
int in, hid, out;
in = net->input_n;
hid = net->hidden_n;
out = net->output_n;
/*** Feed forward input activations. ***/
bpnn_layerforward(net->input_units, net->hidden_units,
net->input_weights, in, hid);
bpnn_layerforward(net->hidden_units, net->output_units,
net->hidden_weights, hid, out);
}
void bpnn_train(net, eta, momentum, eo, eh)
BPNN *net;
double eta, momentum, *eo, *eh;
{
int in, hid, out;
double out_err, hid_err;
in = net->input_n;
hid = net->hidden_n;
out = net->output_n;
/*** Feed forward input activations. ***/
bpnn_layerforward(net->input_units, net->hidden_units,
net->input_weights, in, hid);
bpnn_layerforward(net->hidden_units, net->output_units,
net->hidden_weights, hid, out);
/*** Compute error on output and hidden units. ***/
bpnn_output_error(net->output_delta, net->target, net->output_units,
out, &out_err);
bpnn_hidden_error(net->hidden_delta, hid, net->output_delta, out,
net->hidden_weights, net->hidden_units, &hid_err);
*eo = out_err;
*eh = hid_err;
/*** Adjust input and hidden weights. ***/
bpnn_adjust_weights(net->output_delta, out, net->hidden_units, hid,
net->hidden_weights, net->hidden_prev_weights, eta, momentum);
bpnn_adjust_weights(net->hidden_delta, hid, net->input_units, in,
net->input_weights, net->input_prev_weights, eta, momentum);
}
void bpnn_save(net, filename)
BPNN *net;
char *filename;
{
int fd, n1, n2, n3, i, j, memcnt;
double dvalue, **w;
char *mem;
if ((fd = creat(filename, 0644)) == -1) {
printf("BPNN_SAVE: Cannot create '%s'\n", filename);
return;
}
n1 = net->input_n; n2 = net->hidden_n; n3 = net->output_n;
printf("Saving %dx%dx%d network to '%s'\n", n1, n2, n3, filename);
fflush(stdout);
write(fd, (char *) &n1, sizeof(int));
write(fd, (char *) &n2, sizeof(int));
write(fd, (char *) &n3, sizeof(int));
memcnt = 0;
w = net->input_weights;
mem = (char *) malloc ((unsigned) ((n1+1) * (n2+1) * sizeof(double)));
for (i = 0; i <= n1; i++) {
for (j = 0; j <= n2; j++) {
dvalue = w[i][j];
fastcopy(&mem[memcnt], &dvalue, sizeof(double));
memcnt += sizeof(double);
}
}
write(fd, mem, (n1+1) * (n2+1) * sizeof(double));
free(mem);
memcnt = 0;
w = net->hidden_weights;
mem = (char *) malloc ((unsigned) ((n2+1) * (n3+1) * sizeof(double)));
for (i = 0; i <= n2; i++) {
for (j = 0; j <= n3; j++) {
dvalue = w[i][j];
fastcopy(&mem[memcnt], &dvalue, sizeof(double));
memcnt += sizeof(double);
}
}
write(fd, mem, (n2+1) * (n3+1) * sizeof(double));
free(mem);
close(fd);
return;
}
BPNN *bpnn_read(filename)
char *filename;
{
char *mem;
BPNN *new;
int fd, n1, n2, n3, i, j, memcnt;
if ((fd = open(filename, 0, 0644)) == -1) {
return (NULL);
}
printf("Reading '%s'\n", filename); fflush(stdout);
read(fd, (char *) &n1, sizeof(int));
read(fd, (char *) &n2, sizeof(int));
read(fd, (char *) &n3, sizeof(int));
new = bpnn_internal_create(n1, n2, n3);
printf("'%s' contains a %dx%dx%d network\n", filename, n1, n2, n3);
printf("Reading input weights..."); fflush(stdout);
memcnt = 0;
mem = (char *) malloc ((unsigned) ((n1+1) * (n2+1) * sizeof(double)));
read(fd, mem, (n1+1) * (n2+1) * sizeof(double));
for (i = 0; i <= n1; i++) {
for (j = 0; j <= n2; j++) {
fastcopy(&(new->input_weights[i][j]), &mem[memcnt], sizeof(double));
memcnt += sizeof(double);
}
}
free(mem);
printf("Done\nReading hidden weights..."); fflush(stdout);
memcnt = 0;
mem = (char *) malloc ((unsigned) ((n2+1) * (n3+1) * sizeof(double)));
read(fd, mem, (n2+1) * (n3+1) * sizeof(double));
for (i = 0; i <= n2; i++) {
for (j = 0; j <= n3; j++) {
fastcopy(&(new->hidden_weights[i][j]), &mem[memcnt], sizeof(double));
memcnt += sizeof(double);
}
}
free(mem);
close(fd);
printf("Done\n"); fflush(stdout);
bpnn_zero_weights(new->input_prev_weights, n1, n2);
bpnn_zero_weights(new->hidden_prev_weights, n2, n3);
return (new);
}
I don't dislike the Propeller, it's just that I don't see why people use it for applications for which it isn't all that suitable.
3 reasons
Its plain to see that people use the Propeller because they love working with it, these forums and its members are first class and always willing to help even an amateur hobbyist like me and last but not least Parallax is an awesome company.
Suitable or not people are doing great things with it IMHO.
The best part Leon is you don't have "see" or understand it, just accept it.
8051 ... monster ... whenever the clock rolled over to a new second, a lot of updates ...didn't have a RTC ... UI was a 'state machine' ... 3000 lines of assembly code ...inline code that should have been a subroutines ... didn't dare waste the cycles ... calculated how many cycles
DUDE, how about a trigger warning, HUH? Some of us haven't gotten over the PTSD yet. Now I'm gonna have to go check under all the furniture to convince myself there aren't any more logic bombs waiting to explode under them.
Because it's fun, and capable, and pushing the edge is always a good thing. "Suitable" is a relative term too. Say we've got one person who has a lot of skill on, say AVR, PIC, etc... And we've another than can really use a Prop, but might not have skill elsewhere. Suitable then means very different things to those individuals, doesn't it?
Sure it does.
Then there is the case where it's fun to advance one's skills, and how is that done? Pushing something to the edge means understanding it at more than a functional level, and what better way to demonstrate that understanding than to make something perform outside the expected norms?
We've got a lot of very interesting code today because people chose to do that. The overall impact of that is significant because it then extends those norms to a new scope and level, where suddenly it does make sense to do more, because it's been done nicely.
That brings me to various work / hobby modes.
For those of us doing this because we want to, on a hobby basis, or small business basis, pushing the edge is always good, because it extends the investments in ways that pay off many times, a primary one being to get better use of time and materials. Always easier to reach for what's on the bench than it is to send away, get familiar, etc...
In a more professional capacity, there are considerations above and beyond whether or not something is possible, and that changes things, and time might be dedicated to specific means and methods because they pay off in a greater context.
The idea that we should constrain our ideas of what works on a prop to some known, favorable set runs in conflict with the same ideas that lead to enjoying a new technology, or a highly differentiated one, and I have the most problem with these discussions in that context. I want to see what can be done on a Prop, because I learn from that, and because I *like* Props and the scene surrounding them. Sometimes it's all just that simple, and the value of it happens to be exactly what people think it is, norms or not. Wouldn't hurt to recognize that a bit more, would it?
I would argue that most people haven't seen it all before, which is a very significant part of why they are here. Wouldn't hurt to recognize that too, would it? I know, if we took a few seasoned types and put them in a discussion, the "right way" or "suitability" would vary among them, based on their preferences and experiences... meaning there is always some room to bend the tech a little and get something done, and in fact, mandatory that people do build that skill because those same seasoned types will have lots of stories about how they had to do it with X, because Y was off the table for whatever reason.
Closing the loop on all of that, it follows that here, where we do propellers, we want to do lots of interesting stuff with Propellers, get motivated by what others do, see the chip boundaries pushed, and generally just build skill, have fun, realize things, do, play, right? Damn right. And that's all I'll say about it, the greater point here being left to the reader "at large", ideally with a Prop in their hands. :0
The ARM can have fully deterministic interrupts. It slows things down somewhat, though.
Yeah, it particularly slows down the development.
Speaking of slow development, how is that 2x Quad SPI memory interface coming? I'm really impressed by how fast you whipped that out. All those superior chips you prattle about don't seem to be helping you. Building another PCB seems to be an oft-used dodge of yours for not writing code. But since you can crank out a PCB in 30 minutes, I guess that's not much of an excuse either. What is your excuse?
Speaking of slow development, how is that 2x Quad SPI memory interface coming? I'm really impressed by how fast you whipped that out. All those superior chips you prattle about don't seem to be helping you. Building another PCB seems to be an oft-used dodge of yours for not writing code. But since you can crank out a PCB in 30 minutes, I guess that's not much of an excuse either. What is your excuse?
I'll be the first to say that some code i posted that he might be trying to use is not fully functional.
Meanwhile, I've moved past that and have produced something that runs with David Betz's XBASIC.
This device is executing code on a Propeller fetched straight from 2x QuadSPI chips. Performance is just fine
The SOIC versions of the chip come in two sizes, and Digi-Key only stocks the wide ones, but I slipped up and used the wrong footprint for the boards I ordered.
I managed to solder one of them to a board, with a lot of difficulty, but I'm not all that happy about the solder joints. I'll check continuity between the tracks and the leads and try it out on a Propeller Proto board tomorrow. Perhaps I should have done what I did when I made a similar mistake with a footprint many years ago and bend the leads underneath the chip, like the old PLCC devices.
Cute device! Since this thread is titled "Use of Propeller", I don't suppose it would out-of-line to ask what it does...
Not out of line
It's a preview of a small Propeller PDA designed for various purposes including weight control and related issues. Nice graphics are a very important aspect of the product and the LCD supports 65K colors.
Target sales price is $99.99.
I'm writing games and other programs for it too. It is programmable in the VB-like XBASIC for programs > 32KB. It is also programmable in SPIN/PASM for smaller applications. The BASIC application technology is also usable with SpinSocket-Flash. David's XBASIC will be released soon.
This particular version has a joystick+other control buttons, sdcard, headphone jack, in addition to accelerometer, rtc, and 4MB of fast access byte-wide QuadSPI flash. Application start time is about 4 seconds right now ... mainly driven by Propeller EEPROM boot time.
Its plain to see that people use the Propeller because they love working with it, these forums and its members are first class and always willing to help even an amateur hobbyist like me and last but not least Parallax is an awesome company.
That reason is perfectly fine for hobbyists. Heck, I often choose an MCU for a hobbyist project because it's unusual or challenging to interface or program. But for commercial applications, this is not the case. Just because something can be done with a particular MCU doesn't mean it should be.
In a commercial environment, other factors are much more important and take precedence. These factors include familiarity of the developers with the part, availability of good development tools, and cost.
A company will gladly spend an additional $1M in NRE to use a part with a poor programming architecture that costs $1 less per unit if they're building 10M units, for example (because the overall savings is $10M - $1M = $9M).
At the other extreme, a project to develop a small number of high-value units, then it's much more desirable to sacrifice unit cost of the MCU in favor of one that's easier to program and has better tools.
To that You need add THAT most of as so called "Professionals" are very conservative in theirs decisions. On both Hardware and Software that them will use.
That reason is perfectly fine for hobbyists. Heck, I often choose an MCU for a hobbyist project because it's unusual or challenging to interface or program. But for commercial applications, this is not the case. Just because something can be done with a particular MCU doesn't mean it should be.
In a commercial environment, other factors are much more important and take precedence. These factors include familiarity of the developers with the part, availability of good development tools, and cost.
A company will gladly spend an additional $1M in NRE to use a part with a poor programming architecture that costs $1 less per unit if they're building 10M units, for example (because the overall savings is $10M - $1M = $9M).
At the other extreme, a project to develop a small number of high-value units, then it's much more desirable to sacrifice unit cost of the MCU in favor of one that's easier to program and has better tools.
But for commercial applications, this is not the case. Just because something can be done with a particular MCU doesn't mean it should be.
Axiomatic, my dear Sal. Any individual or organization with the savvy to design a commercially viable product understands the economics of the situation and does not need a self-appointed consultant named Leon trolling the Parallax forums in their behalf. If he had half the skills he professes to have, he'd have better and more lucrative ways to spend his time. He's the poster child for the old saw that, "Those who can, do; those who can't, teach."
Implement the standard back-propagation algorithm and see if you can use it to solve the classic XOR problem. It can't be done without a hidden layer. Don't bother about efficiency at this stage, use floating-point.
Sorry guys, I googled and found some links to 'back-propagation algorithm' and 'classic XOR problem', but I have not a clue as to what these are trying to do or why. This is going to take a lot more reading and a lot less kids chasing the dog. Any hints?
Whilst a simple perceptron can perform logic functions like AND and NAND, it doesn't work with XOR and many other functions. It was eventually found that they require an inner layer and back-propagation:
I do not believe, that implementing neural networks really makes any sense, because science is still on the way. What can we do?
One possible application of a propeller network could be to extract the notes from a piece of music. Watch a soundtrack and write down the notes. Needs to decompose a complex signal, FFT, wavelets?, ANNs? ... And nobody can do it
And what? automatic number plate recognition? What is difficult with that and could not be done else. Typical example for an NANN is to start from scratch and be a PhD after 25 years. Typical ANN is feeding a doctor for 25 years without result ;--)
I was working for Racal when they developed it, it was tested on vehicles entering and leaving our car park. The ANN software came from a company in Cambridge.
Here in Norway we use automatic numberplate recognicion on both toll roads and in automatic traffic control systems(speed traps)
For toll roads, it must be able to read plates on cars driving at least 80Km/h(55mp/h?)
For traffic control... the requirements are a bit more extreme...
The first camera takes a picture, reads speed(sensors in the ground) and wheel distances, and also the plates.
It then contacts the main registration database and checks the type of car against measured wheel distances, to double-check that the speed measurement was correct.
A few kilometers down the road is another camera, which does the same job, again...
It then uses the distance between the cameras(this is of course constant) and the time between the pictures(both cameras are continually synched to one server, so drift is pretty much eliminated)
If the speed calculated is over the limit, a red light will switch on. this is placed just a few meters behind the camera, so the calculations must be done in less than a second. If the speed is in the legal zone, the pictures are deleted.
If one of the readings has a mismatch on wheelbases, they're also deleted(unless the driver was speeding while actually passing the camera, not just between them, of course)
This is all done using common PCs and a good quality digital camera.
From what I heard, the biggest difficulty was in getting a good 'invisible' flash(they use ultraviolet light) for the cameras.
(older 'spot check' systems use a visible flash, but they only take pictures when they register a car driving too fast. And on those systems, they don't have to use ANPR as all pictures must be manually checked anyway. If the driver can't be recognised, the pictures are usually tossed away as its the driver who gets fined, not the owner of the car.)
We are also beginning to use a 'portable' kit, which is mounted in a car. This can be parked along a busy road, or they can drive through a parking lot with it, and it will scan all plates, check them against the main register(using 3G or whatever is available) and flag cars that the owners haven't paid road tax or insurance for, or haven't had the latest MOT(or whatever it's called where you live).
(This kit is able to spot if the car has the current 'tax stickers' affixed to the plates or not, too. After August 15, it doesn't matter if everything is checked and paid up, if the sticker isn't in place, the plates gets removed... They had to use colour cameras for this system, which adds to the complexity. )
Anyway, doing ANPR today means being able to correctly read a lot of plates, VERY quickly.
It may be 'fun' to try and implement it with a Propeller or even a stack of them, but unless you can get reliable readings in less than a second, there won't be a market for it.
I will very shortly get back to you as to what we can do with ANN and the prop. As a small example, Hanno completed the balancing robot. When I taught ANN, we designed a balancing broom project, using a then primitive IC that had come out. So there is similarity. Some basic algorithms, like the Perceptron, do not require that much memory, others do. What I would like to do is apply the standard ANN algorithms, such as Perceptron, Backpropagation, etc using the Prop. Where you will a requirement for large amounts of memory is the application of ANN in statistics problems and similar applications.
Comments
We all here are amateurs and we SPEND money working with the propeller. The UPE are full of those, they even pay to go there, book hotels, have a great time. So, having a cheaper controller: what for? My pleasure is to give propellers away for free. To share the joy I find. Being used to work with gates, starting to make a CPU from gates, I went the way to 8080, Z80, 8051, Z8, Transputers, ... and I finally gave up! Nothing to do what others not had done already, but no longer able to run a V.24 communication line. Then, by lucky accident I found the propeller. All my knowlegde on what to do and NOT to do I could use, having this chip. So let me ask one question: if you make your money with low cost chips, what brings you to here. I have to say: I made my money with low cost solutions, but only the propeller gave me the chance to develop such an solution.
Now to ANN: a lot of research work is done on this field, but I am not aware of any useful product. It might be of academical interest. In this case the performance and realtime behavior is not relevant, so is the price point. But if whenever someone finds the solution to a real problem in form of an ANN, like autonomous housekeeping, and he can show, that this really works, he can raise the funds necessary to make an affordable solution. So my hope is, he needs about 64 analog inputs. And then Prop][ will be unbeatable, because the great designer just decided: I know how to make a multipurpose I/O-Pin, so let there be 64 of them, why not!
And now some words to this great forum: I had used FFT for years and then not for decades. Only the forum here and the discussion on why a FFT works gave me the insight into a very simple relationsship and why a complex number is not a vector. So even if others didn't follow, to me something became clear. That is what you can not count in $.
I do not say, I could not have got such in result in an other place. But: in such a place I can not read about blinking a LED, drive a robot, or share my knowledge in another field, what I sadly do not often enough.
And, not to be misunderstood: we need Leons comments and contributions. I at least feel triggered to write down my positive experience.
ErNa
This ANN is getting me interested. The multiprop support I am testing allows as many props as needed to be linked together to provide as many pins and as many chunks of 32k RAM as needed costing three resistors and one capacitor per prop. Also, the SD support I am testing gives me 8 Gig of SD that I can use as expanded RAM (sort of).
What is a demo that I can make to show ANN on the prop or another micro controler? If number of I/O pins and amount of memory are the only obstacles, assume these are solved, or the demo is not to be specific to a particular micro controller.
Can the forum participant create a straightforward ANN example we can code?
Later versions of the computer introduced in 1979 was slightly slower to switch levels because the register sets weren't executable, just a set copied from a fast register file: The switch took 5 microseconds. But the CPU was much faster than the earlier version so the price was worth it for most purposes. The interrupt handling was so fast (for the period's requirements) that for a 5-channel I/O board we needed just 2KB of fifo on-board while when we moved the whole thing to a Sun computer around 1990-1991 we had to install 8MB of fifo in the new hardware to keep up.
Parallel processors like in the Propeller also have their place, in a way it's like working with thread programming.. and with the same possibilities for doing it wrong, of course. Threads, when done right, can reduce a complicated program to a very simple thing. Just think of a serial terminal emulator: With threads it's the easiest thing in the world to program: One thread sits and listens to the keyboard input, writes what it receives to the serial output. Another thread listens to the serial input, writes the output to the screen. Very little code. Then there are those who try to split everything into threads because it's fashionable.. or at least it used to be, just a few years back. There was a lot of horrible messy code back then.
Lesson 5 for the QuickStart http://www.parallaxsemiconductor.com/quickstart5
The lessons are short so you get to that point about 10 minutes after starting your first tries with the propeller, which I did only recently. Lovely stuff!
-Tor
Here is the backprop code for a facial recognition ANN application developed at CMU. I've built the whole thing with gcc and it seemed to work OK when I tested it. I can supply the whole program if anyone is interested.
3 reasons
Its plain to see that people use the Propeller because they love working with it, these forums and its members are first class and always willing to help even an amateur hobbyist like me and last but not least Parallax is an awesome company.
Suitable or not people are doing great things with it IMHO.
The best part Leon is you don't have "see" or understand it, just accept it.
Ron
DUDE, how about a trigger warning, HUH? Some of us haven't gotten over the PTSD yet. Now I'm gonna have to go check under all the furniture to convince myself there aren't any more logic bombs waiting to explode under them.
Because it's fun, and capable, and pushing the edge is always a good thing. "Suitable" is a relative term too. Say we've got one person who has a lot of skill on, say AVR, PIC, etc... And we've another than can really use a Prop, but might not have skill elsewhere. Suitable then means very different things to those individuals, doesn't it?
Sure it does.
Then there is the case where it's fun to advance one's skills, and how is that done? Pushing something to the edge means understanding it at more than a functional level, and what better way to demonstrate that understanding than to make something perform outside the expected norms?
We've got a lot of very interesting code today because people chose to do that. The overall impact of that is significant because it then extends those norms to a new scope and level, where suddenly it does make sense to do more, because it's been done nicely.
That brings me to various work / hobby modes.
For those of us doing this because we want to, on a hobby basis, or small business basis, pushing the edge is always good, because it extends the investments in ways that pay off many times, a primary one being to get better use of time and materials. Always easier to reach for what's on the bench than it is to send away, get familiar, etc...
In a more professional capacity, there are considerations above and beyond whether or not something is possible, and that changes things, and time might be dedicated to specific means and methods because they pay off in a greater context.
The idea that we should constrain our ideas of what works on a prop to some known, favorable set runs in conflict with the same ideas that lead to enjoying a new technology, or a highly differentiated one, and I have the most problem with these discussions in that context. I want to see what can be done on a Prop, because I learn from that, and because I *like* Props and the scene surrounding them. Sometimes it's all just that simple, and the value of it happens to be exactly what people think it is, norms or not. Wouldn't hurt to recognize that a bit more, would it?
I would argue that most people haven't seen it all before, which is a very significant part of why they are here. Wouldn't hurt to recognize that too, would it? I know, if we took a few seasoned types and put them in a discussion, the "right way" or "suitability" would vary among them, based on their preferences and experiences... meaning there is always some room to bend the tech a little and get something done, and in fact, mandatory that people do build that skill because those same seasoned types will have lots of stories about how they had to do it with X, because Y was off the table for whatever reason.
Closing the loop on all of that, it follows that here, where we do propellers, we want to do lots of interesting stuff with Propellers, get motivated by what others do, see the chip boundaries pushed, and generally just build skill, have fun, realize things, do, play, right? Damn right. And that's all I'll say about it, the greater point here being left to the reader "at large", ideally with a Prop in their hands. :0
Yeah, it particularly slows down the development.
Speaking of slow development, how is that 2x Quad SPI memory interface coming? I'm really impressed by how fast you whipped that out. All those superior chips you prattle about don't seem to be helping you. Building another PCB seems to be an oft-used dodge of yours for not writing code. But since you can crank out a PCB in 30 minutes, I guess that's not much of an excuse either. What is your excuse?
I'll be the first to say that some code i posted that he might be trying to use is not fully functional.
Meanwhile, I've moved past that and have produced something that runs with David Betz's XBASIC.
This device is executing code on a Propeller fetched straight from 2x QuadSPI chips. Performance is just fine
I managed to solder one of them to a board, with a lot of difficulty, but I'm not all that happy about the solder joints. I'll check continuity between the tracks and the leads and try it out on a Propeller Proto board tomorrow. Perhaps I should have done what I did when I made a similar mistake with a footprint many years ago and bend the leads underneath the chip, like the old PLCC devices.
Cute device! Since this thread is titled "Use of Propeller", I don't suppose it would out-of-line to ask what it does...
It's a preview of a small Propeller PDA designed for various purposes including weight control and related issues. Nice graphics are a very important aspect of the product and the LCD supports 65K colors.
Target sales price is $99.99.
I'm writing games and other programs for it too. It is programmable in the VB-like XBASIC for programs > 32KB. It is also programmable in SPIN/PASM for smaller applications. The BASIC application technology is also usable with SpinSocket-Flash. David's XBASIC will be released soon.
This particular version has a joystick+other control buttons, sdcard, headphone jack, in addition to accelerometer, rtc, and 4MB of fast access byte-wide QuadSPI flash. Application start time is about 4 seconds right now ... mainly driven by Propeller EEPROM boot time.
That reason is perfectly fine for hobbyists. Heck, I often choose an MCU for a hobbyist project because it's unusual or challenging to interface or program. But for commercial applications, this is not the case. Just because something can be done with a particular MCU doesn't mean it should be.
In a commercial environment, other factors are much more important and take precedence. These factors include familiarity of the developers with the part, availability of good development tools, and cost.
A company will gladly spend an additional $1M in NRE to use a part with a poor programming architecture that costs $1 less per unit if they're building 10M units, for example (because the overall savings is $10M - $1M = $9M).
At the other extreme, a project to develop a small number of high-value units, then it's much more desirable to sacrifice unit cost of the MCU in favor of one that's easier to program and has better tools.
To that You need add THAT most of as so called "Professionals" are very conservative in theirs decisions. On both Hardware and Software that them will use.
Axiomatic, my dear Sal. Any individual or organization with the savvy to design a commercially viable product understands the economics of the situation and does not need a self-appointed consultant named Leon trolling the Parallax forums in their behalf. If he had half the skills he professes to have, he'd have better and more lucrative ways to spend his time. He's the poster child for the old saw that, "Those who can, do; those who can't, teach."
your cat sheds all over the place, and you probably don't know how to spell "french fries".
Nothing personal, man. You know... when in Rome and all that...
Sorry guys, I googled and found some links to 'back-propagation algorithm' and 'classic XOR problem', but I have not a clue as to what these are trying to do or why. This is going to take a lot more reading and a lot less kids chasing the dog. Any hints?
http://en.wikipedia.org/wiki/Perceptron
Whilst a simple perceptron can perform logic functions like AND and NAND, it doesn't work with XOR and many other functions. It was eventually found that they require an inner layer and back-propagation:
http://en.wikipedia.org/wiki/Backpropagation
Here is a good description of how to implement it:
http://www.cs.bham.ac.uk/~jxb/INC/nn.html
and here are the Birmingham ANN course details with plenty of references:
http://www.cs.bham.ac.uk/~jxb/inc.html
One possible application of a propeller network could be to extract the notes from a piece of music. Watch a soundtrack and write down the notes. Needs to decompose a complex signal, FFT, wavelets?, ANNs? ... And nobody can do it
http://ndi-rs.com/ukrs/talon_anpr_software
I was working for Racal when they developed it, it was tested on vehicles entering and leaving our car park. The ANN software came from a company in Cambridge.
For toll roads, it must be able to read plates on cars driving at least 80Km/h(55mp/h?)
For traffic control... the requirements are a bit more extreme...
The first camera takes a picture, reads speed(sensors in the ground) and wheel distances, and also the plates.
It then contacts the main registration database and checks the type of car against measured wheel distances, to double-check that the speed measurement was correct.
A few kilometers down the road is another camera, which does the same job, again...
It then uses the distance between the cameras(this is of course constant) and the time between the pictures(both cameras are continually synched to one server, so drift is pretty much eliminated)
If the speed calculated is over the limit, a red light will switch on. this is placed just a few meters behind the camera, so the calculations must be done in less than a second. If the speed is in the legal zone, the pictures are deleted.
If one of the readings has a mismatch on wheelbases, they're also deleted(unless the driver was speeding while actually passing the camera, not just between them, of course)
This is all done using common PCs and a good quality digital camera.
From what I heard, the biggest difficulty was in getting a good 'invisible' flash(they use ultraviolet light) for the cameras.
(older 'spot check' systems use a visible flash, but they only take pictures when they register a car driving too fast. And on those systems, they don't have to use ANPR as all pictures must be manually checked anyway. If the driver can't be recognised, the pictures are usually tossed away as its the driver who gets fined, not the owner of the car.)
We are also beginning to use a 'portable' kit, which is mounted in a car. This can be parked along a busy road, or they can drive through a parking lot with it, and it will scan all plates, check them against the main register(using 3G or whatever is available) and flag cars that the owners haven't paid road tax or insurance for, or haven't had the latest MOT(or whatever it's called where you live).
(This kit is able to spot if the car has the current 'tax stickers' affixed to the plates or not, too. After August 15, it doesn't matter if everything is checked and paid up, if the sticker isn't in place, the plates gets removed... They had to use colour cameras for this system, which adds to the complexity. )
Anyway, doing ANPR today means being able to correctly read a lot of plates, VERY quickly.
It may be 'fun' to try and implement it with a Propeller or even a stack of them, but unless you can get reliable readings in less than a second, there won't be a market for it.
I will very shortly get back to you as to what we can do with ANN and the prop. As a small example, Hanno completed the balancing robot. When I taught ANN, we designed a balancing broom project, using a then primitive IC that had come out. So there is similarity. Some basic algorithms, like the Perceptron, do not require that much memory, others do. What I would like to do is apply the standard ANN algorithms, such as Perceptron, Backpropagation, etc using the Prop. Where you will a requirement for large amounts of memory is the application of ANN in statistics problems and similar applications.
Long live the Prop!