Getting more out of the P2...
Seairth
Posts: 2,474
in Propeller 2
Brian Fairchild wrote: »Given the complexity of the P2, and the lack of inbuilt peripherals, what it really need is something like PSoC Creator.
Hopefully, P2 isn't so complex that people suppose everything must be configured ahead of time, before their main program runs.
Programs that dynamically reconfigure the hardware will get a lot more out of the chip.
Is that true? In most cases, I'd think the peripheral configuration is going to be static. Yes, there will be some neat designs that dynamically use the same I/O for different purposes, but I suspect that will be in the minority. Or are you talking about something else?
I think our core manual doesn't need to be that big. Examples can take lots of room, but descriptions shouldn't. Everything in the Prop2 is intended to be thoroughly understood and exploited. There are no black boxes inside.
Personally, I prefer having a simple code example accompany each instruction. Now, this might not be a big an issue with assembly language instructions, but I think it's indispensable for higher-level languages. Given the old adage of "a picture being worth a thousand words", a code example is the picture.
Comments
Those customers that need targeting if the P2 is to see any volume sales, and hence survive, will not be interested in any sort of dynamic configuration.
The ability of make a chip with your own mix of USARTs/SPIs/I2Cs/DACs/ADCs/PWMs/COUNTERs/... is the selling point. Today you have a chip that's a communications hub, tomorrow, using the same inventory, it's doing SMPSU duties. But these are different PCBs.
I fully agree.
Wordy descriptions are prone to readers guessing the meaning.
To me, good documents for areas like Smart Pins will have:
* Descriptions with equations, that show the limit cases and dynamic range.
For things like the smart pins, the examples can start in ASM, and expand to include Spin / C etc.
( I see ersmith already has a SpinP2 in very early form )
The big problem with a nice pre-configuration app is that it could give people the wrong idea that such a thing is necessary. I remember back in the late 80's, I bought Borland Turbo Pascal and was reading all about how some insects have wings and others don't, but they all have legs. This was about inheritance and polymorphism. I just wracked my brain trying to figure out how I was going to write a parser and assembler using inheritance and polymorphism. It was a venture into insanity. I was building a taxonomy of op-codes and mnemonics, hoping that when I finally "got it", I would have some legwork already done. I thought that was just how everything needed to be done, going forward. Nothing I read indicated that it was just a scheme to provide some possibly useful feature, but, otherwise, standard programming practices were still the norm. That was a horrible experience and I think it's made me very apprehensive of trendy new tech.
Mainly, though, objects are going to take control of hardware resources, and they will manage them. There will certainly be 'start' and 'stop' methods available for getting things going. If there was a configuration app, it would maybe be better at dealing with objects, as opposed to hardware resources; but, then, the hardware is simple to set up, really, and a call to a method is simpler than a preconfig screen.
Okay, I could see such an app helping people get acclimated to the idea that multiple things can be going on at once. That would have some value for shifting mindsets in the P2 direction. It doesn't seem like something an advanced programmer would use, though. I could be very wrong, however.
The ARM approach I do not much like, uses an API to call lower routines.
Other vendors have a side-tool more akin to a Graphical Calculator, or Configurator.
Taking your PWM on P4 example, users run the Configurator, enter P4 and PWM Frequency and other desired features,
and the tool pops up a few lines of commented assembler/C/Spin etc.
(Better tools will also accept a paste of Assembler, and report back what that results in.)
They then paste that into their project, which manages any "Before and after that," you mentioned.
No API overhead, but it saves a lot of user time 'aligning bits in registers'.
The closest thing in Prop-land to this, is probably ersmith's nifty interactive 'snippet level' Spin2cpp
Okay. That makes a lot of sense to me. That would be very useful. I would use that, myself, because I can't always remember everything. What I really like about it is that it hands you the solution, not some black black connector.
That's also why I think it's important to get the intellisense functionality working in Code. For instance, it should be possible to type "pinsetm", then have intellisense lead you through each field in the mode expression. This, I think, will make direct programming of the P2 more accessible to people that might otherwise have just stuck with objects written by others.
It'll get so many more people over the complexity hurdle too. Prop2 now has a swath of far-off seemingly cryptic registers and many many new special instructions that the Prop1 never had. Thinking about the egg-beater is enough to get some sweating.
There's no doubt, even if the symmetries and directness are still there, that the Prop1's simplicity is harder to see in the Prop2.
I'd rather the time was spent on a config code generator, a separately compilable program, that the IDE would launch. With copy to clipboard and save to file being the means of transfer back to the editor.
This allows it to be generically usable for more than just the Proptool.
Sure. But why not do both? Then we can provide everybody's "cup of tea"!
I don't think I could disagree more.
At the point you design your PCB you are going to connect P4 to some other hardware that needs a PWM signal, something like a bunch of MOSFETs to drive a motor. From that point on you are never going to want to turn that pin into a USART or DAC. That decision occurs before a single line of code is written and is set in stone (or rather copper and fibreglass).
Setting P4 to be low (=0% duty cycle) or high (100% duty cycle) is still a PWM function.
Even something as simple as an IO pin will never be exposed naked to the real world. It's always going to have protection and filtering on it which will forever make it an IO pin.
without a number of volume customers the whole P2 development process will end up as an entry in Wikepedia detailing a curious chip, with some interesting ideas, that never quite made it to the mainstream.
Out of the box, the P2 occupies a strange middle ground between a traditional microcontroller and an FPGA. Look at the datasheet expecting to see a uC and you'll see a chip with few in-built peripherals, an average amount of memory and an unspecified performance. You want something to use as a communications hub? Sure it can do that BUT you'll have to write your own bit-banged USART code in assembler. Or pick something from a user contributed library and massage it to make it work in your design. So if you're going to have to write your own hardware why wouldn't you go the FPGA route? It's a path with a lot more history and resource. And multi-vendor support.
I see your points. You may be right.
FPGA's are really tedious to program. I'm only doing it because it will turn into a P2. It's rewarding, for that reason, but it's also very stressful. It's taken me all day to get back into the streamer block in order to add 4/2/1-bit modes. Software would be so much easier to deal with than this. Anyway, FPGA's are not something you can casually use, like a microcontroller. So, I hope we get to that niche you are talking about, between FPGA's and microcontrollers. We want to be close to an FPGA in flexibility and speed, but much easier than your average microcontroller to program. Maybe setup tools in the IDE are a big step to getting there.
You are right, the Prop 2 will not be a common or garden traditional micro-controller. I'm very sure it was never intended to be. There certainly would be no point in Parallax trying to compete with all the existing MCU vendors with yet another "normal" MCU. Why would anyone buy it, from a little company that nobody has ever heard of when they can use their familiar PIC, AVR, MIPS whatever micro-controller. Parallax could never match them on price or performance anyway.
No, the Propeller has to be different. It has to be able to do things that the others cannot, or do them more easily. Otherwise there is no point in the exercise at all.
That "strange middle ground between a traditional micro-controller and an FPGA" seems like a good approach to me. As Chip says configuring an FPGA is a whole other world of complexity and time sucking tools.
Yes functionality like UART, I2C, SPI, whatever will have to be written in software. I don't see that as a problem. Someone will roll their sleeves up and create whatever device(s) they need. Once it's done once everyone else gets to use them. I did not have to write a UART or SD card driver or external memory interface etc for my projects. I just use what is available.
Will this plan be a success? Who knows?
I am very glad there are people in the world crazy enough to try such things though.
Both angles can be catered. The config code generator gives speed and certainty to regular setups and the hard-core hacker still gets to come up with obscure gems.
http://www.xmos.com/news/3-aug-2010/xmos-customers-build-better-products-faster
Parallax needs to do the same with the P2.
More thoughts later; the other day job calls....
Prospective customers for the P2 will ask what advantages it has over the XMOS range, and Parallax had better be ready with some answers.
I might speculate that branding the P2 as an FPGA replacement might backfire. Those looking for an FPGA may skip over it because it's not an FPGA. Those looking for an MCU may skip over it because it's not an ARM.
Here are some examples of interesting FPGA designs for DSP, but this doesn't appear to be a good fit for P2:
http://www.andraka.com/gallery.php
I've been involved with projects which use FPGAs for PCIe interfacing, but the P2 isn't going to due PCIe in software. I don't think that higher speed USB or gigabit Ethernet is going to happen in P2 software either?
So I just don't have the experience. Do the lower end FPGAs ship in consumer products? Or is the interest more for industrial control? I thought it would be easier to think about P2 versus FPGA with some specific products in mind.
BTW - for ASIC design a lot of companies are now using tools such as Simulink for DSP simulation and design. The tools spit out usable (but ugly) Verilog. They generate software versions as well - I've seen the latter used to generate C simulation models. This is just done to get chips out quickly - from concept to tapeout is less than a year. Once DSP designers learn how to use the tools, then they can generate a lot of verilog, and thoroughly test it. I know a guy that works on ~4-5 chip projects at once. The verilog code can be run in simulation, FPGA emulation, other emulation, and used for the actual ASIC design. It's all generated with block diagrams, and can be quickly simulated at that level to see that it meets the performance goals. The previously mentioned engineer is even able to use genetic algorithms for filter design. Just mentioning this because it doesn't match Chip's experience "FPGA's are really tedious to program." Not that I completely disagree with the sentiment, but for this type of DSP work I think the ASIC/FPGA design is easier than writing P2 code.
(Reference http://www.mathworks.com/solutions/fpga-design/?requestedDomain=www.mathworks.com)
No not a good fit for the Prop. As you said, block diagram style. Everything is pre-built for Lego style mix'n'match.
Chip is making a lot of new features that aren't in any Lego set, and what little may exist as pre-built will come with a licensing arrangement and fixed interface that Chip has no control over (Something he's explicitly avoided) and potentially bloated too (C++ made a lot of software much much slower).
So, Chip is grinding all the logic level possibilities as he comes to them. He's writing all the HDL by hand.
So tout it as having the simplicity of an MCU with the flexibility of an FPGA ?
I still have 20pcs more or less.
The Configurator also needs a report facility for the various configurations selected.
I understand their necessity on other micros, where there might be crossbar limitations or rules that must be adhered to, but P2 won't be similarly confined.
We'll certainly need examples of common configuration modes, which is no problem and doesn't need a tool
I guess its not a big deal either way. Perhaps a visualisation/configuration tool that runs on the P2 itself could be interesting