Just called Parallax Sales to order another P123 board. Unfortunately, they are sold out.
Not so happy with my options...
DE2-115 costs more, doesn't give as much and is way too big.
The BeMicro-A9 seems to have been out of stock for a year.
Are there any small A9 boards with reasonable cost?
Any plans to make more P123 boards?
Wait! I believe there are more, but there's some MRP system disconnect. I will call them.
Was looking around and found this: DEV ATLAS SOC A9
It's only ~$100 and there's a lot in stock.
Any chance it would work?
I think that has a smaller 40k FPGA, and the A9 here applies to the ARM variant, not the Altera FPGA Size ?
It could still be of some use for P2 development, using the 5CSEMA4U23C6N ?
Rayman, we've got 8 in stock. In the system, the board is called "Propeller 1-2-3 vA9". The part number is 60065. If you call back and use that data, they will know what you want.
Parallax is out of the new Prop123A9 boards? Maybe they still have some Prop123A7 boards.
Above Chip said they have 8 on Jan 10th ? "we've got 8 in stock. In the system, the board is called "Propeller 1-2-3 vA9". The part number is 60065"
Did you mean they have all sold since the 10th ?
Parallax is out of the new Prop123A9 boards? Maybe they still have some Prop123A7 boards.
Above Chip said they have 8 on Jan 10th ? "we've got 8 in stock. In the system, the board is called "Propeller 1-2-3 vA9". The part number is 60065"
Did you mean they have all sold since the 10th ?
Sorry. I was responding to what turned out to be an old message. Please ignore my comment.
....
A rising edge on DIRx will initiate the smart pin, even from another cog.
I think those are essentially the same, with the point I think Rayman was trying to make, in the example, that you can pre-configure a Smart Pin Cell, from one COG, and then release DIR to start, from ANY COG.
Maybe that DIR action could better be called Apply Config, rather than Reset, as many may avoid loading config when DIR == RESET, thinking nothing would happen ?
(in any other MCU, reset really does reset the SFRs and any configs)
If you raise DIRx and then lower it, the smart pin mode and X parameter remain as previously set.
Any function currently running is terminated and output is cleared.
Raising DIRx again just initiates the smart pin again.
Issuing a new WYPIN instruction starts the smart pin again. WRPIN and WXPIN are not required again.
Rayman, if the DIR bit is low, that smartpin is being held in reset. Are you sure you are seeing the opposite?
Sorry, I wasn't clear enough...
I've got two cogs with serial code.
I thought I disabled one of them by commenting out the "DIRH" line.
But, that wasn't enough... had to comment all the "w_pin" lines too...
Rayman, if the DIR bit is low, that smartpin is being held in reset. Are you sure you are seeing the opposite?
Sorry, I wasn't clear enough...
I've got two cogs with serial code.
I thought I disabled one of them by commenting out the "DIRH" line.
But, that wasn't enough... had to comment all the "w_pin" lines too...
A couple times, now I've tried to do something like this:
mov rx_char,ptrb++ 'pop from stack
When the compiler complains, I remember that ptrb++ is just for hub reading and writing.
Anyway, can this ptrb logic also be easily tied to mov instructions?
I'm not even sure if this would be a good idea or not though...
Wait a minute, that doesn't make any sense at all, never mind...
I guess it's easier to keep a buffer in HUB than in COG RAM, right?
Think I'd need self-modifying code to do receive buffer in cog ram...
Actually, what I should do for this case is use LUT as a buffer...
If you set up RDFAST or WRFAST, you can move data between cog and hub with a single instruction for each long. With the streamer, you can move data between pins and hub. And there are those SETQ/SETQ2-RDLONG/WRLONG combos that can move longs between cog/lut and hub on every clock.
Indirect addressing inside cogmemory is now done with the ALTS/D/R and ALTI instructions instead of self modifying code.
ALTI allows also to modify the pointer, just like PTRB++.
I imagine PNUT could gain new general use cases of the ALTx "prefix" instructions to provide these addressing modes as an assembly feature. Not unlike how ## prefixes a regular instruction with one or more AUGx instructions.
What I'm working on here is very trivial... Just a receive buffer for incoming serial bytes...
Still, at 3 MBaud, I've got only ~26 clocks between bytes.
A write to hub can take up to ~16 clocks and I need to do two separate writes.
But, I just realized that if I combine these two writes, as Chip suggests, with WRFAST or SetQ, then it should be fine.
Still, the code to do serial receive is tiny and there's all kind of space in this cog.
I could do ALTx as Ariba and evanh suggest, but that just looks complicated.
Anyway, I switched my code to use the LUT as buffer.
Maybe that's the best way anyway.
Another benefit is that (at least I think) I don't have to worry about the index rolling over the end of the LUT address space. I'm going to assume that the cog only looks at the lower bits of the address and ignores the upper bits that are outside address space.
1. setq only works with wr/rdlong and not wr/rdbyte
2. when setq used with ptra, the value of ptra is not changed after wr/rdlong
3. there can be no instructions between the setq and the wr/rdlong
1. setq only works with wr/rdlong and not wr/rdbyte
2. when setq used with ptra, the value of ptra is not changed after wr/rdlong
3. there can be no instructions between the setq and the wr/rdlong
Comments
It's only ~$100 and there's a lot in stock.
Any chance it would work?
Maybe I should be brave and try to make my own P123 clone...
Wait! I believe there are more, but there's some MRP system disconnect. I will call them.
It looks like the "-A9" designates "ARM Cortex -A9", not a nice, big FPGA.
I think that has a smaller 40k FPGA, and the A9 here applies to the ARM variant, not the Altera FPGA Size ?
It could still be of some use for P2 development, using the 5CSEMA4U23C6N ?
I had commented out the DIRH command in garryj's USB code thinking that would disable serial output because I was using my own serial I/O code.
When I started getting two characters sent every time I hit the keyboard, I figured it out...
Above Chip said they have 8 on Jan 10th ?
"we've got 8 in stock. In the system, the board is called "Propeller 1-2-3 vA9". The part number is 60065"
Did you mean they have all sold since the 10th ?
A rising edge on DIRx will initiate the smart pin, even from another cog.
For example
I think those are essentially the same, with the point I think Rayman was trying to make, in the example, that you can pre-configure a Smart Pin Cell, from one COG, and then release DIR to start, from ANY COG.
Maybe that DIR action could better be called Apply Config, rather than Reset, as many may avoid loading config when DIR == RESET, thinking nothing would happen ?
(in any other MCU, reset really does reset the SFRs and any configs)
If you raise DIRx and then lower it, the smart pin mode and X parameter remain as previously set.
Any function currently running is terminated and output is cleared.
Raising DIRx again just initiates the smart pin again.
Issuing a new WYPIN instruction starts the smart pin again. WRPIN and WXPIN are not required again.
Sorry, I wasn't clear enough...
I've got two cogs with serial code.
I thought I disabled one of them by commenting out the "DIRH" line.
But, that wasn't enough... had to comment all the "w_pin" lines too...
Obvious now, of course...
Ah, I got it. Thanks.
A couple times, now I've tried to do something like this:
When the compiler complains, I remember that ptrb++ is just for hub reading and writing.
Anyway, can this ptrb logic also be easily tied to mov instructions?
I'm not even sure if this would be a good idea or not though...
Wait a minute, that doesn't make any sense at all, never mind...
I guess it's easier to keep a buffer in HUB than in COG RAM, right?
Think I'd need self-modifying code to do receive buffer in cog ram...
Actually, what I should do for this case is use LUT as a buffer...
Could there by something like MOVP and WRLUTP instructions that worked with the cog/lut address in PTRA/PTRB and also allowed PTRA++, etc.?
Even if that made any sense, it's probably a big change now...
Indirect addressing inside cogmemory is now done with the ALTS/D/R and ALTI instructions instead of self modifying code.
ALTI allows also to modify the pointer, just like PTRB++.
Andy
Still, at 3 MBaud, I've got only ~26 clocks between bytes.
A write to hub can take up to ~16 clocks and I need to do two separate writes.
But, I just realized that if I combine these two writes, as Chip suggests, with WRFAST or SetQ, then it should be fine.
Still, the code to do serial receive is tiny and there's all kind of space in this cog.
I could do ALTx as Ariba and evanh suggest, but that just looks complicated.
Anyway, I switched my code to use the LUT as buffer.
Maybe that's the best way anyway.
Another benefit is that (at least I think) I don't have to worry about the index rolling over the end of the LUT address space. I'm going to assume that the cog only looks at the lower bits of the address and ignores the upper bits that are outside address space.
1. setq only works with wr/rdlong and not wr/rdbyte
2. when setq used with ptra, the value of ptra is not changed after wr/rdlong
3. there can be no instructions between the setq and the wr/rdlong
Is this right?
That's all correct.
Are you close to releasing the new V15? FPGA images with the new FLTx and DRVx instructions?
I could do that on Monday.
Glad to hear your making good progress with your recovery too!
Well done!
It says: Shift D left by S with zero written to bit 0. If wc is specified the C will be set if the msb of the result = 1
But, I think this is wrong. Doesn't the C flag get set by the last bit shifted out of MSB?
Yes. If D was $0001_0000 and you shifted left by 16, C would equal 1 if WC was used.