Pyra News: Springs are brilliant!


I think there are some Pyra Related things that the Devboard dosnt have, like Batterie Management, and LCD Display, and this 3 Board Thing..
Or the 3G Module..

Apropos 3G: I just saw i can get 3 Sims whit my Cellphone Tarif: One in my Phone, one for the Smartwatch and the 3th will be for the Pyra ..
 
True, but if I remember correctly, dev-boards are out in the wild since a while.

That doesn't help if the devs have no time.

Well, then going Intel sounds like the logical and les stressful way I guess.

So, throw away around 300k EUR development costs to start from scratch?
The PCB would need a complete redesign, the system would need active cooling (which means a complete case redesign, etc.)
When we started, no Intel CPU was useful. No other CPU was useful.
If we'd start now, we'd probably use the i.MX8, as it has bigger support.
But that one wasn't available back then.

It was a lot of bad luck (or bad timing), but we cannot simply throw 300k development costs away and start anew.
We're no multibillion-Dollar-Company.

Are the quantities of GPD's devices known? It's bigger than Pyra but still really niche devices. Maybe Intel provides programs for small companies who only need a couple of hundred chips. Just to piss of AMD or whatever. ^^"

I'm guessing around 20k GPD Win 2 are out in the wild.

That's actualy....weird...

No. Usually, you only get support from the manufacturer is if you buy at least 100k of their chips.
That's why there are so many generic Chinese tablets out there that all use the same generic design: The manufacturer released a reference design and they simply use that and produce it.
Then they don't need ANY support from the manufacturer.

Only if you add your own stuff is when things are getting complicated.

TIs reference design used 2GB RAM. The 2GB RAM Pyras worked out of the box.
Now just take a look what switching to 4GB RAM has brought us to: about a year delay and around 50k EUR additional costs. Just to get it to work properly.

It's just a small change from the reference design - and this is the result.

I already said multiple times: What we're doing here is something COMPLETELY different to most of the handhelds out there: We're doing TONS of custom stuff, not just using reference designs and putting them into a shell.

You get me wrong. I never sayed it's easy, I just assumed the many years during the Pyra development would have lead to the attention of the "right" people. Because it sounds like most of the "core" Software stuff is not even existant. Of course you need the hardware first, we had hope that going the Debian route would make stuff much more easy and compatible, compared to the quirky Pandora software development.
Not sure if the choosen OMAP is easier or harder to develop for. I guess, today you would look first if the choosen Chip also has propper software documentation and support. This should be a standard in the Chip industry, actualy. At least I hope so. Otherwise it is indeed hard to find people who can code "low level" stuff for an (abandoned) SoC without official support and documentations.

Don't mix up the OS with Kernels or drivers.
Debian is fully running on the Pyra. That's nothing "core" that's just the OS on top of the kernel.
The OS isn't the problem. Kernel things are what's still missing.
The Pandora had a LOT of kernel stuff added by us - luckily, we had notaz back then, but he doesn't have time anymore.

The OMAP5 is VERY well documented. Better than most SoCs out there.
But that's over 5000 pages documentation. Someone needs to implement all the timings, hardware registers, etc. into the driver modules so that everything works fine.

Audio works, but the driver doesn't have DC Offset included. We need to use DC Offset, and the chip supports it - so someone has to read the hardware documentation and include that into the driver.

TI never finished the graphics system properly. That's why rotation with TILER was terribly slow, until zmatt made a quick hack to show it can be done in fullspeed.
But TI didn't have a huge customer who was in need of that - so they never took care about it. And why should they? Android uses OpenGL for the rotation, and that was probably the main use case for the chip.

The OMAP-Series was specifically designed for Nokia-Phones. All Nokia-Smartphones used OMAPs. The OMAP5 should've been the next iteration. Microsoft bought Nokia, and the OMAP5 didn't have any huge customer anymore. The mobile version (which we wanted to use) wasn't even released, only the automotive version.

So yep, a lot of bad luck.

Now, for developers:
Nikolaus knows developers from the GTA04 times. I do know some from the Pandora-times.
They all don't have time anymore. Normal work is holding them up, so they can't really help us. If they help, it's just little things.

We even did ask some companies who are specialized on Linux kernel stuff. They're all overbooked right now.

Times have changed. Back in Pandora-days, there were motivated developers who had fun working on such devices. These days, it's very, VERY hard to find them. Even if you pay them.
 
That's actualy....weird...
It might be weird, but not a very uncommon thing. Embedded components usually have a very high availability (>10 years in the automotive industry), because e.g. car manufacturers and their suppliers are not willing to invest into migrating existing ECUs to new hardware just because they are running low on replacement parts for an older model. The chip manufacturers don't just stop selling chips that are getting near their EOL, they just discourage from using them for new projects - and therefore may stop providing support for the chips they're still selling to you, the support is rarely needed if the product's development is already finished. I can tell you from experience that there are even some automotive suppliers that still want to start new projects with PowerPC BookE chips that are already over 10 years old, even though the whole architecture has already been pining for the fjords for years because everyone is going ARM these days (and because they're an organically grown mess with serious hardware bugs...).

If the OMAP5 actually made it into a single product that hit the market, TI is required to keep them in stock until the promised availability expires, even if they already discontinued it.
 
At least we've got a couple of people getting experience of the PVR stack on the N900 device, as was announced on the mailing list a couple of days ago. It doesn't integrate Linux's direct rendering manager, and presumably doesn't do tiler rotation, but more engineers being more familiar with the baseline technologies enables efficient discussion to work out issues at the very least.
 
  • Like
Reactions: rSl
Could you send out some units to the preorderers who may be able to help with the low level stuff before an “official release.”If any preorderers indicate they may be able to help and will not release any photos or details to anybody( as its still beta)
 
So, throw away around 300k EUR development costs to start from scratch?
The PCB would need a complete redesign, the system would need active cooling (which means a complete case redesign, etc.)
When we started, no Intel CPU was useful. No other CPU was useful.
If we'd start now, we'd probably use the i.MX8, as it has bigger support.
But that one wasn't available back then.
No, not for the Pyra. I thought about future projects or other small indie companies, IF you would start such an project TODAY. ;) What would have changed, what could go different and so on. Sorry, no intention to "throw away" the long Pyra development. I'm not a cruel person.
No. Usually, you only get support from the manufacturer is if you buy at least 100k of their chips.
Even today with so much stuff going on in the hardware market? Where do small "low quantity" indie companies get their stuff from? or is the Pyra the only one in the world?
I already said multiple times: What we're doing here is something COMPLETELY different to most of the handhelds out there: We're doing TONS of custom stuff, not just using reference designs and putting them into a shell.
"Overengineered", yeah that's a typical german thing I guess. Nobody here knows the "KISS" principle (keep it simple, stupid).
The OMAP5 is VERY well documented. Better than most SoCs out there.
But that's over 5000 pages documentation. Someone needs to implement all the timings, hardware registers, etc. into the driver modules so that everything works fine.
Sounds like really low level work. No wonder all these chiense companies use common stuff for their products. I guess they never have to dig that deep into an SoC to make it run right?
TI never finished the graphics system properly. That's why rotation with TILER was terribly slow, until zmatt made a quick hack to show it can be done in fullspeed.
But TI didn't have a huge customer who was in need of that - so they never took care about it. And why should they? Android uses OpenGL for the rotation, and that was probably the main use case for the chip.
They really released that unfinished products? And they are still not bancrupt? Sometimes I wonder how companies come through with that kind of half-ass business. I remember that you lost over an year because of that rotation-chip desaster. Sounds like it could have beeen avoided if TI would gave you the right infos about TILER. ^^"
Times have changed. Back in Pandora-days, there were motivated developers who had fun working on such devices. These days, it's very, VERY hard to find them. Even if you pay them.
What happend? We only have the "Fachkräftemangel" in germany because almost everyone goes IT and "something with computers" and not into craftmanship or service jobs. The world should be full of computer specialists actualy, everyone want to go there (or become Youtuber xD ). So, where are all the talents?
It might be weird, but not a very uncommon thing.
Still not a good thing if you want to call yourself a professional company. Support is everything, entire industires rely on propper (software) support to even be able to exist. Long time service contracts are a thing for sure. Imagine Intel or AMD would act like that. Their drivers support a wide range of older hardware as well as the newer one. Not to infinite but long enough to not piss of the customers completely. ^^
 
Last edited:
Times have changed. Back in Pandora-days, there were motivated developers who had fun working on such devices. These days, it's very, VERY hard to find them. Even if you pay them.

i'm verry motivated and have fun tinkering when things are so cool like the pyra!
but i'm no hardcore kernel developer. back in the days (tm), when redhat/fedora linux was a thing (and wasn't owned by big blue...),
i hacked a lot away on little bash-scripts and better desktop integration.
these days using gnu/linux most of the time "just works" for me. maybe it's because i have learned what *not* to touch, to avoid breaking things. ;)

i for one will spend a lot of time trying to break things while doing "the normal" stuff and trying to fix that.
when more of us with mid-level skills are doing this, we will get the gnu/linux pyraOS polished quite nicely, i'm sure.

for the core kernel and ti flavoured issues we really need some devs of near notaz qualification.

it's the beginning of the new, fun packed, pyraOS-journey, and we are starting *right now*.
the pyra *will* be alive soon! so, woohoo welcome!!! :D


:p&|a:<3
 
Must be a hell of a chip.
Eh, it's just a simple thoroughbred x86 CPU that was targeting the embedded market. It was designed to get the best performance per Watt while still being low power back then, but the result was still rather mediocre (BTW: Its bus system is based on Socket 7, the 24 years old original Pentium and K6 socket).

The long availability is a direct result of its target audience, these kind of chips are usually used for things like industrial control systems - one does not simply replace such heavy machinery, and without a direct internet connection nobody cares that you're still using Windows XP and the like. In the end the ancient manufacturing process is even an advantage, combine it with general modern advances in lithography and you get one hell of a reliable chip - a lot of chips certified for functional safety are still being manufactured with pretty old nodes, 40+nm is still fairly common among those.
 
Pandoras OMAP3 is also still available ;)

The long availability is a direct result of its target audience, these kind of chips are usually used for things like industrial control systems - one does not simply replace such heavy machinery, and without a direct internet connection nobody cares that you're still using Windows XP and the like. In the end the ancient manufacturing process is even an advantage, combine it with general modern advances in lithography and you get one hell of a reliable chip - a lot of chips certified for functional safety are still being manufactured with pretty old nodes, 40+nm is still fairly common among those.
Yeah, and the Zilog Z80 is over 40 years old and still in glorious usage. ;) But I guess it's a different thing to "just" use these chips in embedded systems, where they only must fullfil a specific task in opposite to be the main core of an Handheld multimedia device with alot of Software and components that need to run. We need propper power saving and multimedia and HW video decoding and full 3D acceleration. Not many embedded SoC's can (or must) do that (if you don't count Raspberry Pi, Arduino & Co. ) Modern CPU stuff needs another level of support than older, well known "embedded" chips I'm sure. So OMAP & Co. may be still good for embedded stuff but it would not the best to use them for modern Handheld devices if you want to make one today.
 
Yeah, but the z80 is a historical oddity. In the late 80s till mid 90s it was only popular because Zilog was the last chip maker going to publicly release their layouts, so every two-bit fab and his mate were exposing them onto wafers for the sake of it. Looking on digikey today, it does seem that Zilog is the primary manufacturer of new parts these days, presumably to fulfil the replacement parts market for old kit where the two-bob z80 has flip-flopped its last. In comparison, the chips that were almost as widely used in popular equipment at the time, the 6502 and the 68k, I found only one 68k that wasn't marked for replacement only, and no genuine 6502s at all.

For some reason the SH-3 and SH-4 seem ubiquitous there for reasons I don't fully understand, although they might have something to do with the way hitachi seems to have exploded and populated it's IP about as far and wide as humanly possible. To be fair, Motorola's chip division did similar in the 1990s and that hasn't helped the 6509, so there must be more to it.
 
The Z80 is a microcontroller rather than a fully fledged CPU, though - and microcontrollers often find a niche to stay alive. The early Game Boys' custom microcontroller was also roughly based on the 8080/Z80.

Intel's MCS-51 (8051) reaches 40 years next year as well and there are still chips based on it in use today - I've programmed one myself in university, and some time ago I even saw a job offer at Siedle for a developer that knows this architecture (they're a leading manufacturer of intercommunication systems for buildings). You could even consider the modern Atmels to be somewhat based on the MCS-51.
 
Personally I've always considered the terms 'microprocessor', 'microcontroller' and 'CPU' to be basically repetition myself. Sure, they've added bits to the old chips to become the new chips as time has gone on, but that's been a piecemeal process and I can't tell you when they turned from one to the other. Perhaps there's a useful way to use those terms these days to differentiate the kind of CPUs you need for dumb washing machines and things versus those you need for fancy new TVs, but that's news to me.
 
Before SoCs became common for the more juicy processors the difference was basically defined as "the chip directly includes peripherals", but nowadays you can probably roughly pin it onto having RAM and flash directly within the chip.

It'd say pretty much everything with less than 32-bit that is still being manufactured today could be considered a microcontroller simply because the typical usage scenarios of a microcontroller are pretty much the only things these are being used for nowadays.
 
Last edited:
Personally I've always considered the terms 'microprocessor', 'microcontroller' and 'CPU' to be basically repetition myself.
I generally think of microcontrollers and SoCs as complete computers (with memory controller and memory on board) and microprocessors as being just one part of a computer (with an external main memory system). All have one or more CPUs.
 
Yeah, SoCs as a thing came about in the early 90s as I recall, and mainly referred to the DRAM controller being on board. These days, simple CPUs found in general purpose computers have USB controllers and PCI headers included. But yeah, stuff like the Z80 these days designed for new projects has onboard flash but it's not really designed for general purpose computing any more, so it should perhaps have a different name based on that property. I'd personally say that microcontrollers are of a lesser standing than microprocessors, because controlling things is a lesser thing that actually processing stuff, but I can see that might just be me.
 
So yes, no sensors on the standard edition, but to bring it back to the original question, both revisions have the vibramotor included, which I guess in English means we all get haptics/rumble.
Thanks levi. Good to know.

(I need the rumble for emulation. I can't think of any use - emulation-wise that is - for any of the other sensors.)
 
Back
Top