Using propeller-load with DE0/DE2 board?
pedward
Posts: 1,642
I read that Dave was going to focus on propeller-load, but it seems to not have the syntax to support multiple files and offsets like p2load.
Is there a solution like p2load (or a secret option) for writing to the SPI flash?
I would like to burn my arcade font text console to flash so it will automatically load it.
Is there a solution like p2load (or a secret option) for writing to the SPI flash?
I would like to burn my arcade font text console to flash so it will automatically load it.
Comments
Chip posted simple Flash loader.
programmer.spin
Thanks,
David
It would be nice to preload chunks of code or data into specific memory locations of the FLASH, so they preload into HUB memory. I just ordered a 624J600 ethernet MAC controller eval board to write an ethernet driver for the P2. I intend to implement the higher level protocol in C. Right now we are hand assembling images and doing our own linking because the development tools are in flux. I don't have any qualms with this, I would just like the ability to FLASH the chip.
I did review the programmer.spin, and it could be altered fairly easily. One of the limitations I have is a DE0, so I don't have a monitor COG available to poke data in and reclaim HUB space from the programmer.
Funny thing is, the Atmel SAM7 series has a monitor program that runs via USB serial I/O too. When dev tools weren't available for Linux I wrote a program that used the monitor to poke data into RAM and write it to flash memory, so it's highly likely that a command and control program could twiddle bits and such via the monitor and not require a loader.
As for images, we are constrained by what the dev tools will produce. If PNut is making obj files, that is going to cover 99% of the development needs until the tool chains are all available. For SPIN/GNU interoperability, you really need to have that conversation in context with Roy. If you want merged object file formats, he will need to add support to oSPIN to support it, then ELF works all around (except PNut).
I'm thinking that the next step for me is to write the AES-128 reference code, since that was put-off because it was unneeded in the initial ROM.
I mostly work in PASM, Spin ---- In time I'm clear with my Basic -- In that to.
But "C" -- I only look on code if I can convert it to them I use !!
I've built the p2test branch specifically so I could start using it for larger programs, however I am running into some limitations (that should be easy to address)
1) the LMM kernel needs to run on cog 1 (or 2..5) as video drivers MUST run in cog 0 on the FPGA's
2) an easy way to incorporate pnut.obj driver blobs (which may exist, perhaps I just need some info on how to do it)
3) a way to specify the last hub address the elf executable may use (so we can reserve frame buffer space) ie $8000
For many usage cases Spin will still be better due to a smaller footprint.
p.s.
I'd also love it if you expanded p2load to allow reading/writing/erasing areas of the flash chip . Please allow 4K block erase of the flash.
So, if these problems were addresses would you make more use of PropGCC for P2? While this is true to some extent, the CMM mode of PropGCC is nearly as compact as Spin and a lot faster on P1. We won't know about P2 until there *is* a Spin for P2. :-)
This brings up another point, it has been possible to program P2 in Spin since late December or early January. You just use Eric's spin2cpp and then compile the resulting C++ code with PropGCC for P2. I'm going to look into this tonight. Actually, I'm going to look into writing flash. I don't plan to support reading stuff back from flash at this point. After all, p2load is a *loader*! :-)
You should take a look at my P2 Serial Debugger (see the thread). It runs on the DE0 and runs/resides mostly in LMM/hub. It has a built-in debugger and monitor that can examine and change hub and cog. There are also routines you can call to send/receive characters/strings/hex etc. Your code just makes a call to these routines. From the debugger, you can return to your user program, or force a restart at any cog location, or reload the rom monitor. Shortly I will be adding a coginit to it as well.
I think this would probably help you with your debugging.
For my purposes, I want to code in PASM, and I'm none to keen on the GAS syntax. SPIN isn't just the SPIN interpreter, it also encompasses a compiler, assembler, and linker. I do appreciate the ease and high level integration the SPIN language has with the hardware and PASM, and I appreciate the ability to manage memory resources with SPIN (hence my question the other day about how to get the HUB address for a statically linked resource).
I plan on writing my ethernet driver in PASM and writing the IP stack in C. I may write a SPIN version too because it fits the ecosphere that surrounds the chip.
SPIN as a language is surprisingly close to the hardware and without many hidden things, unlike compiled C code that foists the calling convention framework upon the chip and makes generally ugly code, not to mention the code density issues.
I personally find SPIN and PASM development to be quicker and more in my comfort zone, than C. While I would consider myself a C expert and I've written tons of C code, it does have a certain lack of polish when considering the Propeller processor, and the subtle incompatibilities that exist with GAS.
Truth be told, I'll be writing C code for the Prop 2, so in time I'll become more comfortable and familiar with that specific toolchain.
I'll take a look. I wrote the TTY driver specifically to have a console to see debug output. If I had a DE2-115, or real silicon, it would make life much easier.
Having the limitation of 60Mhz in the FPGA has actually been valuable in making the render code as tight as possible, so when the real chip comes around you can either underclock it or have a bunch of extra cycles to do interesting things interleaved in the render code.
As it stands, I've got my main loop to 16 clocks, with 1 NOP, and it's doing 2 hub reads in that timeframe, so it's really getting a lot of bang for the buck.
The video circuit has to be updated at 4Mhz when the dot clock is 30Mhz, so that means at 160Mhz there can be ~40 clocks between WAITVID calls, providing another 25 clocks to do something during scanline rendering.
Re: LMM in cog1
Thanks David. Here is the code I use in my pasm code to do this.
I think if this is added in front of crt0.s (lmm, cmm, cog etc) it should work as-is.
Re: driver blobs
Thanks.
Re: limiting gcc to below $8000
Thanks.
Short Answer:
Yes.
Long Answer:
Yes.
Due to consulting, other product work and family, I don't have as much time as I'd like to play with the P2 as is... which is why I have not dug in and addressed the three points I brought up, myself. Instead, I've been working on drivers and understanding this powerful beast.
LOL!
What does the code that the Spin compiler generates look like? My understanding is that it does no optimization at all. GCC with the -Os option generates pretty good code. It may not be as good as you can do in assembly but it's still good enough for outer loop code and certainly way faster than Spin bytecodes. Even CMM code is faster than Spin bytecodes and almost as small.
I also don't understand how Spin is closer to the machine than C or even better matched to the Propeller. What Spin features make it particularly well matched to the Propeller other than a handful of runtime functions like cognew, etc that also appear in the PropGCC library? I guess you must be refering to the bewildering collection of obscure operators. C has been accused of having obscure operators but it is nothing compared with Spin. :-) What lack of polish? If there are runtime functions that are missing from the PropGCC library we can certainly add them. In fact, if the Propeller community would embrace PropGCC, they could contribute code that would make it easier to use C on the Propeller. This is Parallax's product just as much as Spin is. Let's all try to make it as good as we can so they have the best chance of success with P2 that is possible. Like it or not, how well C runs on the P2 will have more of an impact on its success than how well Spin runs. When you start using please let us know about your experiences and how you think this Parallax product can be improved.
Thanks!
David
I really hate the ugly kluge that the C compiler does for stack calling and variables. It wastes precious hub cycles with the r0..r15 convention. I bet this hasn't gone away with the P2 even though it actually has a per-COG stack, because you likely want to keep all this data in HUB so you can migrate it between COGs.
SPIN has a lot of conventions that mirror the hardware, such as the INX/OUTX and DIRX pseudo arrays. And now with the REPX PASM instructions, it's the hardware mocking SPIN, since SPIN had it first.
Really though, in C you are stuck with loops like this:
for (i=0; i<10; i++) {
foo
}
And once you've written it such as:
repeat 10
foo
And now in PASM:
REPS #10, #1
nop
call #foo
It's hard not to look down on C because the efforts to make it modern have actually just made it more complex instead of removing complexity.
But hey, that's one of the inherent things about C. I program a lot of PHP, and it is basically C with a lot more convenience and I've come to appreciate that convenience and lack of protocol and rigidity demanded by C.
But I really do hate the ugly calling convention. When you spend so much time writing tight code, then blow your budget in the stack frame build up and teardown, WTF is the point? I'm talking about small functions that may be called a lot.
It is unfortunately a common problem among all microcontrollers that have C. FWIW, Metrowerks CodeWarrior for the HC08 produces much more elegant looking code IMHO.
Perhaps we should suggest to Parallax that they abandon the PropGCC project.
I've learned not to make such statements in my career, they stem from a case of over zealousness and don't represent your true feelings.
The real fact is that "C" is just the least common denominator when dealing with programming micros or computers. The trend has been more towards interpreted languages and rapid development, outside of the need to grok C code.
If you look at the job listings, you might believe that Ruby On Rails is the new hotness, but the fact is that it's just the last in a long line of what was hot. As languages have gained acceptance and maturity, they lose buzz and something else comes along.
Witness PERL->PHP->Python->Ruby
I believe that SPIN is a more modern like language, though it borrows convention (indirectly) from many different languages.
Pascal is represented
C is represented
Python is represented
BASIC is represented
While I say they are "represented", with the exception of Pascal, there was no attempt to emulate any existing language, but rather to develop a language that was modern and worked well with the hardware.
I don't think it's a coincidence that SPIN looks like many well understood and used languages, yet was developed exclusively of those -- great ideas come to more than one person.
I intend to leverage existing C code for implementing the TCP stack, looking for an open source tiny TCP stack, then write the glue to make it work with PASM and the Ethernet hardware.
SPIN is my first choice for developing on the Prop because it doesn't carry a draconian penalty and allows me to do rapid development. C can do that with Steve's SIDE, but there needs to be an effort to make it work as simply as BST (I cite BST because it's a good developer extension of proptool).
I personally have had my fill of make, grep, and vi for developing software, now that I've been using Eclipse for a few years.
I'm not really a fan of the C programming language. It's just that it gets the job done in most cases and lots of people know it. No one knows Spin and that is a big deterent when it comes to adopting the Propeller. I guess if you could provide some other standard language that would be fine also. Spin is not a standard language.
"The Propeller Elite" is an interesting phrase, and one worth adding to the lexicon in a good way. Many of us were here from the beginning, or near the beginning in my case, not sure about everybody else. Pretty sure Bill was on board before me, for example.
When I bought a Demo Board, the idea that the chip is a concurrent multi-processor without interrupts and spiffy features like video generators was way too much to ignore. I did worry about learning and effort required to put it to use. To be frank, SPIN + PASM is something a curious person can make do stuff in a day. Powerful stuff.
We didn't have C then. In fact, it took Ross really thinking about it and developing Catalina into a darn nice, darn easy C enviornment, and the formation of the Prop GCC team and all that work to really get C moving forward to some real potential, and that all took lots of boot strapping type efforts and some discovery thanks to Bill leading the way with LMM, and a failed C effort.
Right now, C is working against the center of gravity, which is SPIN + PASM. Those of us who have invested in the chip have basically seen Chip's way as the potent way it is, and then we've gone off and added what we could or would and all of that exists out there today. This won't always be the case.
Part of my day job involves working with companies on product design software, processes, data management, etc... I just got done meeting with one today, which is why I'm not propping on my DE2 right now too, but I just got done with the most interesting conversation! And it's relevant to this discussion too.
They are using AVR and PIC devices and they've been doing so for a long time. I mentioned the Propeller and it's features. Mostly P1 features, but I did explain the P2 and those feature / speed / power differences.
Honestly, they were quite interested in something that is a micro controller still, but that offers things they can really use, be more flexible, and or upgrade their control presentation, etc... lots of possibilities.
"Can we program it in C?"
"Yep"
Now, if I were Parallax sales at that moment, it would have been time to act on that interest in various ways, but it was really two guys chatting about tech they like.
This conversation ended with, "What a cool chip! We are gonna have to take a look at some point", to which I offered my contact info if they want an introduction, etc... And I did so as an advocate of tech I like and find valuable too.
"We" and I mean those people who see the Propeller as being worth a conversation like that and who are able / willing to have that conversation need to be able to say that, "Yep" period.
What "The Propeller Elite" do isn't of any consequence. And when "The Propeller Elite" perhaps get a contract to develop, or help with a design win, or some other thing, you can bet your Smile C will look one heck of a lot different than it does right now when we are both having fun and getting to know this new design.
I know how it is for me, and it's exactly that way right now. Not a negative against any of this stuff, just reality. If I didn't have the day job I do right now, I probably would be doing a lot more with C, because I believe it's needed to grow adoption rates overall, and I want that because I love the people, company and the good times I've had on something that should have been a lot harder. Darn cool!
I've had these conversations before on P1, and the moment I say "SPIN and a really easy, beautiful assembly language" they give me the "Okie Dokie" and the conversation moves on. They are done, because they too have time limits, and we've all had that discussion enough times to know better.
That right there is what the work is being done for, and Jazzed, Ken, David, Eric, and others who I should know and mention right now, but am forgetting are doing it so that the answer to the question which comes up all the time is simply, "Yep."
Put this another way, I'll code in PASM + SPIN (when we get it) for *fun*
I'll do it in C when somebody pays me to, or it becomes fun, or I really need it for some reason.
The more polish that's on it, the more fun potential it has and now that we have roomy environments, we might need it, see how that works?
The Parallax C investment, along with anybody else investing in C for whatever reason, is enabling in this way. We need that to happen so that a new "center of gravity" centers around C, and once that happens, more and more falls in and life is good for all involved.
The scenario then for P2 is different! This time, we've got C with us the whole time. SPIN + PASM is lagging some, and that's just due to the order of events. Once there is working silicon, I suspect Chip will get SPIN P2 sorted out and life will be good, but the reality is C will be farther along than SPIN will be, and that "center of gravity" will shift a little.
It's shifting a little right now. Some of the P1 C adopters are going to jump on the P2, and when they do, they will see an immediate benefit. That center of gravity will form right there and begin to work like SPIN + PASM does now.
More of those conversations like I just had will lead to real engagements which will bring new blood into the fold, sales of chips, building of libraries, and all manner of things needed to augment that "center of gravity" to work with or from and help to solidify commercial uses too.
So don't do it. Prop GCC and C in general is needed.
IMHO, what is also needed are some real challenges that will pay somebody and or offer incentive and opportunity and once that is out there, happening, you all are going to see C grow. Maybe they would call and say, "Let's replace this LCD with a video touch display, and...." Guess what? Suddenly C is fun, and it might pay a little, get cracking! That's how it will work more than not I suspect.
None of that can happen, unless we can say, "Yep" and mean it. Gotta do C, and do it well too.
And aren't most of those written in C?
If you take the Propeller out of the context, it then becomes "those that learn FooBAR" and "those that stick to C".
If you count the number of jobs available, less than 10% of the jobs in software development [today] are C based. Then you narrow the scope to embedded software and the focus is on C.
The P2 will make SPIN much less of a compromise because of additional instructions, improvements to the micro-architecture, and raw speed increase (the PTRX and INDX pointers are huge boons).
PropGCC is quite useful on a P1, and getting close to being useful on the P2 emulations now that gas is mostly pasm compatible - some more polishing, and more people will use it.
Once the P2 is released, and shipping in volume, I think we will see a LOT more propgcc users.
The early adopters - people running it on an FPGA - are I think more interested in exploring the capabilities of the P2 (including graphics), mostly in assembler.
Your p2load is very helpful with this
With Eric's SPIN2CPP tool, that might just be a possibility, albeit in an awkward manner.
I think writing a SPIN interpreter would actually be the better way to go, then it would only take, in theory, some work to get OpenSPIN to produce binaries.
I think SPIN and C fulfill different, yet aligned, goals. It's a lot like the difference between writing a web application in PHP vs C, PHP gives you a rich environment that does most of the heavy lifting for making a web enabled application, whereas it would be more tedious to write the same thing in pure C.
FYI, I agree with you - Spin and C are not really competitors, but different tools - each has some set of applications it is better for (or faster to develop with).
An interpreter has been done ... at least twice.
Hippy did a version several years ago.
Dave Hein's simulator can run spin programs.
I'm sorry I brought up this topic. This whole Spin vs. C/C++ discussion has happened uncountable times in these forums and it was stupid to start the debate again. It is clear that the people here like and probably prefer Spin to any other alternative. If they didn't, they would have jumped ship long ago. My only defense is that I thought P2 might be different especially since a number of us worked hard to make C available very soon in the process rather than as an afterthought as was done with P1. I guess that wasn't enough. So, I'll take the advise I gave in another thread in this forum and stop discussing this since it is off topic for this thread. Sorry.
The simple fact is that PNut was available as soon as we had FPGAs, and that is what was presented. PNUT is only an assembler, but most of the current users realize that this is a microcontroller, and as in the past it will be necessary to write code in PASM to extract the most from the chip.
Nobody is writing high level code for the P2, so you can relax.
The early adopters in this group do not represent any part of the cross section of potential P2 users, all of the folks in this group are hardcore Propellerheads and enjoy doing things the "hard" way.