P2 and HyperRAM - Is it just hype or does it have a real use???
Cluso99
Posts: 18,069
in Propeller 2
The title says it all!
I know Roger has spent many man months on this project, and done an amazing job too, but...
Am I the only one that thinks HyperRAM is all hype and of no practical use? And remember, I'm the one that put SRAM on a P1.
To me, if the P2 doesn't have enough RAM then it's the wrong chip for the job. There are so many cheaper chips that can add RAM or FLASH easily, and can address that memory more easily too. And those cheaper chips are based on common CPU architecture, mostly ARM. And they have a mass of tools and software to help too. The P2 is NOT and ARM - and it cannot possibly take on the ARM architecture due to cost, tools and software.
So where could HyperRAM take the P2 into it's own viable niche? Unfortunately, I cannot think of any
HDMI or VGA ?
IMHO P2 doesn't do HDMI well - the Raspberry Pi does this way better, on a single board way cheaper than the P2 chip alone.
P2 does VGA nicely, and up to 2K (1920x1080) too. The P2's 512KB hub ram is rather limited for this, depending on what resolution and color depth you require, but it may just be fine depending on what you need - eg varying sections of the screen with different resolution and/or colors, a hires color text terminal. HyperRAM may be useful here, but IMHO it adds too much to cost and complexity. I'd rather use a R-Pi or something else altogether than add HyperRAM. And I like the P1 and P2 architecture.
Code execution
If 512KB isn't enough, IMHO it's the wrong chip for the job again - too costly and too expensive
But, what message does using HyperRAM send to prospective users ???
This is the part that worries me the most! Seeing HyperRAM on Parallax's base demo boards gives me the impression that the P2 has a lack of resources that need more RAM, and, if I didn't know any better, it would send me looking for another chip! I really hope that the endorsement by Parallax of HyperRAM doesn't send the wrong impression to prospective designers causing them to disregard the P2 right from the outset. It was hard enough to get designers to look at the P1 - we don't want to give them a reason to dismiss the P2 before taking a closer look.
Your thoughts???
I know Roger has spent many man months on this project, and done an amazing job too, but...
Am I the only one that thinks HyperRAM is all hype and of no practical use? And remember, I'm the one that put SRAM on a P1.
To me, if the P2 doesn't have enough RAM then it's the wrong chip for the job. There are so many cheaper chips that can add RAM or FLASH easily, and can address that memory more easily too. And those cheaper chips are based on common CPU architecture, mostly ARM. And they have a mass of tools and software to help too. The P2 is NOT and ARM - and it cannot possibly take on the ARM architecture due to cost, tools and software.
So where could HyperRAM take the P2 into it's own viable niche? Unfortunately, I cannot think of any
HDMI or VGA ?
IMHO P2 doesn't do HDMI well - the Raspberry Pi does this way better, on a single board way cheaper than the P2 chip alone.
P2 does VGA nicely, and up to 2K (1920x1080) too. The P2's 512KB hub ram is rather limited for this, depending on what resolution and color depth you require, but it may just be fine depending on what you need - eg varying sections of the screen with different resolution and/or colors, a hires color text terminal. HyperRAM may be useful here, but IMHO it adds too much to cost and complexity. I'd rather use a R-Pi or something else altogether than add HyperRAM. And I like the P1 and P2 architecture.
Code execution
If 512KB isn't enough, IMHO it's the wrong chip for the job again - too costly and too expensive
But, what message does using HyperRAM send to prospective users ???
This is the part that worries me the most! Seeing HyperRAM on Parallax's base demo boards gives me the impression that the P2 has a lack of resources that need more RAM, and, if I didn't know any better, it would send me looking for another chip! I really hope that the endorsement by Parallax of HyperRAM doesn't send the wrong impression to prospective designers causing them to disregard the P2 right from the outset. It was hard enough to get designers to look at the P1 - we don't want to give them a reason to dismiss the P2 before taking a closer look.
Your thoughts???
Comments
Hyperram is below $2 and there are at least 4 vendors now
While I tend to agree that other chips are better suited to addressing memory and that the RPi has lots of RAM and does HDMI nicely, the trouble is that it is a board and not a chip. I'm already looking at chip solutions to hires/hicolor HDMI displays myself but that does not preclude the use of HyperRAM either if that makes more sense. As for more code memory .... well, I have no need for it, especially when it is awkward.
The fact that rogloh is devoting time and talent to HR is only ever commendable and a big bonus for the P2 community. Beyond that, what Parallax does and the reasons why we might agree with or not, but it's the same Parallax that gave birth to P1 and P2, so we are all in agreement with them there.
For video applications I actually don't see this as being too big an issue. The actual refresh overhead itself is minimal (5-6 latency clocks per access) and we sort of need to break apart the transfers anyway on this sort of 4uS time scale anyway to reduce latency and allow multiple COGs to share the memory while giving video or audio real-time access with constrained latency. If this chip select time limit wasn't there I would sort of need to fragment things anyway to be able to support video unless the video drivers can buffer a lot more than a scan line at a time which is not convenient when you don't know what you are drawing in advance (i.e if you have multiple regions). Main downside is that video transfers also get fragmented, which probably eats up ~10% of bus bandwidth. I managed to help reduce it quite a bit down to just 11 instructions outside of CS low by not polling between video sub-burst transfers, but all the other per transaction overheads inside CS low time and the address phase will still contribute there.
I don't think the HyperRAM alone needs to take the P2 into a niche. P2 needs to be able to stand on its own two feet there in its own right. HyperRAM just enables more capabilities of the P2, especially in higher bandwidth areas that will need more than 512kB.
For display applications, we already know HyperRAM enables much more now including full screen video frame buffers at higher resolutions with the P2 which would not be possible with HUB alone unless you use a tile based model with its own restrictions. It enables up to 1080p 8bpp on a single chip @ 297MHz anyway (overclocked with V1 HyperRAM, the V2 RAM won't need to be overclocked), making an excellent hi-res control/presentation GUI directly from the P2 to different displays. You could pretty much only achieve 1080p mono otherwise from HUB, or otherwise need to drop back to much lower resolutions like VGA/SVGA.
Other applications where the high speed memory could be useful may be for audio processing or when collecting and analysing larger data sets of high speed data, e.g. for logic analyser/scope capture type of stuff, or maybe some high speed networking if it can be interfaced with the P2.
Later as we expand its use with virtual machines/caching, it could become useful for larger applications too, e.g., think of MicroPython where a considerable amount of HUB memory just gets used for the environment itself reducing the space available for the heap. If (and it's a big if) HyperRAM could be utilized here for some of the heap/application, it may help to alleviate some of the storage problem. It may also become useful for self-hosted development systems where accessing larger amounts of file/binary information rapidly is helpful (vs reading from SD card alone). Eg. you could copy and map a filesystem into the HyperRAM and then read/write temporary/large file data very quickly indeed. Also in self-hosting setups some of Chip's recent graphical DEBUG stuff would be hard to do on the P2 without external memory, but some (subset) of it might be possible on the P2 with external memory.
I'm sure there are other real-time applications where high speed external memory is useful just to buffer incoming data before it can all be processed. Robotics environmental mapping, sensing, vision? Huge external lookup tables? Of course not all P2 stuff is going to need it but there are likely to be some known and unknown P2 applications that could benefit.
Echoes of the infamous "640k should be enough for anyone."
In the end here I'm not 100% sure what you are trying to say. Do you believe Parallax should not support putting any memory on their demo P2 board offerings and only leave it to the customer because it would reduce P2 sales if they have extra memory on their boards? I would hope Parallax has an option of board with no RAM to save costs, but could still provide some option for external RAM if this is desired by users. A demo/experimenter board in particular is useful to have that can cover multiple applications, some of which may not need the RAM, some which might benefit from it. If you end up limiting what your demo board can do, it may also limit what people imagine that the P2 can do, especially as demos get developed that show off the applications possible. I don't imagine having two different demo board options will suddenly turn off a whole bunch of customers.
Other chip designs support external RAM/ROM in their system implementations and breakout boards. The ESP32 seems to be supporting PSRAM options for expansion nowadays. Does that cause a lot of people to disregard it, I wonder? Unless you always know all the application's requirements in advance and it won't ever expand from there I think a device that doesn't demonstrate an ability for memory expansion may be the one to avoid. I would rank a system that can be expanded as far more capable than one that cannot, and that would go in it's favour, not against it.
There was no more die space for more than 512KB unfortunately
So IMHO, we have to live within 512KB.
I have yet to see an area where a P2 with hyperram can operate in, let alone outperform alternatives. So, what are they???
IMHO, P2 needs a niche (actually many niches). P2 will never gain mainstream attraction because it will always be too expensive, and the tools will never be as good as, mainstream chips, and its' architecture is unique. This is an unfortunate reality, which also existed with the P1. But the P1 was developed in an era where multicore micros were (virtually) non-existent, large ram was uncommon (8K was a luxury), 8-bit micros were the norm, and on-board video generation was unheard of. Unfortunately P1 still did not find mainstream acceptance.
These days, many micros are 32-bit, they have a large array of peripherals which in a lot of designs can be mapped to almost any pins, there are multicore designs, standard architectures (ARM, PIC, RISC-V, etc), powerful development tools, and lots of sample code. And they are cheap as chips.
Please, show me where I'm wrong!
I think Cluso's point is that we should not go down the same dead-end path on the P2. Instead of decrying the lack of RAM on the P2 (and 512kb is a "lack"? Sorry, I don't think so!), let's concentrate on things the P2 does that no other chip in its class can do (I am thinking parallel processing applications here!).
Sure, HyperRAM has its uses - but (as Cluso said) extending Hub RAM is probably not one of them.
Ross.
** apologies to Harry Harrison!
The hyperbus interface is very attractive for high bandwidth and it's certainly a great experience pushing well beyond the clock rating of the parts and seeing them perform still. And that's under non-ideal conditions of the Eval Board accessory connectors.
The Edge with the hyperRAM should have notably improved characteristics compared to an Eval Board. Having a common performant platform will allow a standard set of timing parameters to be used to get the best out of the hyperRAMs.
Well I think HDMI will replace VGA soon and using Hyperram for Video ram makes a lot of sense. I am not sure why TWO of them should be used, IMHO that take way to many pins.
In my understanding Parallax wants to build 2 Edge module versions, one w/o Hyperram and one with two of them.
Not sure why you claim that the tools never be as good as other architectures, with VS code and the Clang/LVM c/c++ compiler we have now a functionable C/C++ solution, Roy works on them simple library files, Catalina works and FlexC seems to get more and more standard stuff implemented as needed.
Sadly I do not like C /C++ much.
Spin2 from Chip is quite confusing for me because of the inability to place things in HUB where you want them, what I used on the P1 a lot. FlexSpin is more cooperative there but tries to mimic Chips Spin2 so it might get more complicated there too.
As you found out in pure PASM one can place stuff into HUB where one wants,it would be nice if SPIN2 would allow that too.
But external Ram could solve that problem too, Spin2 can stay relocatable but one would have fixed external addresses for data /buffers/XMM-code(?).
Another interesting use would be a RAM disk loaded at reset from SD. Chip uses a nice concept of chaining programs to load the debugger, basically the debugger blob loads itself into higher HUB and then moves the main code down to HUB 0 and starts it.
Mram would be also interesting...
But I do understand your argument and agree with you that the basic module should not have any ram, and most examples/objects should run without external RAM.
How is the current state of CP/M on P2, can I test it somehow? Any chance to upgrade to MP/M, according to the old thread that needs to be started from a running CP/M system and will then support multiple terminals and some basic network file system to combine more then one P2?
curious,
Mike
"P2 Edge" - for those who like living on the edge
"P2 Fledge" - for those wanting a basic reliable introduction
Its true that HyperRam needs more application based testing, to learn its traits and limitations. But if anything thats a call for going deeper rather than shying away
64Mb should be helpful with audio synth / blending for starters, I think its around 45 seconds of CD I2S sound. Hub would be 1/3sec
I don't understand your resistance.
Your very own Propller 1 product (RamBlade) has 512KB of SRAM doesn't it?
Surely you don't believe people are going to think P2 is only good for emulating 70's 8 bit CPU's and old operating systems?
The two models will be used in different ways not just because of the RAM chips. The Edge without HR will have all I/O exposed on the connector while the Edge with HR only has half.
I totally agree. I use the propeller (P1 and P2) for embedded applications. The ability to connect a graphic diplay is very useful to make small diagnosis tools like handheld scopes, data loggers or even GUI based controls for small machines like label or 3D printers. But as soon as you need full blown hi-res graphics with high color depth or even 3D animations the P2 is defintively the wrong device. A RasPi can do this much better.
For example, take a look at my CNC controller. There are two versions, one for stepper machines and one for servos. Both have one P1 that does the trajectory planning. It is connected to a PC (or RasPi) via Ethernet. The GUI runs on the PC which also serves as fileserver. Two more P1s in a seperate box control up to 5 stepper motors. For servos there is one dedicated P1 per axis.
No other processor can do real time processing of multiple concurrent tasks at once as good as the propeller does. No other processor can deal with custom communication protocols as well as the propeller. But there are limitations. It is not wise to use it for tasks it doesn't do well as (high end) graphics.
And I'm also a bit worried about the current P2 community. Don't get me wrong, you are all very clever and sympathetic guys. But as we see at the zoom meetings, most of us (including me) have grey hair and a beard. I fear it is quite likely that we live in our own bubble and most of the outside world doesn't care much about what we are doing. All those retro-computer things are funny and interesting applications for propellers but Parallax won't make much money out of it.
To get attention (ans sale numbers) from a bigger community we need to focus on thing the propeller can do better than other processors. That is:
* real time signal processing
* quick prototyping
* "real" multitasking (without time-slicing)
* bit-banging of non-standard protocols
* high IO-count applications where other µC are too limited
I think that the Hyper-RAM extension is a nice-to-have feature as last resort. But it shouldn't be included as a standard in most boards. As Cluso said, this would give the false impression to newcomers that the P2 is short of resources even for the most common applications.
Things are very different now. Micros run over 100MHz, multicore, and 32-bit are common, and 512KB of internal RAM is also obtainable.
I can do plenty of things with P2 without the need for external RAM.
IMHO demonstrating examples using hyperram well before other basic demos are done sends the wrong signals. We need examples that show off the P2 without peripheral chips, otherwise the P2 cannot shine. It is bad enough there is no internal flash.
P2 doesn’t have any internal peripherals like normal chips do, so we need drivers that add (emulate) these peripherals easily. We don’t need external chips to overcome deficiencies - demos with external chips only serve to highlight any deficiencies.
We desperately need the USB that GarryJ wrote made in to a proper object now. Again, adding external USB chips just doesn’t cut it these days.
IMHO WiFi, Bluetooth, and other RF, are the exceptions where external chips are ok. Other very specific chips like the DOF chips are exceptions too.
The arguments they made are very valid indeed. I'm a newcomer to the propeller and only came to this camp for the reasons ManAtWork so accurately described. And my hair is also mostly gray, no beard however
Nothing to stop anybody to do whatever one wishes with the P2. Impossible has been proved possible many times already so why not again ?
My answers to Cluso's questions are fairly simple. No and yes. Just not for everybody.
Of course, I'm also fond of the EVE2 GPU, but adding that chip adds a layer of complexity to the system, that sometimes you don't want.
One day, it might also be useful for code execution. I'm curious if XIP would work with P2...
The other potential use is high speed data collection. Could be used for a high speed digitizer at long length...
Agreed. I like HyperRAM because of what it affords for another $2, but most things don't need it.
RAM or not, more objects people can use will help more people get going.
Right now, including RAM for early development makes sense.
Is this the best / right RAM? Maybe it is, but I think the question is valid.
As more objects get added, maybe other kinds of modules will make sense. Maybe leaner P1 style things continue to make sense? It is not like all that is useless, right?
PS/2 mouse and keyboard, for example. Super lean, comparable with P1. On P2, serviceable by an interrupt too. User will barely notice it.
If all the stuff being done is big, expansion RAM will be needed.
So maybe address this question with lean objects that do not need much RAM?
Like the P1, video generate is better than the on chip RAM. Unlike the P1, a reasonable, very useful subset is easy, not too RAM hungry.
I was thinking the other day about mixed mode tile / character displays. Say we has 80x50 text, just for discussion. And it is color, IBM style.
Now say on a per character basis one could include 8 bit bitmap graphics. Not just redefined characters, but graphics from a buffer. This gets overlayed onto the screen where needed. Have a list, or map that describes it.
Now, the P1 way of doing things gets a real face lift and is still lean. Use the P1 graphics.spin library approach too.
Suddenly, a 640x480 HDMI display gets super useful and remains RAM lean. Higher resolutions make as much sense that way too. User just defines buffers, points at them to draw, etc and it can all be loaded when needed.
On that topic, I feel strongly about being able to load in RAM at target address. I know, not best practice, but in a multi processor scenario, doing this makes all kinds of sense. It should see more thought, that's all.
And what about SD cards? How fast can the better ones really go?
Say one has a buffer for overlays, 32, 64k worth? Or a few 8k ones?
An SD card loaded up with relocatable ready to go objects may be excellent!
Load "tempsensor.xxx"
Update its object pointer
Do temp sensing"
Repeat for various things as needed, pushing them in and out dynamically.
Anytime it does not need to be real time, why not? Tons of things can happen with few worries and might RAM use. We have respectable HUBEXE now. Doing this kind of thing makes a lot of sense and it has potential advantages.
Say one gets a new sensor?
Compile it, dare I say .dll style, and put it on the SD card.
Either:
Overwrite the old one and the application just works.
cp tempsen.xxx tempsen.xxx.old
cp newtempsen.xxx tempsen.xxx
Or:
Modify higher code to fetch newtempsen xxx and leave both on the SD card for later.
I will stop there.
The point I think I am making is how things can work has a big impact on whether expansion RAM is a thing or not and how often it is.
Maybe some ideas on how things can work might help.