• Content count

  • Joined

  • Last visited

About Exophase

Contact Methods

  • AIM Exophase
  • MSN exophase@adelphia.net
  • Yahoo espfusion

Profile Information

  • Gender Male
  • Location Cleveland, OH
  1. Jumping into ARM assembly

      You're right, I didn't really work that out right. It's not that (a * reciprocal_b) - (a / b ) < 1 fails in this case (it's about 0.1), but that the error flips it over into the next whole number.   So I guess that should really be formulated as: ((a / b) % 1) + ((a * reciprocal_b) % 1) < 1 Not really sure what bounds that though >_> Getting the first part (non-negative) right is really the key, after that I tend to just iterate the range to make sure it works for what I need...
  2. Pi Zero - the $5 computer

    Another alternative got posted here before but here it is again in case anyone's interested:   http://getchip.com/ (if you order it on Monday it's $8 instead of $9)   So vs RPi Zero, it has advantages like:   + A faster processor + 4GB onboard storage + Integrated WiFi/BT + Populated GPIO and composite headers + Battery charger built-in and battery available that you can plug in directly + A neat little handheld keyboard device expansion thing is available   But disadvantages like:   - A little larger in one dimension (60x40mm vs 65x30mm for the RPi Zero.. so a little smaller in the other dimension) - No uSD expansion - Needs expansion board for HDMI - Isn't actually out yet and some speculate that the price will go up later - RPi will have a bigger software and hardware ecosystem, even with ARMv6 - Is a little more expensive at $8 vs $5.. if you can buy RPi Zero for $5 anyway. They do appear to have some at a Microcenter near me for that price.
  3. Jumping into ARM assembly

      We're synthesizing unsigned integer division here, that's supposed to floor/truncate. You can turn that into round to nearest by adding to the dividend beforehand.   When performing (a * reciprocal_b), some positive error is allowed so long as it isn't greater than or equal to 1.0. On the other hand, no negative error is allowed.   So: (a * reciprocal_b) - (a / b) >= 0 reciprocal_b - (1 / b) >= 0 Meaning that you can't allow any negative error on reciprocal_b, so any fractional part must be rounded to the whole (with ceil). On the other hand... (a * reciprocal_b) - (a / b) < 1 reciprocal_b - (a / b) < (1 / a) The error must be < 1 / a. With the format I used reciprocal_b has 0 integer bits and 32 fractional bits, so the positive error is < (1 / (2^32)). So long as a < (2^32) (which is the limit of the number format) this will hold.
  4. Pi Zero - the $5 computer

    This post might ruffle some feathers and get me some negative backlash, but I personally will not buy an RPi Foundation product so long as they use public blocklists on their official Twitter account that block people based on who they follow (https://spacemidget.wordpress.com/2014/11/25/raspberry-pi-use-scattershot-blocklist-and-put-hands-over-their-ears/)     Really, even Pandora is more powerful. This is an overclocked RPi 1. The problem is that without proper L2 cache that ARM11 will not scale terribly well in performance to 1GHz. I expect the CPU performance to be something like half that of 1GHz Pandora's, although it'd vary a lot depending on what you're running. Lack of ARMv7a (NEON mainly) is also a big downside.   I doubt you could come anywhere close on price, but size-wise Gumstix had products that outdid this 6 years ago.
  5. Jumping into ARM assembly

      Cortex-A8 and therefore Pandora does not. It wasn't added to ARMv7a CPUs until Cortex-A15/Cortex-A7.   Division by constants can be synthesized with multiplications and shifts. Depending on the input range, you may need to use multi-precision. This will work for all unsigned 32-bit inputs:   ldr r1, =div_10_reciprocal umull r3, r2, r0, r1 @ r2 = r0 / 10, r3 is overwritten ... div_10_reciprocal: .word 429496730 @ ceil((2^32)/10)   If you need smaller values you can do it with a 32-bit multiplication and a shift.   a % b (modulo) is then performed as (a - (b * (a/b)). Here I'll use the mls (multiply and subtract) instruction that actually is available on Cortex-A8: mov r3, #10 mls r3, r2, r3, r0 @ r3 = r0 - ((r0/10) * 10)  
  6. nVidia Jetson TX1 board

      I'm saying it's somewhat more power efficient but somewhat less powerful than A53, and for a Pyra-like application A53 already fulfills the low-power 64-bit little core role well enough.
  7. nVidia Jetson TX1 board

      No, this isn't really applicable. It's somewhat weaker than Cortex-A53, albeit more power efficient. And Cortex-A53 is significantly weaker than Cortex-A15, albeit 64-bit. This is for lower power and cheaper devices than what Pyra is supposed to be.   Even as a replacement for the cores in a little cluster it's not that interesting; for a new mobile SoC made on a 14nm/16nm process A53s are really low power enough.
  8. nVidia Jetson TX1 board

    A Tegra X1 PCB (http://www.notebookcheck.net/fileadmin/_processed_/csm_P1000157_e4c0fd7899.jpg) was demonstrated at CES 2015 in this video: http://www.notebookcheck.net/Nvidia-announces-Tegra-X1-SoC.134068.0.html   There's no particularly bulky HSF but there is a slab of metal on top of the SoC and RAM (much like the SoC in Samsung's Exynos 5250 Chromebook, which is very OMAP5-ish). The PCB is the one in the lower left, this is clearer when the video zooms in around 1:15.   Tegra X1 is also in the Pixel C tablet. I can't find any teardown shots of it. It's obviously fairly thin and not actively cooled but it's also a big old tablet so that doesn't really amount to much.
  9. nVidia Jetson TX1 board

    IMO it'd be disrespectful to even broach the subject of investigating a redesign around this for Pyra when so much money and effort has been put into designing the OMAP5 based solution and it's so close to release. Even if the community were willing to absorb the delay and cost hike associated with this.   I'd rather see other people verify the viability of this on the bench and later propose a design that's basically a Pyra fork with a separate mainboard, possibly sharing the same case/LCD/controls/etc (so maybe something you could migrate a Pyra to or make with off the shelf parts). Then see this funded with a separate initiative, something like a ~$100k KS campaign (just a guess number...). But even this could be problematic for DragonBox, so I would hope it'd only happen with ED's considered blessing.   The alternative would be to just do a new handheld altogether. Even there I wouldn't want to see a straight up competitor steal Pyra sales outright.   Now any of this would mean a split hardware userbase. But if Pyra is going to ever upgrade again (and I think they'll want to..) this will have to be accepted as an inevitability. Going forward I think there's going to have be lighter weight migration/compatibility paths than what we're seeing with the move from Pandora to Pyra. There really shouldn't be much about the SoC choice that is unportable between software so long as the ISA stays compatible, but some care and effort will have to be made in using pretty generic interfaces for things like 2D acceleration and display windows. As much as is possible anyway.   But please no one take this too seriously, this is just daydreaming really, maybe brainstorming, not some big call for initiative. And before anyone asks, I personally probably wouldn't be able to play a role in something like this outside of maybe funding
  10. nVidia Jetson TX1 board

    I should have mentioned before, but another good example of varying thermal envelopes was the Tegra 4, which was deployed in the original Shield handheld with an HSF but still had respectable performance in the Xiaomi Mi3 phone (although it's obscure since only the Chinese version used Tegra 4). In theory something like Pyra could have somewhat more favorable thermal characteristics than a phone, although in practice it'll be hard without employing high end materials and cooling design.     The display specs for the board are:   2x DSI, 1x eDP 1.4, 1x DP 1.2/HDMI   So I'm not certain it lets you use all of those simultaneously. You would think so.
  11. nVidia Jetson TX1 board

    Dimensions are 87x50mm, roughly like the size of a credit card (85.6x53.98mm).   I don't have precise dimensions of the Pyra CPU board, I think ED or hns would have to provide these.. but you can estimate from drawings by comparing to standard connector sizes. I rotated/sheared a picture (http://cdn.liliputing.com/wp-content/uploads/2015/05/pyra1-680x424.jpg) and estimate that the USB connector (12.5mm) is about 32 pixels wide. Board total is about 282 pixels wide by about 114 pixels tall. So, dimensions are about 110x44.5mm. Meaning the nVidia board is not nearly as wide but a bit taller. Now, the Pyra CPU board fits really snugly in between the connectors so there'd be some challenge moving it. Worst case scenario would be moving to microSD (yeah, I know...) but maybe it can be avoided somehow.
  12. nVidia Jetson TX1 board

    Some other positives about the SoC and module:   - Full SoC TRM and datasheet are available if you register at nVidia's site - Full drawings for the module are available - From the TRM, it looks like the display controller supports rotation in a pretty straightforward way:  
  13. nVidia Jetson TX1 board

      For their SoCs, yes. Here they are selling an entire module that combines SoC, RAM, PMIC, storage, and wifi/BT on a small form factor PCB. Much like Pyra's CPU board. They're selling it publicly and in individual quantity so I doubt they have any stipulations on what you do with it.
  14. nVidia Jetson TX1 board

      nVidia has said that the HSF is overspecified, but putting that aside...   Power consumption/heat are very dynamic parameters and there a bunch of controls in place to make it fit into whatever envelope is specified. What becomes relevant is not whether or not this could run full-tilt in a Pyra-like form factor. It probably can't, but neither can most high end phones. For that matter, it already sounds like you may not be able to run both Cortex-A15 cores at 1.7GHz in Pyra. Let alone the 2GHz TI once advertised the SoC as being capable of. Look at the OMAP5 EVM, it also has a heatsink that's bigger than what can fit in a Pyra-like device and it's only specified for 1.5GHz.   We're talking about quad core devices here so there's a big dynamic range between one core running at 1.5GHz and four cores running at 1.9GHz. The latter doesn't have to be attainable for this to be better suited for the form factor.   That makes the relevant question this: is the efficiency as good or better than OMAP5 + DDR3. All things considered, I suspect that it is. It's a newer CPU incorporating more efficiency advances (OMAP5 isn't just Cortex-A15, it's an early revision Cortex-A15 prior to various optimizations) on a newer process (OMAP5 isn't just 28nm but probably not 28HPM which brought a lot of efficiency advance over the process used for eg Tegra 4; Tegra X1 is on TSMC 20nm) And it's using more power efficient RAM (LPDDR4 vs DDR3L) The GPU is also known to be very efficient.   nVidia certainly says as much themselves: they've made the claim that their CPU implementation is 1.4x more efficient than Samsung's Exynos 5433, another Cortex-A57 SoC implemented on a 20nm process. And given the power measurements I've seen of that SoC I expect it's more efficient than OMAP5 as well. I fear OMAP5 will be more in line with the old Exynos 5250 which wasn't very efficient at all.   Now granted, this isn't a given. By all appearances, it may not apply to Qualcomm's S810/S808 despite it having those advantages too. But I definitely would not write it off. That's why it'd be worth getting and doing some tests with.
  15. So nVidia recently announced a new Jetson board equipped with the Tegra X1 SoC:   http://www.nvidia.com/object/jetson-tx1-module.html   For those who are aware, Jetson is nVidia's Linux-based development board series. This one is more interesting than the last because it comes in the form of a small module for the main components (like the one being used in Pyra) and because it's 64-bit. So all in all, you get a relatively high end ARMv8 CPU with a strong GPU and extensive OpenGL ES 3.1+ and plain OpenGL 4.4 support. The small module also embeds the 4GB of LPDDR4 RAM, PMIC, 16GB eMMC (400MB/s theoretical peak access speed) and wifi/BT. I/Os include 2x SD, USB 3.0, gigabit ethernet, SATA, and HDMI/eDP.   So I'll say what I bet some others are also thinking.. it sure would be nice to see a Pyra-like handheld built around this board instead of OMAP5 + DDR3. Not that I would push ED to even consider such a thing, but maybe if all the drawings are released (AFAIK they will be?) funding could be raised allowing a third party to respin the Pyra main board and hopefully it would still fit inside the same case. That's assuming that the power profile isn't too extreme to be useful in this form factor, but that's the nice thing about being able to purchase it now - that can be tested for beforehand.   There are however two big downsides. First is the price, which is $299 for the module ($599 if you want the full dev board it plugs into, the HSF, etc). This might still allow a roughly Pyra-priced unit, but it's still pretty steep - especially when you consider that the Shield TV has more or less the same hardware plus a bunch of other stuff and only costs $199. Maybe nVidia would in time lower the price or offer volume discounts.   The other downside is that none of the documentation for the module makes mention of the SoC's Cortex-A53 cluster, leading me to believe it has been disabled. Bad news for a handheld where it would have been very useful for lower end tasks like basically anything that runs fine on Pandora. But maybe there's something more to this.