A Model Code In The Firmware?


maybe you guys are overthinking this. Wouldn't a placement of a resistor be enough? The advantage would be that the currect ve4rsion wouldn't have to be changed, as the lack of said resistor is enough of an indicator.
 
Kyosys said:
maybe you guys are overthinking this. Wouldn't a placement of a resistor be enough? The advantage would be that the currect ve4rsion wouldn't have to be changed, as the lack of said resistor is enough of an indicator.
WTF? How should a resistor help, and how would its presence or absence even if there was a way to detect it would help?
 
Last edited by a moderator:
Kyosys said:
maybe you guys are overthinking this. Wouldn't a placement of a resistor be enough? The advantage would be that the currect ve4rsion wouldn't have to be changed, as the lack of said resistor is enough of an indicator.
Do you know the stable value of a floating input?
 
Last edited by a moderator:
On a lot of consoles these days, you are not allowed to publish games that attempt to check/verify what revision of the hardware you are running on (it would cause the software to fail submission). Of course this is a slightly different case as the console hardware is designed to function exactly the same across revisions (normally the only reason for the revisions is to use cheaper parts each time to raise profit margins). I'd still say you probably shouldn't be trying to do any model number checks for any versions of the Pandora that are meant to be the same as each other, if the hardware changes substantially early on then it'd be a bit of a disappointment, because potentially it could screw lots of people over, as you'd end up with loads of software you couldn't run as it was designed for the old hardware and you have a new board (okay, you can argue that the software would still be compatible, but if you the stance that the software runs correctly on all revisions then there is still no need for checking the revision in the first place)! :)

If a completely new version of the Pandora came out (Pandora II) then of course I'd expect it to be possible to detect this - but I wouldn't be worrying too much about doing anything with the original version to ensure this.

Just my thoughts...

Steve
 
I am going to try to add a sense resistor to an analog input line that changes between revisions of the PCB that actually change features. I think that is a great idea and my only concern is whether I can route out a pin to do it. Contrary to some people's belief, there are not a whole bunch of free pins available anywhere to attach lots of extras. :)

Rockthesmurf: As much as I would love to see commercial games on the system, it's a long shot. This little identifier part isn't going to change much for anyone and I too don't expect to see a bunch of changes to Pandora but adding a $0.0001 part isn't going to hurt anyone. I'd rather be prepared than face the disasters with the GP2X.
 
Rockthesmurf said:
On a lot of consoles these days, you are not allowed to publish games that attempt to check/verify what revision of the hardware you are running on (it would cause the software to fail submission). Of course this is a slightly different case as the console hardware is designed to function exactly the same across revisions (normally the only reason for the revisions is to use cheaper parts each time to raise profit margins). I'd still say you probably shouldn't be trying to do any model number checks for any versions of the Pandora that are meant to be the same as each other, if the hardware changes substantially early on then it'd be a bit of a disappointment, because potentially it could screw lots of people over, as you'd end up with loads of software you couldn't run as it was designed for the old hardware and you have a new board (okay, you can argue that the software would still be compatible, but if you the stance that the software runs correctly on all revisions then there is still no need for checking the revision in the first place)! :)

If a completely new version of the Pandora came out (Pandora II) then of course I'd expect it to be possible to detect this - but I wouldn't be worrying too much about doing anything with the original version to ensure this.

Just my thoughts...

Steve
That kind of infringes upon the "open-ness" of the console... if devs want to know the model number then why not? I suppose, devs could intentionally stop poeple with newer units being able to use their apps, but i can't quite see the point in that.

I only see the point that if something is changed slightly, and unpredictably, it causes an app to not work properly, devs can sort it!

(BLU+ anybody? - though i know this won't happen on the pandora ;))
 
Last edited by a moderator:
mrsnature said:
Rockthesmurf said:
On a lot of consoles these days, you are not allowed to publish games that attempt to check/verify what revision of the hardware you are running on (it would cause the software to fail submission). Of course this is a slightly different case as the console hardware is designed to function exactly the same across revisions (normally the only reason for the revisions is to use cheaper parts each time to raise profit margins). I'd still say you probably shouldn't be trying to do any model number checks for any versions of the Pandora that are meant to be the same as each other, if the hardware changes substantially early on then it'd be a bit of a disappointment, because potentially it could screw lots of people over, as you'd end up with loads of software you couldn't run as it was designed for the old hardware and you have a new board (okay, you can argue that the software would still be compatible, but if you the stance that the software runs correctly on all revisions then there is still no need for checking the revision in the first place)! :)

If a completely new version of the Pandora came out (Pandora II) then of course I'd expect it to be possible to detect this - but I wouldn't be worrying too much about doing anything with the original version to ensure this.

Just my thoughts...

Steve
That kind of infringes upon the "open-ness" of the console... if devs want to know the model number then why not? I suppose, devs could intentionally stop poeple with newer units being able to use their apps, but i can't quite see the point in that.

I only see the point that if something is changed slightly, and unpredictably, it causes an app to not work properly, devs can sort it!

(BLU+ anybody? - though i know this won't happen on the pandora ;))


Don't get me wrong, I don't mind either way, I was just sharing some knowledge I had about how the main consoles work. Not having 'version specific' code, is useful for stuff like:

- Doesn't requie testing per version
- Don't have different code paths with potentially different bugs in
- Means that future revisions of the hardware are guaranteed to be backwards compatible (providing the hardware doesn't screw up)
- Doesn't potentially close off programs/parts of program to users based on when they brought their handheld

But there's been some good points raised about why it would be useful to be able to know the current version (based on some other handhelds that have been out recently.... ;) ).

Steve
 
Last edited by a moderator:
I doubt that will happen. Hardware revisions will probably just be little things like a different wifi chip because the old one went out of business (just an example). Of course everyone will try to keep the compatability up, but it might just be something like a backspace key being added, and in order not to discriminate mk1 users, the program would detect if it's there and route it to the DEL key otherwise.
I doubt that you will really _need_ to test your software on different revisions as it's still the same machine. If incompatability problems occur, however (kinda like with the F200), it's easy to fix them.
 
From an Applications point of view it doesn't matter if the WiFi chip or LCD change as it doesn't directly talk to the HW but goes through standard interfaces (e.g. sockets or framebuffer).

Key remapping for the keyboard I think *may* also be able to be done in the same way (i.e. the kernel handles it) but I have to confess that I haven't looked into that.

I agree that it would be harder to workout if, for example, shoulder buttons have been added as the hardware probably wouldn’t report that information back (unless someone added a proc or sysfs entry with the information).

I don't know if each unit will have a serial number in HW somewhere but if so it would be a easy job to determine which model it was from that (e.g. 01xxxxx = MK1, 02xxxxx = MK2).

A E2PROM would be better for storing which model it is rather then a resister as then you can have more then 2 values (assuming only 1 GPIO is available and that it's not a ADC) but I understand this will add much more cost then just a resister.

Just my 2 pence :)
 
Back
Top