What to do with my BeMicro CV???
Rsadeika
Posts: 3,824
in Propeller 1
Is it really coming up on a year for the release of p1v? And is it really coming up a year for my BeMicro CV board to be in the closet? So, I guess the big question is, is anybody doing anything with their BeMicro CV board that has gone past the original experiments?
I know originally I had loaded the p1v image, if that is what it's called, and I think I had an LED blinking with some Spin code, not sure at this point. Since all of the p1v stuff is in the search realm, I do not even know where to find anything, especially the original speculation as to what the BeMicro CV could do, or could not do, with the p1v image.
Now that fall and winter months are coming up, I probably could allocate some time to experimenting with my board again, but where does one begin. I think I dumped my Altera software, but I am not sure. But another big question is, what could I possibly gain from this endeavor? More long compile waits just to get the thing to work like a Propeller, and then what, blink an LED? Maybe the board should just stay where it is and ...
Ray
I know originally I had loaded the p1v image, if that is what it's called, and I think I had an LED blinking with some Spin code, not sure at this point. Since all of the p1v stuff is in the search realm, I do not even know where to find anything, especially the original speculation as to what the BeMicro CV could do, or could not do, with the p1v image.
Now that fall and winter months are coming up, I probably could allocate some time to experimenting with my board again, but where does one begin. I think I dumped my Altera software, but I am not sure. But another big question is, what could I possibly gain from this endeavor? More long compile waits just to get the thing to work like a Propeller, and then what, blink an LED? Maybe the board should just stay where it is and ...
Ray
Comments
Do you have any ongoing projects? Past projects? Was there ever a time you said, "I really wish the Propeller could ....?" Some people wish the Propeller had more HUB RAM. Others more cog RAM. Someone even stuck a hardware UART on there - I think that's one of my favorites. I know if I were to get into P1V right now, I'd be working on a hardware full-duplex UART so that I could receive messages without requiring either a dedicated cog or a blocking function call! That issue has been a major pain point in my current project.
Significant increases in HubRam have been achieved, but the SPIN compiler may not be able to service all the additional HubRAM until something evolves.
Forth may actually just accept it as empty dictionary space and allow it to be useful after the Forth interpreter is loaded within the reachable SPIN compiler boundaries.
A variety of speeds have been explored and other performance enhancements. There is more, but I think I need to formalize a complete listing with a related who is who to make it all seem worthwhile.
I just got my BeMicroCV and BeMicroCVA9 about a month ago, and had to catch up on what has been done. Progress is still occurring (leisurely pace) and the BeMicroCV is still very useful. The BeMicroCVA9 created a buzz as it seems to put the Propeller 2 on FPGA into the hands of more users on a tight budget.
The BeMicroCV remains cheap at $50USD.
The BeMicroCVA9 is vast for the ambitious and reasonable at $150USD.
PIV works on both, but no LEDs on the CVA9. CVA9 has LEDs and it also has a RJ-45 for LAN interfacing.
Where am I?
I have been attempting to evaluate swapping a bigger EEPROM to the BeMicroCV so that it loads from the EEPROM, exactly like the Propeller1 by first having a daughter board replicate the actual modification to the BeMicroCV board. (Seems important to me.)
After all, I did get the Propeller 1V code to work, but reloading from USB every time you power up is not what I desire. The LEDs do successfully indicate which cog is active (but active ones are the unlit LEDs, not the lit ones -- a bug in the code somewhere... still looking for it.).
My own exploration path is to get the EEPROM to boot the BeMicroCV, and then get pfth Forth 1.03 or Tachyon Forth 2.0 loaded to manage the SDcard already included.... with the conventional P1V image.
Only after those support features are in place do I care to seek out the more exotic modifications. For a long time now, I have felt Forth is ideal to explore microcontroller architecture and modifications.
These days, I have been working around my actually damaging one of the i/o Pins on the BeMicroCV that equals Pin 29 on the Propeller while trying to get the EEPROM to work. That is causing delays in me reporting back. I have to learn how to live with one damaged i/o pin. But I must say that using Forth, it was very easy to quickly confirm the damage.
For me, the long-term personal dream is to create a Propeller-like architecture, but with CPUs specific to Forth and following C.H. Ting's eForth concepts. There may be some enhancements in performance, and there may be a few other surprises along the way.
The BeMicroCV (A2) and BeMicroCVA9 have the LEDs connected such that they're on when the outputs are LOW. In my Github repo, the CVA9 has code in the top level module (BeMicroCV-A9.v) to invert them:
module bemicrocva9 ( input DDR3_CLK_50MHZ, input CLK_24MHZ, output wire [8:1] USER_LED, input [4:1] DIP_SW, input [2:1] TACT, inout wire [40:1] J1 //inout wire [40:1] J2, //inout wire [80:1] J4 ); //... snip ... wire[8:1] cogled; assign USER_LED = ~cogled; // ... snip ... p1v p1v_( .clock_160 (clock_160), .inp_resn (resn), .ledg (cogled[8:1]), .pin_out (pin_out), .pin_in (pin_in), .pin_dir (pin_dir) );I didn't change the BeMicroCV code as far as I can remember but it's been a few weeks. I'll create a similar hardware-specific top module for the BeMicroCV and other targets as I did for the CVA9, but at this time the LED inversion for the CV happens (or should happen) by way of a define in the project settings, which gets interpreted in features.v and is used as parameter in dig.v:
module dig ( input nres, // reset input (active low) output [7:0] cfg, // configuration output (set by clkset instruction) input clk_cog, // cog clock input input clk_pll, // pll simulator clock input (2x cog clock) input [31:0] pin_in, // pin state inputs output [31:0] pin_out, // pin state outputs output [31:0] pin_dir, // pin direction outputs output [7:0] cog_led // led outputs to show which cogs are active ); parameter INVERT_COG_LEDS = 0; // ... snip ... assign cog_led = cog_ena ^ { 8{|INVERT_COG_LEDS} };Are you saying that stopped working?
===Jac
Whether the LEDs go on with an active Low or active High is a tiny problem in the world of my 'to do' list. I mentioned the bug because it might upset others that are new to FPGAs and expect to get exactly what the Readme.txt asserts.
+++++++++
I am much more conflicted by having to pay $8USD (including shipping) each for EEPROMs (if I order 5) to attach to me BeMicroCV and CVA9. I can't find an SMD EEPROM anywhere within Taiwan, must import. I want these very badly as they will make the whole FPGA P1V experience more like a true Propeller 1.
Damaging the BeMicroCV has put me on notice to be much more careful with the i/o. I do cover the unused i/o pins with a blank ribbon cable plug, and protect the back of the board.
++++++++++
I am very keen on the idea that the Quartus II might actually allow me to re-route and somehow recover the Pin29 as my testing indicated that the input/output function still works. Only the high/low fails.
I am thinking there is a 50/50 possibility that might work. But I may be dreaming.
It is still worth a try and I haven't had time to investigate this.
If I can't recover, I have to drag out the soldering iron and reconstruct the daughter board I built, and then recode the i/o from the standard P1V example. I guess I should just give up and order the SMDs and forget the whole daughter board scheme.
I also need to confirm that the damaged Pin29 is not the default that is hardwired to the SMD eeprom on the BeMicroCV. That would be a huge disappointment. Tons of Altera documents make for distraction.
I do remember that the first batch of P1V related things had a minor difficulty, which was with some LEDs that were on when the P1V was started up, Then Chip provided a second download with the problem corrected, now I am not sure which one is the first download file and which is the corrected download file. My dates on files are the same date, so that is of no use.
Now, I also remember that I did not tamper with the board, so I think that board still contains the P1V program. I guess I will just have to start up the board and see if anything happens. I also noticed that I used SimpleIDE C program to do the blinky program, in a separate COG no less. So I guess I did do some stuff with the board.
Now, where do I go from here. Since most of my "real" Propeller experiments always show that I get very close to running out of HUB ram, maybe that is an area to investigate. So, a P1V with 256KB or maybe 512KB of HUB ram? But, I do notice that in order to use that extra HUB, with todays tools, SimpleIDE C would be the only way to go. Their is a small problem, using SimpleIDE C, it has to use LMM or XMM to gain access, which everybody says is a bottle neck. If their was a way to get around this, then one could use Spin or a rip roaring C, I think. At this point I am not really sure if SimpleIDE could be used with a P1V 256/512KB setup.
Most of the P1V related stuff that I have seen does not really contain a downloadable .zip file that you could just simply have the Altera package do its work with. Most of the stuff is simply a text file that shows what was done, for beginners like myself, this is very bewildering (personal opinion). Having a lot of things scattered and some very terse material, is also a bummer, not sure what the next step should be.
Ray
Jac Goudsmit has his own repository of updated P1V that is good. The Parallax code may be outdated and troublesome. Quartus II V14.xxx should be fine for the CV, but not the CVA9.
My comment on the CVA9 not having LEDs was an error. I revised my entry above to reflect the reality that it certainly does have these.
========
I have had the afternoon free to finally dig into what I have to do to divert the Propeller P28 and P29 to the on-board SMD EEPROM and made a lot of progress. I may abandon trying to ever revive what I call P29 in P1V.
The BeMicroCV_A2 documentation has some typos that make the whole project a wee bit more work. J1 is PinHeader_A and J4 is PinHeader_B. BeMicroCV documents provide a photo with both J1 and J4 labled PinHeader_A.
I am not quite finished, but I have been writing up a HOWTO to reassign the Pin28 and P29 in P1V to the on-board SMD EEPROM. I'll share that soon. And I will order my expensive SMD EEPROMs from abroad (grr...).
+++++++++
Hopefully, having a simple HOWTO for replacement of the smd EEPROM to something that will hold a bootable Propeller binary will make the BeMicroCV more fun.
In theory, I can just as easily do the same on the BeMicroCVA9, but you may have noticed I spent a few hours sorting this out for just the CV so far.
Conclusion -- the Pin i/o declarations in a device with near 200 i/o pins in use can lead you on a merry chase. If one really desires to use all the features the board has to offer, take some time to comprehend Altera's methods and how these apply in Quartus II. To get the onboard SDcard active, a similar diversion procedure needs to be done.
I am happy that I finally took time to do this research. This is fun, and very interesting.
The PDF is there for those that desire something that cannot be changed in order to prevent errors from creeping in.
The spreadsheet format allows more create use, such as assigning cross-reference to the Propeller pin notation and data sorts into whatever you feel is best for you personally.
Pins are all in Altera notation. I believe the schematics are the most reliable reference. Listing may have errors creep in.
PinHeader_A is J1 on the BeMicroCV schematic
PinHeader_B is j4 on the BeMicroCV schematic
The Edge Connector (an 80 Pin interface) is J2 on the BeMicroCV schematic and appears to use entirely separate i/o pins -- not shared with PinHeater_A or PinHeader_B.
This one can continue with its original purpose.
Some early datasheets of the BeMicroCV had the LEDs assigned to the wrong FPGA pins (i.e. swapped), and Chip used one of those documents to wire up the LEDs in Quartus. This was easily fixed by correcting the .qsf file. I also remember adding the code to invert the LEDs for the BeMicroCV.
I don't remember if those problems were fixed in the official code drop from Parallax into Github, but they are certainly fixed in all branches of my P1V repo, even though the Master branch is frozen for now, until Parallax picks up my Pull Request or we find any other bugs.
===Jac
Swapped LED pins are not very serious in terms of the overall scheme. This does explain one thread on the Forums complaining that the wrong LED was lighting.
While my BeMicroCV_A2 pdf with its Page TOW and mislabeled photo seems awkward enough, the BeMicroCVA9 document downloaded as an open Microsoft Office document.... not a good bit of document control.
I immediately printed a PDF of what arrived to assure that it remains intact.
++++++++++++++++++++++++++++++++++++++++++++++++
Documentation errors do drive off users that are a bit timid. So it is important to mention errata. Thanks.
===Jac
So far I have learned that the provided schematics seem to be the primary reference to the boards AS BUILT.
And at least the BeMicro technical writers have as much trouble with typos as I do. I am not sure that the Altera technical writers are involved... different company, different quality control.
Quartus is Altera.