Just as a point of reference, I am presently running a test program to check the performance of the scheduler, and I find it can simultaneously run three 115,200 channels transmitting continuously, while also receiving one 115,200 stream. These are NOT bursts but continuous. I believe this to be about the limit of what I can muster. At somewhat slower speeds, say 38,400, I expect it will handle considerably more, probably 8 transmitters, or 4 simultaneous streaming transmitters and receivers.
I have not delved into the details of keyboard or mouse protocols, but at the 10KHz-ish speeds you mention, they would have negligible impact. It would be a fun thing to see how much could be pushed into a single cog. I would bet that keyboard, mouse, I2C, (100KHz), LCD driver, 7seg LED mutiplexer, OneWire comms could all readily be done in one cog. Since I have not messed with the video (no need for it), I'm unsure what impact that would have, but I have some ideas I'd like to try.
For me the Holy Grail would be to drive Ethernet directly..... no PHY chip.... again, I have some ideas but not enough lab time!
Keyboard / Mouse is a piece of cake compared to receiving 115,200 [noparse]:)[/noparse]
re/ Eth
I believe someone managed 10Mbps transmission, but could not manage reception due to the overhead of Manchester decoding.
I think 10Mbps reception might be possible for small packets by throwing several cogs at it.
Two cogs for reception - one listens for a packet, then writes it to the hub ... and while #1 was writing to the hub, #2 listens for the next packet. if 100% wire rate reception at 10Mbps is not required a single "raw" receiving cog may barely suffice.
Then have several cogs (I suspect at least two) to Manchester decode and error check the received "raw" packets.
Fun intellectual exercise.
Personally, I'll just keep using ENC28J60's
Regards,
Bill
pjv said...
@Bill & Jazzed;
Just as a point of reference, I am presently running a test program to check the performance of the scheduler, and I find it can simultaneously run three 115,200 channels transmitting continuously, while also receiving one 115,200 stream. These are NOT bursts but continuous. I believe this to be about the limit of what I can muster. At somewhat slower speeds, say 38,400, I expect it will handle considerably more, probably 8 transmitters, or 4 simultaneous streaming transmitters and receivers.
I have not delved into the details of keyboard or mouse protocols, but at the 10KHz-ish speeds you mention, they would have negligible impact. It would be a fun thing to see how much could be pushed into a single cog. I would bet that keyboard, mouse, I2C, (100KHz), LCD driver, 7seg LED mutiplexer, OneWire comms could all readily be done in one cog. Since I have not messed with the video (no need for it), I'm unsure what impact that would have, but I have some ideas I'd like to try.
For me the Holy Grail would be to drive Ethernet directly..... no PHY chip.... again, I have some ideas but not enough lab time!
I would prefer to hold off until I can do a proper write-up as the intended method of using the scheduler requires some insight or knowledge on the part of the user. I would not say that its unfriendly, just that there are a bunch of implications for your application code. Just to give you an idea, it took me three months of experimenting and tinkering, trying at least a dozen different approaches to come up with this result of a 20 (optional features 25) instruction scheduler. It seems pretty rock solid, and performs like a dream, but you can screw it up royally if you don't write your application in a compatible manner. Of course that is also dependent on how much you are trying to squeeze out of it.
So let me know if you can wait -I'm off to China the week after next, maybe I can write it on the plane.... 13 hours UGGG- otherwise I will send you a copy on a "user beware" basis.
Cheers,
Peter (pjv)
P.S. My 2010 contest entry has an earlier, less elegant·version, but it does work. Perhaps you would read, dissect and·absorb that. The current version·takes a bit more "twisted thinking".
I'll wait... we've got Oshkosh coming up anyway... this would just be a diversion that I don't need right now. [noparse]:)[/noparse] But it is definitely something that we could use and I'd love to help test it out for you.
I won't have time to look at it for two-three weeks. I have to finish testing the new PropCade board, and I have five other large designs to build and test!
Yeah, I remember when I flew to HK it was a 14 hour ride squished like a sardine...
pjv said...
Hi Bill;
I would prefer to hold off until I can do a proper write-up as the intended method of using the scheduler requires some insight or knowledge on the part of the user. I would not say that its unfriendly, just that there are a bunch of implications for your application code. Just to give you an idea, it took me three months of experimenting and tinkering, trying at least a dozen different approaches to come up with this result of a 20 (optional features 25) instruction scheduler. It seems pretty rock solid, and performs like a dream, but you can screw it up royally if you don't write your application in a compatible manner. Of course that is also dependent on how much you are trying to squeeze out of it.
So let me know if you can wait -I'm off to China the week after next, maybe I can write it on the plane.... 13 hours UGGG- otherwise I will send you a copy on a "user beware" basis.
Cheers,
Peter (pjv)
P.S. My 2010 contest entry has an earlier, less elegant version, but it does work. Perhaps you would read, dissect and absorb that. The current version takes a bit more "twisted thinking".
Bill Henning said...
I am pretty sure it is exactly the same (or functionally the same) as the code posted in the original threads that talked about saving/restoring flags... which I could not find!
Not entirely sure if that's the right thread as the one thing it doesn't define is saving both flags [noparse]:)[/noparse] Direct flag manipulation in assembler
jazzed said...
@kuroneko, can you do C&Z save/restore in 3 longs?
Provided there is one single point of failure^wrestore, yes [noparse]:)[/noparse] I had a look a while back when I updated Phil's macros but couldn't be bothered. May have some ideas later today ...
' save/restore C&Z
muxc restore, #%00001 ' save C
muxz restore, #%10000 ' save Z
restore shr $, #%01110 wc,wz,nr ' restore C&Z
test code (demoboard)
VAR
long storage
PUB null | n
dira[noparse][[/noparse]16..23]~~
repeat n from 0 to 3
storage := n
cognew(@entry, @storage)
repeat until storage > 3
outa[noparse][[/noparse]16..23] |= (storage & 3) << (n * 2)
repeat
DAT org 0
entry rdlong outa, par
test outa, #%01 wc ' force carry
test outa, #%10 wz ' force zero (inverted)
save muxc restore, #%00001 '
muxz restore, #%10000 ' save flags
not_z muxz $, $ wz,nr '
not_c muxnc $, $ wc,nr ' scramble current flags
restore shr $, #%01110 wz,wc,nr ' restore flags
muxc outb, #%01
muxnz outb, #%10 ' inverted
or outb, #128
wrlong outb, par
cogid cnt
cogstop cnt
fit
Yes as far as I found, saving takes 2 instructions. Restoring can be done in 1, plus of course the long. Chip's code in the interpreter works for restoring and uses the lower 2 bits. I found a way to use the top 2 bits which could mean you could use another variable. Just at the moment I cannot recall which program I used it in. IIRC the restore is shr xxx,#31? wz,wc,nr
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@Cluso, the PS/2 keyboard does indeed send different codes depending on whether it's in num lock mode -- it's not just a light. The particular keyboard which caused the problem was a Storm numeric-only stainless steel hardened keypad which has no num lock annunciator. I had to detect the alternate codes (arrows, pgup, pgdn, etc.) and translate them to the numerics on the same key in case the operator didn't have it in the right mode. When I switched to the prop I was able to send it commands to force it into num lock mode and lock it so the mode couldn't be changed.
@localroger: Thanks for the info. I must confess as you have now pointed out, when I did the 1pin code I did not test the numlock mode and presumed it was the same. However, as you said, it could be controlled from the prop code. Since others have numlock lights on their laptops, it is curious I don't on the one with the numeric keypad. Of course my other 2 laptops don't have numeric keypads anyway. Anyway, it was a thought to save pins since we are nearly always short of them.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Just as a point of reference, I am presently running a test program to check the performance of the scheduler, and I find it can simultaneously run three 115,200 channels transmitting continuously, while also receiving one 115,200 stream. These are NOT bursts but continuous. I believe this to be about the limit of what I can muster. At somewhat slower speeds, say 38,400, I expect it will handle considerably more, probably 8 transmitters, or 4 simultaneous streaming transmitters and receivers.
I have not delved into the details of keyboard or mouse protocols, but at the 10KHz-ish speeds you mention, they would have negligible impact. It would be a fun thing to see how much could be pushed into a single cog. I would bet that keyboard, mouse, I2C, (100KHz), LCD driver, 7seg LED mutiplexer, OneWire comms could all readily be done in one cog. Since I have not messed with the video (no need for it), I'm unsure what impact that would have, but I have some ideas I'd like to try.
For me the Holy Grail would be to drive Ethernet directly..... no PHY chip.... again, I have some ideas but not enough lab time!
Cheers,
Peter (pjv)
WOW! That is very impressive!
I can't wait to try your scheduler.
Keyboard / Mouse is a piece of cake compared to receiving 115,200 [noparse]:)[/noparse]
re/ Eth
I believe someone managed 10Mbps transmission, but could not manage reception due to the overhead of Manchester decoding.
I think 10Mbps reception might be possible for small packets by throwing several cogs at it.
Two cogs for reception - one listens for a packet, then writes it to the hub ... and while #1 was writing to the hub, #2 listens for the next packet. if 100% wire rate reception at 10Mbps is not required a single "raw" receiving cog may barely suffice.
Then have several cogs (I suspect at least two) to Manchester decode and error check the received "raw" packets.
Fun intellectual exercise.
Personally, I'll just keep using ENC28J60's
Regards,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 7/9/2010 9:32:32 PM GMT
Bill
I would prefer to hold off until I can do a proper write-up as the intended method of using the scheduler requires some insight or knowledge on the part of the user. I would not say that its unfriendly, just that there are a bunch of implications for your application code. Just to give you an idea, it took me three months of experimenting and tinkering, trying at least a dozen different approaches to come up with this result of a 20 (optional features 25) instruction scheduler. It seems pretty rock solid, and performs like a dream, but you can screw it up royally if you don't write your application in a compatible manner. Of course that is also dependent on how much you are trying to squeeze out of it.
So let me know if you can wait -I'm off to China the week after next, maybe I can write it on the plane.... 13 hours UGGG- otherwise I will send you a copy on a "user beware" basis.
Cheers,
Peter (pjv)
P.S. My 2010 contest entry has an earlier, less elegant·version, but it does work. Perhaps you would read, dissect and·absorb that. The current version·takes a bit more "twisted thinking".
Post Edited (pjv) : 7/9/2010 10:02:15 PM GMT
Bill
No worries!
I won't have time to look at it for two-three weeks. I have to finish testing the new PropCade board, and I have five other large designs to build and test!
Yeah, I remember when I flew to HK it was a 14 hour ride squished like a sardine...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
I didn't see Bill's save/restore. Best I can do is this (not tested):
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
' save/restore C&Z muxc restore, #%00001 ' save C muxz restore, #%10000 ' save Z restore shr $, #%01110 wc,wz,nr ' restore C&Ztest code (demoboard)
VAR long storage PUB null | n dira[noparse][[/noparse]16..23]~~ repeat n from 0 to 3 storage := n cognew(@entry, @storage) repeat until storage > 3 outa[noparse][[/noparse]16..23] |= (storage & 3) << (n * 2) repeat DAT org 0 entry rdlong outa, par test outa, #%01 wc ' force carry test outa, #%10 wz ' force zero (inverted) save muxc restore, #%00001 ' muxz restore, #%10000 ' save flags not_z muxz $, $ wz,nr ' not_c muxnc $, $ wc,nr ' scramble current flags restore shr $, #%01110 wz,wc,nr ' restore flags muxc outb, #%01 muxnz outb, #%10 ' inverted or outb, #128 wrlong outb, par cogid cnt cogstop cnt fit▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz