Bugs and Calculations

[EvilDragon]

Still it's enough to make the kernel maintainer's life miserable as it's creating another hardware variation of Pyra.

I just hope it won't be me this time...

Why? If there are no LEDs, they simply cannot be switched on.
What does that have to do with the kernel?

The 4G module is connected via USB, and I don't remember that you need to change the kernel on a Linux system when you unplug / plug in a USB device.

With the OMAP / DM3730 and the RAM it was different - those need to be discovered and use different configurations.

That's not what I plan to change here.

I've tested a 4G and non 4G-version with GPS. The OS simply reports that it can't find a GPS device on the non-4G version, which makes sense.

But it doesn't need any additional kernel maintenance.

 

[vcoleiro1]

Ed, If it's only the LEDs and controller , how much of a price reduction could that make ?

 

[sm0kew0n]

Wifi only version? Lots of tablets split their range into 3G or wifi only....

 

[_jr_]

Why? If there are no LEDs, they simply cannot be switched on.
What does that have to do with the kernel?

The 4G module is connected via USB, and I don't remember that you need to change the kernel on a Linux system when you unplug / plug in a USB device.

With the OMAP / DM3730 and the RAM it was different - those need to be discovered and use different configurations.

That's not what I plan to change here.

I've tested a 4G and non 4G-version with GPS. The OS simply reports that it can't find a GPS device on the non-4G version, which makes sense.

But it doesn't need any additional kernel maintenance.

OTOH notaz is the guy with kernel maintenance experience.

 

[EvilDragon]

Ed, If it's only the LEDs and controller , how much of a price reduction could that make ?

I never said it's ONLY. I mentioned that as an example as we're looking what makes sense.
And I never said we WILL make a cheaper version, I only said we're checking whether there are enough purely optional parts that can EASILY be removed (meaning: no different parts put on the PCB, only non-populated parts).
[doublepost=1461323642,1461323622][/doublepost]

Wifi only version? Lots of tablets split their range into 3G or wifi only....

That's already the difference between the normal and the 4G version

 

[sm0kew0n]

That's already the difference between the normal and the 4G version

Ah, OK, I got confused in the whole 3G/4G/US 4G debate. I'll be ordering a wifi only version then, assuming it doesn't get too stripped back, I do want a keyboard backlight.

 

[thatgui]

And I'd think like >50% of those would be able to upgrade an unit even if it had the eMMC / RAM already installed ...

Oh, I did not know that so many people could solder on bga components at home (backing oven?)

The 4G module is connected via USB

Interesting, how will activation/deactivation of the device be handled ? Will the power to the module be cut, so its really off, or is WWAN module just told to cease emitting/ going into a low power sleep mode or similar ? If its the latter, it may be interesting so see how battery runtime is affected by that.

 

[matzesu]

But whe know from Pandora, that USB and Low Power Mode, dosnt work well together, and my Display Backlight of the CC Unit gos to the hightes level, when i acitvate USB Host,
and when 4G is connektet via USB, than the whole Low Power Mode / Standbye thing should work diverent on Pyra..

 

[EvilDragon]

Interesting, how will activation/deactivation of the device be handled ? Will the power to the module be cut, so its really off, or is WWAN module just told to cease emitting/ going into a low power sleep mode or similar ? If its the latter, it may be interesting so see how battery runtime is affected by that.

You can fully cut the power, if you like. There was a discussion about it long ago.
[doublepost=1461326929,1461326877][/doublepost]

But whe know from Pandora, that USB and Low Power Mode, dosnt work well together, and my Display Backlight of the CC Unit gos to the hightes level, when i acitvate USB Host,
and when 4G is connektet via USB, than the whole Low Power Mode / Standbye thing should work diverent on Pyra..

Usually, such devices take care about the power usage themselves. The Wifi chip, for example, needs very little power when it doesn't do anything.

 

[hns]

I saw in a tweet from ED today that Doc Nik is creating some Pyra specific eSATA adapters. Does this mean that the driver for the power circuit is solved or is that still in flight at the same time?

Also - with regards to the eSATA adapters - I'm sure ED and Doc Nik have considered it - but what happens if the eSATA adapter is plugged into the standard USB 2.0 port - or a USB port on a whole other device?

Hope it has been considered from a precautionary perspective so that it can't damage things. I'm overly familiar with having plugged the wrong device into the wrong plug. Pandoras really don't like 3A@14VDC.

See:
If you plug an USB3 device into the USB3 socket of the Pyra it will see USB2 signals plus eSATA signals. The latter are not compatible (in data bit encoding) so that it should simply fall back to USB2.

If you plug the eSATA adapter into an USB3 capable host it will try to communicate USB3 signals into the eSATA socket. But they are again not compatible .

In both cases the signals are weak high-frequency signals coupled by 10 nF capacitors so that there will not flow any damaging current or voltage.

If you plug in the eSATA adapter into a standard USB2 socket the additional wires for eSATA will be connected to nowhere. So it will not damage your PC or USB power supply and will itself not be damaged.

 

[notaz]

Why? If there are no LEDs, they simply cannot be switched on.
What does that have to do with the kernel?

You mentioned removing the LED controller and that is already a problem, as the kernel will have to handle missing controller gracefully or use separate device trees. Missing devices may cause the bus to hang, expose driver bugs and so on, and as we don't want to be stuck on single kernel version things like that can (and will) happen on kernel updates.

In both cases the signals are weak high-frequency signals coupled by 10 nF capacitors so that there will not flow any damaging current or voltage.

It may confuse their controllers though and cause things like the port stopping to work until hard reset, like we have it on OMAP3 when low/full speed USB device is plugged into high speed port.

 

[EvilDragon]

You mentioned removing the LED controller and that is already a problem, as the kernel will have to handle missing controller gracefully or use separate device trees. Missing devices may cause the bus to hang, expose driver bugs and so on, and as we don't want to be stuck on single kernel version things like that can (and will) happen on kernel updates.

Oh, it's that picky?
How does that work with standard PCs, where every mainboard has different configurations...? :O

 

[slaeshjag]

It's probed on boot-up. ARM devices however mostly lack these capabilities, and have a fixed set of devices specified in the DTB, and if they're not physically present, it's up to the driver what happens. Kinda like telling your SoundBlaster 16 driver there's a card at an I/O address that isn't claimed by anything.

 

[lukey]

There are Worlds between I2C and ISA/PCI(-E).

 

[Grench]

See:
If you plug an USB3 device into the USB3 socket of the Pyra it will see USB2 signals plus eSATA signals. The latter are not compatible (in data bit encoding) so that it should simply fall back to USB2.

If you plug the eSATA adapter into an USB3 capable host it will try to communicate USB3 signals into the eSATA socket. But they are again not compatible .

In both cases the signals are weak high-frequency signals coupled by 10 nF capacitors so that there will not flow any damaging current or voltage.

If you plug in the eSATA adapter into a standard USB2 socket the additional wires for eSATA will be connected to nowhere. So it will not damage your PC or USB power supply and will itself not be damaged.

Thank you! That was just the information I was looking for!

That split adapter looks great by the way - VERY nicely done.

An interesting companion cable set might be one that connects to the USB 2.0 (for power) and one that connects to the eSATA with the other end(s) being the power and signal connector(s) for an internal SATA drive. I'm not sure if that exists anywhere currently. Since 100mA isn't enough to spin up a drive, though, it would likely need the logic to shift into high power mode to draw up to the USB 2.0 spec max of 900mA which is a lot.

Hmm... It would be interesting to be able to pick up any SATA HDD/SSD/DVD and direct connect it. On the other hand, that's a lot of current to draw Maybe relying on an external power source for eSATA drives would be better. Thoughts?
[doublepost=1461336659,1461336204][/doublepost]

There are Worlds between I2C and ISA/PCI(-E).

And a few of us still know how to set the DIP switches in hex to control the IRQ from card to card - or even within the card in the case of the AST 6 pack.

Still, from the OS perspective, I could see where an inconsistent hardware could make development and maintenance of a stable OS image more difficult.

 

[TrashyMG]

And a few of us still know how to set the DIP switches in hex to control the IRQ from card to card - or even within the card in the case of the AST 6 pack.

I still have a couple of those laying around...

 

[Plume]

You mentioned removing the LED controller and that is already a problem, as the kernel will have to handle missing controller gracefully or use separate device trees. Missing devices may cause the bus to hang, expose driver bugs and so on, and as we don't want to be stuck on single kernel version things like that can (and will) happen on kernel updates.

Shouldn't handling missing controllers gracefully be the base case ?

 

[Grench]

Oh, it's that picky?
How does that work with standard PCs, where every mainboard has different configurations...? :O

If you want to leverage the development work that has been done to expand to other product lines - maybe there are alternatives other than making a stripped down Pyra?

I am fully aware of the bad history associated with Insane Clown Possee 2. However badly that was mismanaged by he who shall remain not mentioned in this post, there may still be a market for a high quality bluetooth keyboard/gaming controller device. Remove all of the ports and slots from the Pyra board except the microUSB for diagnostics & charging. Find a very inexpensive low powered chip to run it and handle the re-mapping from it's keyboard layout to standard bluetooth HID. Create a case that can handle the quad shoulder buttons, use consumer available rechargeable AA batteries in nacelles on the bottom left/right to give a bit more thickness there for comfort and the shoulders and...

OK, so the bad history would be very very hard to overcome. Still, that is the most 'stripped down' that anything derived from the Pyra could be.

 

[notaz]

Shouldn't handling missing controllers gracefully be the base case ?

In theory yes, but in practice it's not something you can expect always to work.

 

[Letalis Sonus]

up to the USB 2.0 spec max of 900mA

900mA is USB 3.0, USB 2.0 only has 500mA max.