I have no doubt that it will bounce back, especially with snow and cold weather coming. However, in all the years that I have been a member, I cannot remember a time when there was this much inactivity. Of course, I could be completely wrong.
It would be nice if more people posted some of the things they have going on. I always find it interesting to see the different things that people do.
Yes, there have been distractions.. They have been good distractions for the most part, but distractions none the less..
GCC is one of those distractions, however it was neccessary to move the Propeller further toward acceptance in education. Hopefully, we'll see more bounce back as more students are encountering the Propeller in the classroom and the numbers will increase again. Those like myself who are Spin users probably aren't going anywhere, and we are perfectly happy to use the Propeller in it's native tongue.
The FPGA release is another distraction. The end result will probably be another, more improved Propeller chip. The Propeller itself, while awesome is becoming something of the antique in the electronics arena. Don't get me wrong, I love the Propeller, but we are overdue for the new chip. Once either Propeller 1.5 or Propeller 2.0 are pressed into silicon you will definately see the numbers rally back up.
I don't like seeing the focus fractured away from Propeller 1 development, but I do know it is neccessary to keep Parallax moving forward.
Hang in there gang. We'll get new goodies eventually and there will be new (and old) folks who will come out of the woodwork to join the fun again.
In the meantime, find a project that you can plug a Propeller into and get busy enjoying what you have. That's what I've done.
I have noticed a slowdown. maybe the holidays coming up, and everybody concerned
with that.
I have noticed that when somebody posted a new thread, or new idea, they were
greeted with less than positive suggestions, in some cases. Not all advice can be positive,
the truth cuts both ways. Discretion is the better part of valor.
Having said that, I would like to post a fun challege in the near future. I will be expecting
participation.(?) :nerd: Thanks.
Where it states users online (members and visitors), I have seen that area packed with member names, not thousands or anything like that, but packed. Over the last several months, that list has slowly but surely been declining. I went to a forum the other day, I forget whether it was the Propeller or General Discussion, perhaps it was the total forum, but there were only two members in that forum at that time, me and someone else. I think it was the total forum.
While I believe that highest recorded number of users on line, is most likely inaccurate, I do know that this fourm has seen much better days of forum member participation.
As you know, I am not attempting to bash the forum, members, or Parallax, I am just stating an observation, and I wish more people would post, just to keep it highly interesting.
I've been thinking about it and maybe some of us (certainly me) are part of the problem. If people come here and find endless discussions of which programming language is best or even discussions about why no one is participating, maybe that puts them off. Some of us are probably contributing to the low signal-to-noise ratio here. I'll try to limit my posts to talking about actual projects I'm working on rather than trying to defend this or that programming language or chip or whatever.
Thanks for providing this great "call to action" post, idbruce. Speaking of which, please get back to your el cheapo 3d printer. I've been waiting patiently. I just know you're gonna crack the code the day AFTER I spring for a commercial unit.
Patience please....
Either today or tomorrow or the next day, you should be able to see some fine photos of the "Drummond Extruder". It is coming along rather nicely, but occassionally some indecision slows me down.
Where it states users online (members and visitors), I have seen that area packed with member names, not thousands or anything like that, but packed. Over the last several months, that list has slowly but surely been declining. I went to a forum the other day, I forget whether it was the Propeller or General Discussion, perhaps it was the total forum, but there were only two members in that forum at that time, me and someone else. I think it was the total forum.
While I believe that highest recorded number of users on line, is most likely inaccurate, I do know that this fourm has seen much better days of forum member participation.
As you know, I am not attempting to bash the forum, members, or Parallax, I am just stating an observation, and I wish more people would post, just to keep it highly interesting.
I general, I agreed there has been a decline.
I notice on weekends, in the morning, there are only a half dozen members logged in. I do not log in until I have read every post. I hate having threads disappear after I read them.
I really think there are a lot of students logged in as guests and are getting information. They have no reason to post until they have a question. Maybe we have done our job and provided that information.
Yea, there are a lot of guests, and if I had to guess, which I do, I would guess that new membership is up, which is also a good thing. And perhaps the questions of students can account for my belief of new memberships. However, as previously stated, I could be way off base, and we both know that it would not be the first time.
I am sure that Parallax is attracting a lot more students these days, and I am also sure these kids enter as guests before commiting to a membership.
To be perfectly honest, it appears that most of the time, the forum is filled with new comers as compared to the old timers. However there are a few old timers that you couldn't beat away with a stick. Not mentioning any names, but you old timers know who you are
At the heart of it all, I would have to say the spirit of the Parallax Forums is quite intact, and it is warm and generous.
Concerns with traffic are in some ways superficial. The internet is maturing and the way we all use it and interact evolves along with all that. Also, there are seasonal slowdowns that come and go.
As for myself -- I have learned to read the pdf documents rather than just ask someone else to interpret them for me, and I have grown weary of debates or explaining the basics of wiring a relay for the nth time.
From what I can see, if someone is stuck with some code that they just can't resolve, others remain willing to show a possible way forward. Most other forums seem unwilling to do so.
But if anyone is concerned with the slowdown in traffic, try to self-moderate and consider how to be part of the solution... not chase people away.
If I had a final thought .... it would be: I'd like to thank Chip for encouraging me to exercise. There have been many benefits from following through with that such as not caring as much about little things that used to irritate me horribly. Let it go; life goes on.
This has been on my mind lately too, that was the last small nudge I needed.. Paid my entrance for the rest of the year to the gym today. Heck I'm 43 and it's past time to start keeping my health in check. Off topic, but thought I'd you might appreciate knowing you've influenced someone else.
...Maybe we have done our job and provided that information.
Across the years, there have been so many questions asked and so many answered. This forum is replete with great info. Just the other day, a piece of code from Alarus was the perfect solution for the precise inquiry I had. No point in me posting anything.
Still, I check in every day for a minute or two to see if Chip has posted anything about P2, or what pik33 has added to the P1V, or if Kuroneko has solved another intractable problem, or if JonnyMac has posted more sample code... Things like that.
I have been trying to again get back to my Wild Thumper and other projects. However, since my father in law has fallen terminally ill back in Montana that has again been put on hold. I just came back to WA a couple days ago. He is not expected to last much longer and is now on end of life treatment. My wife and her sister have been with him all summer and will be there until the end. It was rather sad seeing the man I considered my own father in the condition he was in. However, I hope this winter brings time to work on projects and will post more frequently.
Across the years, there have been so many questions asked and so many answered. This forum is replete with great info. Just the other day, a piece of code from Alarus was the perfect solution for the precise inquiry I had. No point in me posting anything.
Same here. I have disciplined myself to search before asking. The forum has become a wonderful knowledge base. I do, however, get weary of the threads where the OP constantly asks then answers his own non-prop related questions.
Forum activity may be slow, but that doesn't necessarily signal lack of activity with the P1. I'd venture to say that some of us are as busy as ever. Some projects don't translate well to a public forum and may not be of general interest, anyway. But I for one remain very enthusiastic about the Prop.
Us too! We've got more projects on the prop than we ever have before and can't wait for them to be done enough to show them off!
I have been selling P1 based modules left and right, almost all based on Quickstarts with daughterboards and laser cut acrylic enclosures. You don't even want to know what my corporate masters have been charging for them. Really, you don't. Now that I've got UDP coded for the ENC28J60, which is much smaller and tighter than the TCP stack, I am using these things all over the place to provide network connectivity for sensors and serial devices. In fact, I'm using them almost exclusively now instead of USB to RS232 converters, most of which broke with Windows 7. The one really reliable solution, Digi Edgeports, are almost as expensive as our handmade boxen, and much less versatile. Since I'm also writing the software on the PC this switches us from the serial library, which is buggy as all Smile and gets broken periodically by new Windows versions, to the sockets library which is stable and which also works under emulation without threading.
We have a customer who is installing photo-eyes at each end of all their truck scales, just wanting visual feedback that the beams are blocked as an aid to the scale operators who are sometimes hundreds of feet away. And a few weeks ago our guys broke the pull tape trying to run another wire through the underground conduit for the eyes. But they had a network drop at both ends, and I was able to easily whip up a couple of little boxes to take the photo-eye outputs and echo them to LED's across the network. Seems kind of crazy to throw all that hardware at 2 bits of continuous data, but the alternative was a thousand feet of wire in a busted underground conduit.
Even within the 32KB limit of Spin I've got some pretty amazing stuff going. I've taken several stabs at a larger code dev system, but none ever gelled and now that I see how GCC "works" I'm not sure that's a very good approach. P2 will open up new vistas but P1 is no slouch if you know where to put it. The ability to bit-bang hardware like UARTs and video makes it amazing where it works. And with a Quickstart on the back I can throw together a simple daughterboard for new functionality -- two serial ports, say, instead of a serial port and video -- in a few hours. There's no other platform in the market with that kind of flexibility.
I've taken several stabs at a larger code dev system, but none ever gelled and now that I see how GCC "works" I'm not sure that's a very good approach.
Can you explain what you mean? In what way is it not a very good approach?
Across the years, there have been so many questions asked and so many answered. This forum is replete with great info. Just the other day, a piece of code from Alarus was the perfect solution for the precise inquiry I had. No point in me posting anything.
Aggree with that. I`ve found a lot of answers for my questions here in the forum without posting anything. That said, there`s always new questions showing up and then I feel its time for posting. This forum is really a big information channel and a "goldmine" of solutions. Thanks to everyone again,
Still, I check in every day for a minute or two...
Can you explain what you mean? In what way is it not a very good approach?
localroger: Please explain what you mean by your comment about the approach taken by PropGCC. We would, of course, like to improve our offering and your input might be able to help.
David, I was extremely disappointed by the speed of the byte code interpreter. (You might remember the thread where I ported the SeeedStudio TFT drivers to the Prop ASC). And while true LMM was tolerably fast the object code size was huge. While it should be possible to manage these bottlenecks -- most code in RL applications doesn't need to run fast, after all -- the compiler doesn't generally know which bits of codes are the ones that need to be optimized for speed instead of size. I realize GCC provides some tricks for doing this management, such as compiling PASM overlays, but that gets to a level of complexity and platform specificity which kind of torpedo the biggest advantage of GCC, which is its wide usage and the ease of stepping into it without specific Propeller knowledge.
I had some ideas of my own about building a system for managing those bottlenecks, but that little experience with GCC, which I know benefitted from a large pool of deep skill and experience, didn't fill me with confidence that my own schemes would work much better. Overlays would be out of the question, but I had in mind a rich set of helper functions particularly for string handling (which tends to be a big thing in my applications). And I had in mind a scheme for caching by te codes to Hub RAM, but after seeing how slow the GCC byte code is even in Hub RAM I'm not sure that would give the performance I need either.
I think it's a no-brainer that both C and Spin will benefit enormously from P2's extra resources. In fact on P2 C might win due to the ability to compile code in multiple ways taking advantage of external RAM and Hub execution. It's easy to say in retrospect that maybe Chip should have tossed in some more RAM for P1, but 32K was once quite a bit of memory and Spin is extremely efficient in that regard, it's still a lot of memory when you're comparing to BASIC stamps, and it's easy to say with 20/20 hindsight that there's a huge difference between 32K and 64K but we got what we got.
David, I was extremely disappointed by the speed of the byte code interpreter. (You might remember the thread where I ported the SeeedStudio TFT drivers to the Prop ASC). And while true LMM was tolerably fast the object code size was huge. While it should be possible to manage these bottlenecks -- most code in RL applications doesn't need to run fast, after all -- the compiler doesn't generally know which bits of codes are the ones that need to be optimized for speed instead of size. I realize GCC provides some tricks for doing this management, such as compiling PASM overlays, but that gets to a level of complexity and platform specificity which kind of torpedo the biggest advantage of GCC, which is its wide usage and the ease of stepping into it without specific Propeller knowledge.
I had some ideas of my own about building a system for managing those bottlenecks, but that little experience with GCC, which I know benefitted from a large pool of deep skill and experience, didn't fill me with confidence that my own schemes would work much better. Overlays would be out of the question, but I had in mind a rich set of helper functions particularly for string handling (which tends to be a big thing in my applications). And I had in mind a scheme for caching by te codes to Hub RAM, but after seeing how slow the GCC byte code is even in Hub RAM I'm not sure that would give the performance I need either.
I think it's a no-brainer that both C and Spin will benefit enormously from P2's extra resources. In fact on P2 C might win due to the ability to compile code in multiple ways taking advantage of external RAM and Hub execution. It's easy to say in retrospect that maybe Chip should have tossed in some more RAM for P1, but 32K was once quite a bit of memory and Spin is extremely efficient in that regard, it's still a lot of memory when you're comparing to BASIC stamps, and it's easy to say with 20/20 hindsight that there's a huge difference between 32K and 64K but we got what we got.
Thanks for your comments. I too was surprised that you found CMM to be slower than Spin. I had thought it was between LMM and Spin in performance and I think it is in at least some applications. The one you attempted was clearly an exception. I should spend some time looking at your code to see where PropGCC went wrong in translating it to efficient CMM code. Can you point me to the source so I can take another look?
The final version with the PASM repeat loop is the only one I'd consider practical for use in a non-demo project. What's especially galling is that this unit doesn't use SPI or IIC which need loops to be bit-banged; it uses 12 I/O lines and a byte wide parallel bus.
.. It's easy to say in retrospect that maybe Chip should have tossed in some more RAM for P1, but 32K was once quite a bit of memory and Spin is extremely efficient in that regard, it's still a lot of memory when you're comparing to BASIC stamps, and it's easy to say with 20/20 hindsight that there's a huge difference between 32K and 64K but we got what we got.
The P1 Die is at a maximum, for the process and package selected, so there was/is no headroom for more RAM.
The final version with the PASM repeat loop is the only one I'd consider practical for use in a non-demo project. What's especially galling is that this unit doesn't use SPI or IIC which need loops to be bit-banged; it uses 12 I/O lines and a byte wide parallel bus.
Thanks for the pointers! I looked at the code for both Spin and C a bit and I can't say anything jumped out at me. I guess for at least this example Spin is faster than CMM. In any case, I don't typically choose C or C++ primarily because it is faster. I like writing in a language that doesn't tie me to a specific platform. I know people here will say that what they write in Spin is so Propeller-specific that it couldn't be ported anyway and I'm sure that's true. It isn't true for me though. I tend to write tools and languages and frameworks and the vast majority of that code is platform agnostic. That's why I typically choose C even though it is far from a perfect language.
David, I'm genuinely curious if you can figure out exactly WHY the C code is so slow, especially the loop that draws character bitmaps. It's also odd that C is faster at just clearing the screen without PASM help. Something very strange is going on here and it's probably worth trying to figure out exactly what. Is it function call overhead? The prototype code calls a generic function for every bit plot, and I'm wondering if maybe the expense of building a stack frame or something is the culprit?
David, I'm genuinely curious if you can figure out exactly WHY the C code is so slow, especially the loop that draws character bitmaps. It's also odd that C is faster at just clearing the screen without PASM help. Something very strange is going on here and it's probably worth trying to figure out exactly what. Is it function call overhead? The prototype code calls a generic function for every bit plot, and I'm wondering if maybe the expense of building a stack frame or something is the culprit?
I don't really have time to do a detailed analysis but C can sometimes be quite fast for small inner loops since it runs them directly in the COG using a technique that Bill Henning suggested called "FCache". A small portion of a function is read into a buffer in COG memory and executed directly as PASM instructions. It avoids the LMM or CMM instruction fetch loop so it is quite fast.
David, I'm genuinely curious if you can figure out exactly WHY the C code is so slow, especially the loop that draws character bitmaps.
If you specify the -S flag the GCC compiler will save the generated assembly code in a file with a .s extension. This way you can see exactly why the C code is so slow.
Comments
I have no doubt that it will bounce back, especially with snow and cold weather coming. However, in all the years that I have been a member, I cannot remember a time when there was this much inactivity. Of course, I could be completely wrong.
It would be nice if more people posted some of the things they have going on. I always find it interesting to see the different things that people do.
Yes, there have been distractions.. They have been good distractions for the most part, but distractions none the less..
GCC is one of those distractions, however it was neccessary to move the Propeller further toward acceptance in education. Hopefully, we'll see more bounce back as more students are encountering the Propeller in the classroom and the numbers will increase again. Those like myself who are Spin users probably aren't going anywhere, and we are perfectly happy to use the Propeller in it's native tongue.
The FPGA release is another distraction. The end result will probably be another, more improved Propeller chip. The Propeller itself, while awesome is becoming something of the antique in the electronics arena. Don't get me wrong, I love the Propeller, but we are overdue for the new chip. Once either Propeller 1.5 or Propeller 2.0 are pressed into silicon you will definately see the numbers rally back up.
I don't like seeing the focus fractured away from Propeller 1 development, but I do know it is neccessary to keep Parallax moving forward.
Hang in there gang. We'll get new goodies eventually and there will be new (and old) folks who will come out of the woodwork to join the fun again.
In the meantime, find a project that you can plug a Propeller into and get busy enjoying what you have. That's what I've done.
Jeff
with that.
I have noticed that when somebody posted a new thread, or new idea, they were
greeted with less than positive suggestions, in some cases. Not all advice can be positive,
the truth cuts both ways. Discretion is the better part of valor.
Having said that, I would like to post a fun challege in the near future. I will be expecting
participation.(?) :nerd: Thanks.
That had to be a glitch. I have been monitoring usage for about four years:
http://forums.parallax.com/showthread.php/126251-Most-Users-Ever
Four years ago, it was common to have 200+ logged in, (as guests and members). Today it is 800+.
We never found out about the 17,236 number, but I suspect a blogger attack.
erco brought this up last year:
http://forums.parallax.com/showthread.php/151184-Where-Were-You-on-Oct-23
The most I saw online, (as mentioned in erco's thread), was 1200+. That was when Huminoido was mentioned on Hackaday with his 40 Propeller Skyscraper:
http://hackaday.com/2010/10/08/turtles-all-the-way-down-40-propeller-mcu-skyscraper/
I think 800+ users is a healthy number.
Where it states users online (members and visitors), I have seen that area packed with member names, not thousands or anything like that, but packed. Over the last several months, that list has slowly but surely been declining. I went to a forum the other day, I forget whether it was the Propeller or General Discussion, perhaps it was the total forum, but there were only two members in that forum at that time, me and someone else. I think it was the total forum.
While I believe that highest recorded number of users on line, is most likely inaccurate, I do know that this fourm has seen much better days of forum member participation.
As you know, I am not attempting to bash the forum, members, or Parallax, I am just stating an observation, and I wish more people would post, just to keep it highly interesting.
Patience please....
Either today or tomorrow or the next day, you should be able to see some fine photos of the "Drummond Extruder".
I general, I agreed there has been a decline.
I notice on weekends, in the morning, there are only a half dozen members logged in. I do not log in until I have read every post. I hate having threads disappear after I read them.
I really think there are a lot of students logged in as guests and are getting information. They have no reason to post until they have a question. Maybe we have done our job and provided that information.
We are still buddies, right?
Yea, there are a lot of guests, and if I had to guess, which I do, I would guess that new membership is up, which is also a good thing. And perhaps the questions of students can account for my belief of new memberships. However, as previously stated, I could be way off base, and we both know that it would not be the first time.
I am sure that Parallax is attracting a lot more students these days, and I am also sure these kids enter as guests before commiting to a membership.
To be perfectly honest, it appears that most of the time, the forum is filled with new comers as compared to the old timers. However there are a few old timers that you couldn't beat away with a stick. Not mentioning any names, but you old timers know who you are
Concerns with traffic are in some ways superficial. The internet is maturing and the way we all use it and interact evolves along with all that. Also, there are seasonal slowdowns that come and go.
As for myself -- I have learned to read the pdf documents rather than just ask someone else to interpret them for me, and I have grown weary of debates or explaining the basics of wiring a relay for the nth time.
From what I can see, if someone is stuck with some code that they just can't resolve, others remain willing to show a possible way forward. Most other forums seem unwilling to do so.
But if anyone is concerned with the slowdown in traffic, try to self-moderate and consider how to be part of the solution... not chase people away.
This has been on my mind lately too, that was the last small nudge I needed.. Paid my entrance for the rest of the year to the gym today. Heck I'm 43 and it's past time to start keeping my health in check. Off topic, but thought I'd you might appreciate knowing you've influenced someone else.
Jeff
Unless you mean to infer you are a young guy collecting old bits. There is some ambiguity there.
As far as I can tell exercise at any age is still beneficial. I'm kind of allergic to it myself.
I adopted the nick quite a few years ago.. I'm afraid it has double meaning these days.
Across the years, there have been so many questions asked and so many answered. This forum is replete with great info. Just the other day, a piece of code from Alarus was the perfect solution for the precise inquiry I had. No point in me posting anything.
Still, I check in every day for a minute or two to see if Chip has posted anything about P2, or what pik33 has added to the P1V, or if Kuroneko has solved another intractable problem, or if JonnyMac has posted more sample code... Things like that.
Same here. I have disciplined myself to search before asking. The forum has become a wonderful knowledge base. I do, however, get weary of the threads where the OP constantly asks then answers his own non-prop related questions.
Us too! We've got more projects on the prop than we ever have before and can't wait for them to be done enough to show them off!
We have a customer who is installing photo-eyes at each end of all their truck scales, just wanting visual feedback that the beams are blocked as an aid to the scale operators who are sometimes hundreds of feet away. And a few weeks ago our guys broke the pull tape trying to run another wire through the underground conduit for the eyes. But they had a network drop at both ends, and I was able to easily whip up a couple of little boxes to take the photo-eye outputs and echo them to LED's across the network. Seems kind of crazy to throw all that hardware at 2 bits of continuous data, but the alternative was a thousand feet of wire in a busted underground conduit.
Even within the 32KB limit of Spin I've got some pretty amazing stuff going. I've taken several stabs at a larger code dev system, but none ever gelled and now that I see how GCC "works" I'm not sure that's a very good approach. P2 will open up new vistas but P1 is no slouch if you know where to put it. The ability to bit-bang hardware like UARTs and video makes it amazing where it works. And with a Quickstart on the back I can throw together a simple daughterboard for new functionality -- two serial ports, say, instead of a serial port and video -- in a few hours. There's no other platform in the market with that kind of flexibility.
Thanks,
David
I had some ideas of my own about building a system for managing those bottlenecks, but that little experience with GCC, which I know benefitted from a large pool of deep skill and experience, didn't fill me with confidence that my own schemes would work much better. Overlays would be out of the question, but I had in mind a rich set of helper functions particularly for string handling (which tends to be a big thing in my applications). And I had in mind a scheme for caching by te codes to Hub RAM, but after seeing how slow the GCC byte code is even in Hub RAM I'm not sure that would give the performance I need either.
I think it's a no-brainer that both C and Spin will benefit enormously from P2's extra resources. In fact on P2 C might win due to the ability to compile code in multiple ways taking advantage of external RAM and Hub execution. It's easy to say in retrospect that maybe Chip should have tossed in some more RAM for P1, but 32K was once quite a bit of memory and Spin is extremely efficient in that regard, it's still a lot of memory when you're comparing to BASIC stamps, and it's easy to say with 20/20 hindsight that there's a huge difference between 32K and 64K but we got what we got.
http://forums.parallax.com/showthread.php/157141-2.8-quot-TFT-Touch-Screen/page2
And this is the thread I started with the side by side comparisons (OK grudge match may have been a little provocative LOL):
http://forums.parallax.com/showthread.php/157357-Radio-Shack-LCD-C-vs-Spin-vs-PASM-grudge-match?highlight=grudge+match
The final version with the PASM repeat loop is the only one I'd consider practical for use in a non-demo project. What's especially galling is that this unit doesn't use SPI or IIC which need loops to be bit-banged; it uses 12 I/O lines and a byte wide parallel bus.
The P1 Die is at a maximum, for the process and package selected, so there was/is no headroom for more RAM.