DC22 Thoughts
JonnyMac
Posts: 9,105
To say that I'm having fun is an understatement. It's a bit heady seeing my name and URL on the back of every badge, and the reaction by some on meeting me has been amazing. Yesterday, three young guys came up to me to shake my hand. At first, I thought it was a prank instigated by Rick, but they were genuine. They even bought me lunch! As we were sitting at a table and all had laptops, I gave them a mini class in Propeller programming (they all knew other languages so they picked it up very quickly, and really seemed to enjoy it).
I'm traveling with my friend, Rick Galinson. Some of you have met him or know him from his Propeller-controlled paintball mini-gun. Rick is a wizard in the FX world, and a practical guy; he just makes things work. We're both getting a lot of attention with a shield that we built that fits on the badge. It's got 10 WS2812 LEDs that we're running color patterns through. Simple, and in the dim light of casino, looks great. What people are amazed by is that we build a shield and were wearing it on the first day. When they ask how, I flip over the badge and point to my name. “I had the files early,” I tell them.
Rick has been doing lots of work with WS2812 lately, in fact, he just returned from a commercial shoot in Argentina where he was controlling several thousand attached to the suits of snowboarders via radio remote. He happened to bring a WS2812 ring that he could glue onto the buttons of the IronMac shield – he hacked our shield!, and is getting even more attention. It's fun.
My take is this: Given a few moments with Propeller programmer, a lot of fans of other processors can be turned, as it were. As Rick and I would explain the kinds of things we do in our Hollywood projects and how we take advantage of multiple processors, people would frequently say, "I didn't know the Propeller could do that."
We may end up with lots of new friends in the forums, now that more are getting a real taste of the Propeller (that didn't require them to buy anything special). I feel certain that those of us that lead the design (Ryan Clarke, myself, Ken Gracey, Daniel Harris, and David Carrier) made the right decisions about this badge. Yes, it's simple -- it's also a hang-around-your-neck development tool that people are excited about. Part of Ryan's contest forces people to reprogram the badge. This is getting new people to explore the Propeller and they're just learning what we all take for granted.
This badge project was a bit crazy in the beginning, but I'll spare you those details. I'm honored that my friends Ryan Clarke and Ken Gracey asked me to help. It was fun to work with Daniel and David to make it real (and in a real big hurry!).
Finally, kudos to Parallax for embracing the open-source movement. That, too, seems to be making a difference in perceptions. Big thanks to Jazzed and all those (forgive me for not knowing everyone's name) involved in SimpleIDE and PropellerIDE, and to Chip for the release of the P1 in Verilog.
Okay, it's time to get cleaned up and jump into day 3.
I'm traveling with my friend, Rick Galinson. Some of you have met him or know him from his Propeller-controlled paintball mini-gun. Rick is a wizard in the FX world, and a practical guy; he just makes things work. We're both getting a lot of attention with a shield that we built that fits on the badge. It's got 10 WS2812 LEDs that we're running color patterns through. Simple, and in the dim light of casino, looks great. What people are amazed by is that we build a shield and were wearing it on the first day. When they ask how, I flip over the badge and point to my name. “I had the files early,” I tell them.
Rick has been doing lots of work with WS2812 lately, in fact, he just returned from a commercial shoot in Argentina where he was controlling several thousand attached to the suits of snowboarders via radio remote. He happened to bring a WS2812 ring that he could glue onto the buttons of the IronMac shield – he hacked our shield!, and is getting even more attention. It's fun.
My take is this: Given a few moments with Propeller programmer, a lot of fans of other processors can be turned, as it were. As Rick and I would explain the kinds of things we do in our Hollywood projects and how we take advantage of multiple processors, people would frequently say, "I didn't know the Propeller could do that."
We may end up with lots of new friends in the forums, now that more are getting a real taste of the Propeller (that didn't require them to buy anything special). I feel certain that those of us that lead the design (Ryan Clarke, myself, Ken Gracey, Daniel Harris, and David Carrier) made the right decisions about this badge. Yes, it's simple -- it's also a hang-around-your-neck development tool that people are excited about. Part of Ryan's contest forces people to reprogram the badge. This is getting new people to explore the Propeller and they're just learning what we all take for granted.
This badge project was a bit crazy in the beginning, but I'll spare you those details. I'm honored that my friends Ryan Clarke and Ken Gracey asked me to help. It was fun to work with Daniel and David to make it real (and in a real big hurry!).
Finally, kudos to Parallax for embracing the open-source movement. That, too, seems to be making a difference in perceptions. Big thanks to Jazzed and all those (forgive me for not knowing everyone's name) involved in SimpleIDE and PropellerIDE, and to Chip for the release of the P1 in Verilog.
Okay, it's time to get cleaned up and jump into day 3.
Comments
Thanks for all your time with this badge, looks like everyone will benefit from the efforts.
-Tommy
A lot of effort and expense for a badge but I'm sure it will impress!
- Ron
God I wish I was there to see all this. I have been really disturbed by this over the past couple of days.
When the Open Source P1 hit Hac-a-Day and Slashdot I read all the comments there. Shocking. From people who claim to be experienced real-time embedded systems engineers I don't expect such a level of ignorance of their craft as displayed in comments like:
"Not having interrupts is a deal breaker", "If you have don't have interrupts you have to poll for events", "interrupts have lower latency", "You can't enter low power states if you don't have interrupts". "Having multiple cores is good for multi-tasking but does not help reduce latency". Etc, etc, etc. Yep, given the above it seems use of a very large clue stick is required before people even understand how their normal single CPU, interrupt driven, systems work never mind the advantages of the Propeller.
Have fun, I look forward to seeing some DC22 vids soon.
@Heater,
Unfortunately there is a lot of momentum in the direction of interrupts on MCUs whether it's justified or not. I'm hoping to make an impact on those interrupt attitudes with a comparison/contrast project. Right now the "Audio Agent" modem is being developed with an AVR device. Next it will be developed with a Propeller device. I'm hoping to publish a paper or some article that talks about the different methodologies used exploring the advantages, etc....
Just trying to sell Spin ease of use is certainly not enough. Of course the easiest thing to do is just ignore the huge market of entrenched naysayers, and instead develop a way to excite a totally new segment of customers possibly in some existing though untapped market ....
I could under stand if people has said the P1 was no use to them because it's memory is too small. Or because it's raw compute speed is not as good an low end ARM. Or it's too expensive.
But all those comments about interrupts vs multi-core were just incorrect.
I really wonder what Parallax can do to make this more apparent in Propeller fliers, datasheets, manuals whatever.
I have thought about this a lot over the years abd in general I'm come down against it. Putting interupts in the Propeller is so antithetical to the whole Propeller concept. It's like putting wings on a tractor or pulling a plough behind a Cessna.
But there is on interrupt mechanism I might go for that maintains the KISS of the Propeller whilst adding a lot of power:
It goes like this:
1) Have an instruction or special register that allows designating one, and only one, pin as an interrupt source for a COG. At the same time allow it to specify the sense of the interrupt, high or low transition. Perhaps also allow for time to be the interrupt source.
2) When the interrupt event happens stash the current PC and flags somewhere, and jump to its handler. We have no stack so this is not nested interrupts. We have only one interrupt so there are no priorities to worry about.
3) When the interrupt handler is done restore the PC/flags and continue. In COG we have no registers to save or restore so that makes life easier.
This is a very simple interrupt scheme but it allows for one interrupt per COG. We have 8 interrupts, not bad.
This would allow writing of things like FullDuplexSerial without the overheads of the coroutines and polling time and I/O pin that it does. (Yes in the case of FullDuplexSerial in one COG the multicore nay sayers are right, it has to poll and it cannot go to a low power state).
Being able to sleep on a WAITxxx and respond to an external event might even be better than the old P2 multi-tasking as it does allow entering a low power state.
-Phil
Even so if you are waking up at a rate of three times per bit surely you have to then read the input at least to see what happened, then check whatever you need to do for shifting the output and checking the tx FIFO. An interrupt would get you to what you have to do without the instructions needed for polling yielding higher speeds. You could be sleeping a lot longer and so consuming less power.
I wish I had had the time to go... maybe next year.
With 14,000 out there it should get a number of them hooked. The Prop is just so easy to program with its 8 cores (excuse me, cogs).
As we all know, spin is really easy, and in reality is just a subset of many languages with indentation being forced rather than the normal endxxx sequence.
heater,
Yes. Unfortunately the prop is not widely known. Add to that the misconception that it has no peripherals (because they can be almost anything as they are soft) and it has no interrupts and the majority just give it a miss right there.
But really, we have so many soft peripherals that can be included we can just about cover any micro out there (excluding USB and Ethernet which are really processors in themselves if done right) with one device. And we can do that on any pin (excepting VGA which requires a block of 8 and TV which requires a block of 3-4).
And as for interrupts, it is just a mentality thing. There has always been interrupts so they must be missing... Well no, they are not required with the Prop because you just use another core and that then runs real-time.
Anyway, I am preaching to the choir, although we may get some newbies to the prop who may validly ask these questions.
Yup. That was me. I'm embarrassed to revisit all the thoughts I had 12 years ago when I dismissed the Propeller offhand.
I applaud and thank Jon for his hard work on DC22 and N&V, and all the other ways he has demonstrated the capabilities of the Propeller. That still seems to be the best way to get the attention of mule-headed individuals like me. Still, it's difficult to communicate the ease with which some otherwise difficult things can be done, or the enjoyment that engenders.
Anyway that is the point of my hyper simple interrupt scheme for the Propeller in post #9.
Currently FDS has two threads or "coroutines", tx and rx, constantly ping-ponging between each other with JMPRET. That means the processor never sleeps, can't get into any low power state, and latency/jitter is high due the over heads of that ping-ponging and polling.
In the current FDS those guys criticizing the Prop for the lack of interrupts are correct!
With that simple interrupt scheme the constantly running threads could be replaced by a background thread and an interrupt handler. Low power state will be entered when waiting on a pin or counter. The over heads of polling are removed.
Would including interrupts in a new chip design be difficult? The marketing guys job would certainly be easier. Telling experienced people they don't need something they've been depending on for years might not be the best marketing strategy.
Interrupts would also be handy when you run out of cogs. There will never be enough cogs no matter how many you include on the chip.
The other thing you could do is rebrand coroutines as a form of interrupt. No, I don't think that would work. That's more like time slicing so again, the interrupt guys wouldn't be happy. Marketing is all about making people happy. It's not about what people need, it's about what people want.
Sandy
I'm kind of pondering that idea that that one interrupt per COG put together as simply as possible and made simple to use may be of benefit in some cases. I have heard this argument many times. Made about all kinds of tweaks and features that could improve Propeller performance at the cost of making the chip more complex and being quite hard and obscure for the user to actually use. We had a year or two of such debates about the P2 until the resulting design was scrapped because it was far too complex and power hungry.
"Those who don't understand it don't have to use it" - Problem is it's not true. Such complex and twisty features will end up in all sorts of code in OBEX and elsewhere where it may wring a little bit more performance out. All users are then affected. They now have a pile of libraries and objects, written by some Propeller guru, that they will never understand. From what I have been reading recently it's a major concern among people who don't understand how interrupts work in the systems they are using already! Changing your product from a Mini to a tractor because there are a bunch of farmers out their wanting to pull ploughs does not seem like a better idea to me. Sure you can put a plough hitch on the back of your Mini but those farmers are not going to buy it because it's not a tractor. Or notice how Ford did not have a horse in front of the Model-T
Those who want interrupts can buy any number of other MCUs that do interrupts very well. Making the Propeller into a pale imitation of an ARM would not be a good move. People will just complain about how awful slow it is and move on anyway.
All users ( programmers) should be exposed to complex code, it will help bring their game up. Advocating against interrupts because the code might be too complicated for some people just doesn't make sense to me. I struggled to understand some of Chip's code when I first started learning ( I'm still learning ) and eventually I did understand it and that experience, though difficult, was a good one. I learned a lot. I could have just plugged the code in and used it ( no understanding required ) but where's the fun in that?
If I promised never to upload code to OBEX that contained interrupts or other complexities would that be acceptable? :-)
Sandy
On a normal CPU I could provide some functionality in a library that uses interrupts. Even if users never have to know how my interrupt code works they have big problems integrating my code. Do they already use that interrupt? Will it take critical time away from some other processing they have going on? What other libraries can they now not use because of this one? Do they need to carefully balance interrupt priorities to make sure everything gets time when it needs it? How does this new thing play with that real-time scheduler I'm using? And so on...
I'm probably OK with complex code provided it is self contained and isolated and cannot affect whatever other components I have in my system at run time or make my system difficult to integrate.
That is one of the major strengths of a multi-core propeller and the Spin object system.
Keep it up!
I saw Ken Gracey on his way out and he seemed pleased. This was a risk for Parallax, and I think it paid off. Part of the contest forced the users to re-program the badges which caused a lot of people to look at Spin. I didn't encounter a single person (even practiced C programmers), who had any problem with it I lost count of how many ad hoc coaching sessions I did, offen standing in a hall somewhere, holding my computer in one hand while typing with the other (along with those I was coaching). My voice is absolutely shot.
More kudos to Parallax for embracing open source. The decision to release the P1 got a LOT of attention. This small step may also drive more to consider the Propeller. With easy tools like Spin, a nice C compiler, and lots of other language choices, I think we could see a spurt in Propeller users. The next step is for Parallax to follow up and finish the Propeller 1.5.
Jon
Rick Galinson and I tried to be the Pied Pipers of new Propeller programmers. There were a fair number of kids at DEF CON and we did our best to interact with them. I keep saying it, but our decision to make the badge a development board was the right one. My IronMac shield excited a lot of people and for the newcomers, demonstrated why we put all those empty pads on the board. It was really fun witnessing the "Ah ha!" moments of those that are new to microcontrollers. Rick and I intend to go to DC23 -- hopefully, we'll be joined by a lot of Propeller programmers.
What kind of battery does it use?
This whole badge / dev kit idea is totally inspired. Who came up with that I wonder?
Not sure why old dog C programmers would have a problem with Spin. C does not cause brain damage as is said of BASIC
I can imagine the release of the P1 design did get a lot of attention. It's a historic moment. I don't know of any other MCU in current production, or even ever, for which the design has been open sourced. I'm told the Sun Spark was released while still in production back in the day.
It was a surprise to me. I did not expect such a release until the P2 was in the stores. If ever.
"Propeller 1.5"? I did not know there was such a plan...
Ray,
It's got a 3 cell AAA battery holder on the back.
What I meant is that none of them complained that it was not C.
I was graciously treated to lunch by three young guys on Saturday during which I coached them in Spin. I suggested that they could build a mini laser-tag game from the badges and on Sunday that had done it. That was very gratifying.
I thought that's what the scaled-back P2 was being called.
The badge / dev-kit idea isn't new per se, but in every other example I've seen (including mine) the users only had limited pins and needed to de-solder components to free-up more.
What IS new was the use of those circular pads which you can use to detach the existing components with. The word "ingenious" doesn't even begin to cover it. I am beyond impressed with the simplicity and utility of this design.
I do have questions about the power circuit design but I'll open up a new thread for that one.
Jon, exceptional work.
I wondered about that. Your voice definitely changed towards the end of the weekend. You're a great teacher btw, I would have loved to have selfishly got some of your time to get more advice and depth in my own work. You had a seemingly endless stream of people hungry for knowledge and I was not going to get in the way of that!
__red__
Agreed, but I hadn't seen it in a DEF CON badge, and especially as we made it on this badge. I ceated my IronMac shield (and have decided to release the files later today) to put my money where my mouth is. I pushed pretty hard for that feature. I'm glad the group accepted it and I sincerely believe that it will encourage many to experiment. We were very careful to ensure that all pads are on even 0.1" centers so a person could use regular perf-board to make a simple shield.
Thank you. To be fair, it was a huge team effort. Ryan (1o57) called me, we called Parallax, and then we knuckled down. I did the rough badge layout, Ryan refined the shape, David Carrier and Daniel Harris (of Parallax) and I worked on the circuitry (based on the QuickStart). We did our best not to use anything new because we had to go from idea to into full prouction in about two weeks. We couldn't find 14000 integrated IR receivers. Daniel and David found a compatible circuit with parts that could be over-nighted and dead-bug tested. Once the layout was approved, David did the final trace routing and then the badge went back to Ryan for art that applied to the crypto game (and he had to do some of that on his honeymoon!). Finally, David panelized everything for production.
Let's not forget Jen and the rest of the production and testing staff. This was a monumental undertaking.
Those really aren't new, either. We found a size that was small enough to be discrete, yet large enough to deal with using a razor or soldering iron.
That was a bit crazy, and humbling, and mind-boggling. Was a lot of fun for me, though, seeing eye light up and those "Ah ha!" moments of people understanding the code, and then wanting to jump in and modify it. I'm glad we did get to meet and chat a bit. Well done on your badge hack.
Not quite right; with a scheduler one CAN be in a low power (WAITCNT) state and do a poll taking 3 instructions every 35 uSec for 9600 baud. That's a pretty low duty cycle at close to 1 in 1000, and certainly what I would call low power. At higher baud rates, of course that gets degraded linerarly.
Cheers,
Peter (pjv)
Yes, possibly I was a bit presumptuous when I said "FDS...it has to poll and it cannot go into a low power state". One can certainly imagine a full duplex serial driver that waits on a time tick and then looks around for what to do thus going to sleep and saving power.
However:
1) The actual famous FullDuplexSerial object does not do that. It runs full speed all the time thrashing between it's coroutines.
2) FDS works up to 115200 baud. I believe others have even faster versions. Can an FDS that uses WAIT actually be written that can do that speed? Has anyone written an FDS that uses WAIT at all?