Yeah, those are the dimensions as designed, I need to know dimensions as manufactured - and board thickness is not on there. I've designed the enclosure with some tolerance around the edges, I'm sure that is sufficient. But the knowing the actual thickness of PCB is important for a good fit of the enclosure.
Does anyone know if the Prop2 can do master/slave blind programming?
(a master prop can program a slave prop using proploader (all in spin on the prop)
If you connect a 3rd propeller's RX to the TX out of the master prop, but leave the TX out of the 3rd prop floating....
During programming, the 3rd prop will usually take the program because the second slave prop does the programming replies.
It emulates the replies the 3rd prop makes because their responses are so similar, it works.
The 3rd prop takes the programming fine. And 50+ slave props all connected this way will also be programmed and run properly, all in the timeframe of a single prop programming sequence.
In other words did you keep a simple serial programming ability, or did you include a encryption/crc unique to each p2?
I would like to try this programming method on the p2, but I do not know if you made the serial programming process much different (i suspect so)
If so, then this blind upload of hundereds of props using a single slave and master, is no longer possible with the p2.
Perhaps someone could test that using 3 p2's?
I suspect that you have changed the serial programming protocol which now includes data crc or serialization during the programming sequence, which would prevent this ability to do DUMMY loading of hundreds of props in the time frame of a single prop?
@Clock Loop
P2 supports multiple device programming.
IO pins can give each P2 a unique ID for programming.
All or selected P2's can then be programmed.
From the P2 docs.
Each command keyword is followed by four 32-bit hex values which allow selection of certain chips by their INA and INB
states. If you wanted to talk to any and all chips that are connected, you would use zeroes for these values. In case multiple
chips are being loaded from the same serial line, you would probably want to differentiate each download by unique INA and
INB mask and data values. When the serial loader receives data and mask values which do not match its own INA and INB
ports, it waits for another command. Because the command keywords all contain an underscore (“_”), they cannot be mistaken
by intervening data belonging to a command destined for another chip, while a new command is being waited fo
If you wanted to talk to any and all chips that are connected, you would use zeroes for these values. In case multiple
chips are being loaded from the same serial line, you would probably want to differentiate each download by unique INA and
INB mask and data values. When the serial loader receives data and mask values which do not match its own INA and INB
ports, it waits for another command.
EXCELLLENT, this indeed implies that, a P2 can program X p2's identically, and all in the same timeframe of a single programming sequence.
Can they all operate from the same clock source too?
Where is this P2 information? I can't keep up with all the forum stuff on p2, you guys move so fast, so i miss things...
(takes a step forward)
(contemplates ordering the last 50 props2's....)
(how do you multiply zeros?, we all know what happens when you divide zeros... damn black holes, why didn't anyone warn the aliens that if they tried to divide zero, in real space time, that would happen, do you think they had any idea what was happening when the test apparatus started to implode? )
150.00000 x 50 = 7,500.000000000000000000000000000000000000$ I cannot put 100 zer0s here, and i cannot afford that many zeros.. entropy demands variation...
And what about the PLL? Whats the detail on that, is it the same, changed? Does it still have one? Can you still do real random generation using it? I suspect it might even be better now, at generating random numbers?
If it has one, what are the input clock ranges the pll can work with?
(i am so gonna abuse that pll clock input... its gonna beg for mercy)
I think i need a datasheet.... (takes a step back) sorry... abit ahead of the p2 game perhaps...
In other words did you keep a simple serial programming ability, or did you include a encryption/crc unique to each p2?
There is no unique to each P2 information.
If you look at the DOCs under SERIAL LOADING PROTOCOL, that mentions
"Each command keyword is followed by four 32-bit hex values which allow selection of certain chips by their INA and INB states. If you wanted to talk to any and all chips that are connected, you would use zeroes for these values. In case multiple chips are being loaded from the same serial line, you would probably want to differentiate each download by unique INA and INB mask and data values. When the serial loader receives data and mask values which do not match its own INA and INB ports, it waits for another command. Because the command keywords all contain an underscore (“_”), they cannot be mistaken by intervening data belonging to a command destined for another chip, while a new command is being waited for."
I suspect that you have changed the serial programming protocol which now includes data crc or serialization during the programming sequence, which would prevent this ability to do DUMMY loading of hundreds of props in the time frame of a single prop?
I'm not clear on the exact question here.
Do you want those 'hundreds of props' to all contain the same code, or different code ?
It sounds like you can OR-wire 100+ props, and they will accept the same code.
Checking many replies could get tricky, as the oscillators are not calibrated and they autobaud, so echos will not quite all line-up.
That effect will be worst at higher bauds, which you probably want to be using if programming many P2's
Reply from one could be used, but that means you are unsure if the others were actually ok.
Just maybe you could 'or' wire many Props, and try to catch the checksum pass/fail difference of "." / "!", but of course have no way to know which P2 gave the error.
If you did want a production gang programmer, why not just use a P2, which can check each targets replies for confirmed ok's & even run some POST stuff too....
Can they all operate from the same clock source too?
Sure, but during boot they all run on their individual RCFAST oscillators. User code can enable external oscillator.
Seems just like the p1....
I'm not clear on the exact question here.
Do you want those 'hundreds of props' to all contain the same code, or different code ?
It sounds like you can OR-wire 100+ props, and they will accept the same code.
Checking many replies could get tricky, as the oscillators are not calibrated and they autobaud, so echos will not quite all line-up.
That effect will be worst at higher bauds, which you probably want to be using if programming many P2's
Reply from one could be used, but that means you are unsure if the others were actually ok.
Just maybe you could 'or' wire many Props, and try to catch the checksum pass/fail difference of "." / "!", but of course have no way to know which P2 gave the error.
If you did want a production gang programmer, why not just use a P2, which can check each targets replies for confirmed ok's & even run some POST stuff too....
This is NOT for a gang programmer, (no verification in that aspect would be horrible idea)
This is for a science fiction ... uhh toy..... yeah tahts it.. just a fake, completely unreal, science fiction toy that has no way in the universe at all to work..
(this statement is to appease mono-lithic omti-potent busy-bodies, that the world they live in is just as monotone as them )
Please DO NOT talk about this thread or project here, keep it about the P2. Go there and talk about it.
The way I use the P1's in this aspect, is the same, all other p1's don't get verified if they were loaded.
(that is verified in enumeration of the randomly generated unique ID's by stimulating pll jitter with the real random obex object.)
Generating a qunique id can be done during loading it sounds like, but for that to work in parallel loading, the slave p2 needs to make its own ID, which is how I have the p1s doing it now.
If you want to load many P2s in slightly different ways simultaneously, you can load your own small secondary loader to have it do it however you want: take the common parts, ID itself somehow, and then deal with the parts specific to itself when they come.
I think it's unnecessary to have the INA and INB masks in ROM, because you can do it yourself instead. Write a program that listens for a condition and does the test (INA and INB masks like in ROM now, or something more complex) and then either jumps to the ROM bootloader immediately if the test succeeds, or else skips the next program sent before running the test again with new conditions sent before the next program is sent. A programmer would first send this small conditional loader program to every P2, then it would loop sending a condition and a program. The nice thing about this is that if you have a more complex test, e.g. an I2C unique ID chip, you can do that instead of wasting lots of pins to use as an ID.
If you want to load many P2s in slightly different ways simultaneously
I don't, I only want them to be different AFTER they are loaded.
Loaded with parallel programs, and then they generate their own id internally, No pins, no unique boot loader.
Part of what I am doing is minimizing the multiple P2's cores execution process as much as possible so they all run the same code and circuitry internally as possible, if I do unique loaders this throws each p2 into its own "cycle"
I like the fact that the p1 loads blind.. its about getting the clocks and internal circuity as synced as possible, across multiple p2's.
But all this discussion tells me I am going to have fun with a hand full of these P2's once they are ready.
Do we still have external memory support? Like the HyperRAM earlier?
The streamer can move blocks of data in a clocked fashion, but there is no native address-data handling for HyperRAM/OctaSPI/QuadSPI, so some portions would be coded in SW, and some using streamer.
The details of HW pin delays etc have not been tested yet, on HyperRAM or OctaSPI.
Do we still have external memory support? Like the HyperRAM earlier?
The streamer can move blocks of data in a clocked fashion, but there is no native address-data handling for HyperRAM/OctaSPI/QuadSPI, so some portions would be coded in SW, and some using streamer.
The details of HW pin delays etc have not been tested yet, on HyperRAM or OctaSPI.
Ah, I wished there are SDRAM support. Many major 32-bit microcontrollers are equipped with one of these nowadays.
Let’s say if I had to do a graphics frame buffer, I still had to do it manually in Prop2, since it is not memory mapped?
Do we still have external memory support? Like the HyperRAM earlier?
The streamer can move blocks of data in a clocked fashion, but there is no native address-data handling for HyperRAM/OctaSPI/QuadSPI, so some portions would be coded in SW, and some using streamer.
The details of HW pin delays etc have not been tested yet, on HyperRAM or OctaSPI.
Ah, I wished there are SDRAM support. Many major 32-bit microcontrollers are equipped with one of these nowadays.
Let’s say if I had to do a graphics frame buffer, I still had to do it manually in Prop2, since it is not memory mapped?
A big part of the philosophy behind the Propeller is that it doesn't support things like this: instead, it makes it easy and efficient for you to do it yourself, with tools such as the streamer and smartpins.
Ah, I wished there are SDRAM support. Many major 32-bit microcontrollers are equipped with one of these nowadays.
Let’s say if I had to do a graphics frame buffer, I still had to do it manually in Prop2, since it is not memory mapped?
Manually is doable - there are test pgms now, streaming HDMI at 250MHz, and VGA at 148.5MHz from P2
If you need a pixel rate=SysCLK clock with that video, the present P2 silicon comes up a little short, but Chip is looking at adding a streamer-rate clock out to the Rev B.
Failing that, you could use a schmitt xor/xnor gate (eg NC7SV57/58), and clock double the SysCLK/2, which RevA can output.
[A big part of the philosophy behind the Propeller is that it doesn't support things like this: instead, it makes it easy and efficient for you to do it yourself, with tools such as the streamer and smartpins.
The prop1 started same way, gained objects over time, and now we have the OBEX, just CHOCK FULL OF software peripherals. EXCELLENT!
Yes the magic of P1 was that all the pins are the same, they all have this capability. Whether you want 3x VGA or 12 serial ports it's just a matter or picking the software objects. Similarly, running a high-level language out of external RAM should just be a matter of software and one which will probably be attacked in a number of ways by different users. There were efforts in that direction for P1, but the chip wasn't quite up to really doing it well. P2 is more capable from the ground up with both more pins and more built-in RAM for the underlying logic. This is one of the things I look forward to investigating with my recently ordered eval board.
Looks like there are still 29 P2 ES boards available. I figured they'd be sold out by now. In any case, you can still find them on the Parallax store. They aren't in the "New Products" section anymore but you can find them under "Propeller/Boards".
Looks like there are still 29 P2 ES boards available. I figured they'd be sold out by now. In any case, you can still find them on the Parallax store. They aren't in the "New Products" section anymore but you can find them under "Propeller/Boards".
I might order a backup unit if there are still some left in a few days.
When I originally counted there was about 80+ people interested.
Though much like everything else in life. I also know there would be a percentage of drop off between people who say they wanted silicon VS who will actually follow through and order. : ]
Not buying this right now is one of the hardest things I've ever done. I hope these get in the right hands so progress can be quick!
It's cool, we'll cut through the tall grass and clear a path for everyone who follows.
But if you ever change your mind and feel adventurous . There are still some boards left.
Comments
Thanks! Good to know, it's a quarter mm difference from the CAD file I was using.
I had just sent you an email about this and a couple other things...
The last page of this doc has the dimensions:
https://docs.google.com/document/d/1gIKAfx5slcwjrAvHnbn5VNReY2SbQxtYkgO8cIzjyyY/edit#heading=h.6frgvwkw4djo
Yeah, those are the dimensions as designed, I need to know dimensions as manufactured - and board thickness is not on there. I've designed the enclosure with some tolerance around the edges, I'm sure that is sufficient. But the knowing the actual thickness of PCB is important for a good fit of the enclosure.
Seems reasonable that the other dims are going to be equally precise. 3500 mil wide, +- 4 mil tolerance.
(a master prop can program a slave prop using proploader (all in spin on the prop)
If you connect a 3rd propeller's RX to the TX out of the master prop, but leave the TX out of the 3rd prop floating....
During programming, the 3rd prop will usually take the program because the second slave prop does the programming replies.
It emulates the replies the 3rd prop makes because their responses are so similar, it works.
The 3rd prop takes the programming fine. And 50+ slave props all connected this way will also be programmed and run properly, all in the timeframe of a single prop programming sequence.
In other words did you keep a simple serial programming ability, or did you include a encryption/crc unique to each p2?
I would like to try this programming method on the p2, but I do not know if you made the serial programming process much different (i suspect so)
If so, then this blind upload of hundereds of props using a single slave and master, is no longer possible with the p2.
Perhaps someone could test that using 3 p2's?
I suspect that you have changed the serial programming protocol which now includes data crc or serialization during the programming sequence, which would prevent this ability to do DUMMY loading of hundreds of props in the time frame of a single prop?
Thank you Ken, Chip, everyone. It is amazing to place an order with "P2" in it.
P2 supports multiple device programming.
IO pins can give each P2 a unique ID for programming.
All or selected P2's can then be programmed.
From the P2 docs. I tried this with 4 DE0-Nano's, it worked great!
EXCELLLENT, this indeed implies that, a P2 can program X p2's identically, and all in the same timeframe of a single programming sequence.
Can they all operate from the same clock source too?
Where is this P2 information? I can't keep up with all the forum stuff on p2, you guys move so fast, so i miss things...
(takes a step forward)
(contemplates ordering the last 50 props2's....)
(how do you multiply zeros?, we all know what happens when you divide zeros... damn black holes, why didn't anyone warn the aliens that if they tried to divide zero, in real space time, that would happen, do you think they had any idea what was happening when the test apparatus started to implode? )
150.00000 x 50 = 7,500.000000000000000000000000000000000000$ I cannot put 100 zer0s here, and i cannot afford that many zeros.. entropy demands variation...
And what about the PLL? Whats the detail on that, is it the same, changed? Does it still have one? Can you still do real random generation using it? I suspect it might even be better now, at generating random numbers?
If it has one, what are the input clock ranges the pll can work with?
(i am so gonna abuse that pll clock input... its gonna beg for mercy)
I think i need a datasheet.... (takes a step back) sorry... abit ahead of the p2 game perhaps...
If you look at the DOCs under SERIAL LOADING PROTOCOL, that mentions
"Each command keyword is followed by four 32-bit hex values which allow selection of certain chips by their INA and INB states. If you wanted to talk to any and all chips that are connected, you would use zeroes for these values. In case multiple chips are being loaded from the same serial line, you would probably want to differentiate each download by unique INA and INB mask and data values. When the serial loader receives data and mask values which do not match its own INA and INB ports, it waits for another command. Because the command keywords all contain an underscore (“_”), they cannot be mistaken by intervening data belonging to a command destined for another chip, while a new command is being waited for."
so you can address many Props in a system.
I'm not clear on the exact question here.
Do you want those 'hundreds of props' to all contain the same code, or different code ?
It sounds like you can OR-wire 100+ props, and they will accept the same code.
Checking many replies could get tricky, as the oscillators are not calibrated and they autobaud, so echos will not quite all line-up.
That effect will be worst at higher bauds, which you probably want to be using if programming many P2's
Reply from one could be used, but that means you are unsure if the others were actually ok.
Just maybe you could 'or' wire many Props, and try to catch the checksum pass/fail difference of "." / "!", but of course have no way to know which P2 gave the error.
If you did want a production gang programmer, why not just use a P2, which can check each targets replies for confirmed ok's & even run some POST stuff too....
try this link
https://docs.google.com/document/d/1UnelI6fpVPHFISQ9vpLzOVa8oUghxpI6UpkXVsYgBEQ/edit#
This is NOT for a gang programmer, (no verification in that aspect would be horrible idea)
This is for... well something different.
http://forums.parallax.com/discussion/127983/55-parallax-propeller-s-parallells-processing-of-permanent-perturbations/p1
This is for a science fiction ... uhh toy..... yeah tahts it.. just a fake, completely unreal, science fiction toy that has no way in the universe at all to work..
(this statement is to appease mono-lithic omti-potent busy-bodies, that the world they live in is just as monotone as them
Please DO NOT talk about this thread or project here, keep it about the P2. Go there and talk about it.
The way I use the P1's in this aspect, is the same, all other p1's don't get verified if they were loaded.
(that is verified in enumeration of the randomly generated unique ID's by stimulating pll jitter with the real random obex object.)
Generating a qunique id can be done during loading it sounds like, but for that to work in parallel loading, the slave p2 needs to make its own ID, which is how I have the p1s doing it now.
Thanks for the link, i will read it over.
I think it's unnecessary to have the INA and INB masks in ROM, because you can do it yourself instead. Write a program that listens for a condition and does the test (INA and INB masks like in ROM now, or something more complex) and then either jumps to the ROM bootloader immediately if the test succeeds, or else skips the next program sent before running the test again with new conditions sent before the next program is sent. A programmer would first send this small conditional loader program to every P2, then it would loop sending a condition and a program. The nice thing about this is that if you have a more complex test, e.g. an I2C unique ID chip, you can do that instead of wasting lots of pins to use as an ID.
I don't, I only want them to be different AFTER they are loaded.
Loaded with parallel programs, and then they generate their own id internally, No pins, no unique boot loader.
Part of what I am doing is minimizing the multiple P2's cores execution process as much as possible so they all run the same code and circuitry internally as possible, if I do unique loaders this throws each p2 into its own "cycle"
I like the fact that the p1 loads blind.. its about getting the clocks and internal circuity as synced as possible, across multiple p2's.
But all this discussion tells me I am going to have fun with a hand full of these P2's once they are ready.
The streamer can move blocks of data in a clocked fashion, but there is no native address-data handling for HyperRAM/OctaSPI/QuadSPI, so some portions would be coded in SW, and some using streamer.
The details of HW pin delays etc have not been tested yet, on HyperRAM or OctaSPI.
Ah, I wished there are SDRAM support. Many major 32-bit microcontrollers are equipped with one of these nowadays.
Let’s say if I had to do a graphics frame buffer, I still had to do it manually in Prop2, since it is not memory mapped?
However, there are 8 COGS. You could have one doing DMA, and responding to commands to work with external memory.
A big part of the philosophy behind the Propeller is that it doesn't support things like this: instead, it makes it easy and efficient for you to do it yourself, with tools such as the streamer and smartpins.
Manually is doable - there are test pgms now, streaming HDMI at 250MHz, and VGA at 148.5MHz from P2
If you need a pixel rate=SysCLK clock with that video, the present P2 silicon comes up a little short, but Chip is looking at adding a streamer-rate clock out to the Rev B.
Failing that, you could use a schmitt xor/xnor gate (eg NC7SV57/58), and clock double the SysCLK/2, which RevA can output.
The prop1 started same way, gained objects over time, and now we have the OBEX, just CHOCK FULL OF software peripherals. EXCELLENT!
Enter the OBEX2?
I might order a backup unit if there are still some left in a few days.
When I originally counted there was about 80+ people interested.
Though much like everything else in life. I also know there would be a percentage of drop off between people who say they wanted silicon VS who will actually follow through and order. : ]
It's cool, we'll cut through the tall grass and clear a path for everyone who follows.
But if you ever change your mind and feel adventurous . There are still some boards left.
28 left
https://www.parallax.com/product/64000-es