On 1/9/2022 3:26 PM, Dimiter_Popoff wrote:> On 1/10/2022 0:06, Don Y wrote:>> You stick with what you already have/had -- insofar as it is able >> to meet your ongoing needs. >> >> Or, embrace more "open" offerings... often with the need to make some >> commitment (time or money) to ensuring their continued availability, >> development, etc. >> >> (Too often, folks buy into FOSS for $0 -- thinking it "free" and not >> realizing that it can go away just as easily, without support, as >> any other offering!) > > Well we have dps for power only but it comes with everything necessary > to do all the software for pretty sophisticated products without needing > a single bit of software from anyone else.This is the approach I've taken with all of my projects -- even if the toolchain had to be purchased, commercially (it will still function years later -- albeit without potential updates). And, if you avoid "exotic" hardware/components, you can usually avoid any dependence on particular suppliers (alas, the days of multiple second-sources are long gone but you can still minimize the effort involved in "porting" a design to a different BoM).> How does product lifetime licensing sound? :-)That's what you have when you own the technology. Many folks now *can* have this by adopting open toolchains AND SUPPORTING THEM (as most folks aren't interested in building tools from scratch but *can* contribute -- bug reports, test cases, etc. -- to improving an open toolchain's codebase) Have you tried to guesstimate the effort required to port DPS to another processor? (genuine question as I've not delved into your code enough to understand it's "assumptions")
Why apps?
Started by ●January 8, 2022
Reply by ●January 9, 20222022-01-09
Reply by ●January 9, 20222022-01-09
Tom Del Rosso wrote:> Phil Hobbs wrote: >> Tom Del Rosso wrote: >>> >>> Google's OS and Apple's OS probably wouldn't allow it. If more people >>> had Linux phones it could be done, but they cost around $800 which >>> gives an idea how much Google and Apple make from your phone. >>> >>> >> >> Nah, you can get a Pinephone for $200. > > Wow. I only looked at the high end with switches to power off > components. > >I have a Pinephone Beta and an early Pinephone tout court (not Pro). Both have the dip switches. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
Reply by ●January 10, 20222022-01-10
Phil Hobbs wrote:> Tom Del Rosso wrote: >> Phil Hobbs wrote: >>> Tom Del Rosso wrote: >>>> >>>> Google's OS and Apple's OS probably wouldn't allow it. If more >>>> people had Linux phones it could be done, but they cost around >>>> $800 which gives an idea how much Google and Apple make from your >>>> phone. >>> >>> Nah, you can get a Pinephone for $200. >> >> Wow. I only looked at the high end with switches to power off >> components. >> >> > I have a Pinephone Beta and an early Pinephone tout court (not Pro). > Both have the dip switches.On the models I was looking at, there were slide switches on the side, not DIP switches. -- Defund the Thought Police Andiamo Brandon!
Reply by ●January 10, 20222022-01-10
On 1/10/2022 3:00, Don Y wrote:> On 1/9/2022 3:26 PM, Dimiter_Popoff wrote: >> On 1/10/2022 0:06, Don Y wrote: > >>> You stick with what you already have/had -- insofar as it is able >>> to meet your ongoing needs. >>> >>> Or, embrace more "open" offerings... often with the need to make some >>> commitment (time or money) to ensuring their continued availability, >>> development, etc. >>> >>> (Too often, folks buy into FOSS for $0 -- thinking it "free" and not >>> realizing that it can go away just as easily, without support, as >>> any other offering!) >> >> Well we have dps for power only but it comes with everything necessary >> to do all the software for pretty sophisticated products without needing >> a single bit of software from anyone else. > > This is the approach I've taken with all of my projects -- even if the > toolchain had to be purchased, commercially (it will still function > years later -- albeit without potential updates). > > And, if you avoid "exotic" hardware/components, you can usually avoid > any dependence on particular suppliers (alas, the days of multiple > second-sources are long gone but you can still minimize the effort > involved in "porting" a design to a different BoM). > >> How does product lifetime licensing sound? :-) > > That's what you have when you own the technology. Many folks now > *can* have this by adopting open toolchains AND SUPPORTING THEM > (as most folks aren't interested in building tools from scratch but > *can* contribute -- bug reports, test cases, etc. -- to improving > an open toolchain's codebase) > > Have you tried to guesstimate the effort required to port DPS to > another processor? (genuine question as I've not delved into > your code enough to understand it's "assumptions")It won't be a huge effort but there will be a performance hit for ARM, not that much for MIPS. The hit won't be that huge anyway. But at the moment I am finishing something I have started a few years ago (and had to put on hold for scheduling reasons), it started as a file browser and is becoming an "object browser", fingers crossed it won't take much longer (getting back into it took nearly a month). So porting is not directly on the agenda, not yet anyway.
Reply by ●January 10, 20222022-01-10
On 08/01/2022 20.17, legg wrote:> On Sat, 8 Jan 2022 08:56:33 -0800 (PST), Lasse Langwadt Christensen > <langwadt@fonz.dk> wrote: > >> lørdag den 8. januar 2022 kl. 16.33.18 UTC+1 skrev legg: >>> On Sat, 08 Jan 2022 14:18:24 +0100, Jeroen Belleman >>> <jer...@nospam.please> wrote: >>> >>>> For years, interaction with the internet worked through a >>>> universal browser. Lately, every service, gadget or whatnot >>>> wants you to download their special-purpose app. Why?? >>>> What's the deal? It seems like a huge step backwards to me. >>>> >>>> Jeroen Belleman >>> Have been trying to get an Android OS running on a PC, >>> just in order to communicate with hardware using a >>> bluetooth link - which is what mfr app provides. >>> >>> Android cannot recognize, access or use most of >>> PC hardware, to do this. Complete flop. >>> >>> Android not ready for anything other than use as toy. >> >> there are 3 billion active Android devices ... >> > > The option of buying an android tablet and setting it > up to run the app seems the only current alternative. > > Why? because Google doesn't want to do the work of > creating a real OS. Revenue from toys id apparently > enough.There is no reason at all why they would want to do that. It is an OS designed to run on phones and tablets, not computers. And in that role it is king. -- Cheers, Carlos.
Reply by ●January 10, 20222022-01-10
On 08/01/2022 14.18, Jeroen Belleman wrote:> For years, interaction with the internet worked through a > universal browser. Lately, every service, gadget or whatnot > wants you to download their special-purpose app. Why?? > What's the deal? It seems like a huge step backwards to me.Not being limited by the browser. For example, a radio station promotes their own app to listen to that station. To make it run, you have to login, so they have you pinpointed. Once there, you can not refuse their adverts. Your privacy is lost. Of course, they also provide features to entice you and keep you in. Even if you close the app, it can keep running in the background, and for example, tell you that your favourite program is coming now. -- Cheers, Carlos.
Reply by ●January 10, 20222022-01-10
On 1/10/2022 1:47 AM, Dimiter_Popoff wrote:>> Have you tried to guesstimate the effort required to port DPS to >> another processor? (genuine question as I've not delved into >> your code enough to understand it's "assumptions") > > It won't be a huge effort but there will be a performance hit for > ARM, not that much for MIPS. The hit won't be that huge anyway.What drives the efficiency aspect? My impression of your code was that it abstracts a register-file based architecture (?); does number (and color) of registers factor into how well it layers onto a new platform?> But at the moment I am finishing something I have started a few > years ago (and had to put on hold for scheduling reasons), it started > as a file browser and is becoming an "object browser", fingers crossed > it won't take much longer (getting back into it took nearly a month).For development use? Or, just as a general utility? I tried to avoid building many tools for my system -- beyond ones that let me watch transactions across multiple processors (e.g., flatten RPCs so they look like simple function calls -- though annotated with system timestamps and related metrics). Here, that's the toughest aspect of debugging to wrap your head around (as the actual function isn't executing on the node that initiates it so watching execution is problematic). And, a simple monitor that lets me attach a console to a node and step through code, pull down binaries over the network, check clock synchronization, etc. "Old tech" :>> So porting is not directly on the agenda, not yet anyway."Agenda"? What's that?! :> [I've some other questions but probably not suitable to ask in a public forum. I'll drop you a line when I get all my immediate "issues" behind me...]
Reply by ●January 10, 20222022-01-10
On 1/10/2022 12:56, Don Y wrote:> On 1/10/2022 1:47 AM, Dimiter_Popoff wrote: >>> Have you tried to guesstimate the effort required to port DPS to >>> another processor? (genuine question as I've not delved into >>> your code enough to understand it's "assumptions") >> >> It won't be a huge effort but there will be a performance hit for >> ARM, not that much for MIPS. The hit won't be that huge anyway. > > What drives the efficiency aspect? My impression of your code > was that it abstracts a register-file based architecture (?); does > number (and color) of registers factor into how well it layers onto > a new platform?Mainly the number of registers, much of the code thinks 32 registers (r0-r31, d0-d7 are r8-r15, a0-a7 are r16-r23, a7 being the SP by convention). Now I first use do-d7 a0-a5 (a6 usually holds the top of the current stack frame), in the 68340 days I had only these anyway, then I resort to r24-r31 as needed, r0-r3 have meanwhile some specialized use (mapping them in memory would mean almost no efficiency hit though - I think). r4-r7 are volatile on a per source statement basis, used to calculate effective address etc. Another aspect is the endianness, if the core cannot do both accesses, especially big endian, this will cost something, too. But the code is so compact and efficient things will still be way better than a compiler output for something written in a high level language.> >> But at the moment I am finishing something I have started a few >> years ago (and had to put on hold for scheduling reasons), it started >> as a file browser and is becoming an "object browser", fingers crossed >> it won't take much longer (getting back into it took nearly a month). > > For development use? Or, just as a general utility?Mostly as a general utility for the users, people are used to see something similar to windows explorer etc. Only this is becoming very flexible/expandable, being based on dps objects (which are runtime maintained, located etc., it is a largish thing and I have spent well over a decade getting better and better at utilizing it... never mind I have changed its basics very little since I introduced it, wait, this was > 20 years ago, 1995-6 or so).> > I tried to avoid building many tools for my system -- beyond ones that > let me watch transactions across multiple processors (e.g., flatten > RPCs so they look like simple function calls -- though annotated with > system timestamps and related metrics). Here, that's the toughest > aspect of debugging to wrap your head around (as the actual function > isn't executing on the node that initiates it so watching execution is > problematic).I also do tooling "on demand", like everyone else I suppose.> > And, a simple monitor that lets me attach a console to a node and step > through code, pull down binaries over the network, check clock > synchronization, etc. "Old tech" :>Oh I am using a monitor which is the basic part of the ROM like forever, a new board still first comes up talking through an UART (the flash being written to using boundary scan via jtag, never had the details of the debug port beyond that, an NDA was not enough for it and well, I can live without it anyway). On a booted system it is the same monitor only the terminal is a window via a "link" driver and a task entering the monitor does not block the scheduler (but try to have a second task exit to the monitor while the first one is in it and wait for the reboot :). I made a (now pretty old) version of this monitor freely available, there has been no huge crowd downloading it but from time to time someone does. ( http://tgi-sci.com/tgi/download/m52.htm )
Reply by ●January 10, 20222022-01-10
On 1/10/2022 8:00 AM, Dimiter_Popoff wrote:>>> But at the moment I am finishing something I have started a few >>> years ago (and had to put on hold for scheduling reasons), it started >>> as a file browser and is becoming an "object browser", fingers crossed >>> it won't take much longer (getting back into it took nearly a month). >> >> For development use? Or, just as a general utility? > > Mostly as a general utility for the users, people are used to see > something similar to windows explorer etc. Only this is becoming > very flexible/expandable, being based on dps objects (which are > runtime maintained, located etc., it is a largish thing and I > have spent well over a decade getting better and better at utilizing > it... never mind I have changed its basics very little since I > introduced it, wait, this was > 20 years ago, 1995-6 or so).Ah! I had a mistaken impression as to how the user interacts with your instrument! I had assumed it was mainly a data collection device and any real interaction/analysis was done on an attached PC (even if that attachment was over the network).>> I tried to avoid building many tools for my system -- beyond ones that >> let me watch transactions across multiple processors (e.g., flatten >> RPCs so they look like simple function calls -- though annotated with >> system timestamps and related metrics). Here, that's the toughest >> aspect of debugging to wrap your head around (as the actual function >> isn't executing on the node that initiates it so watching execution is >> problematic). > > I also do tooling "on demand", like everyone else I suppose.Yes, esp if your needs don't fit neatly with existing tools (or design approaches)>> And, a simple monitor that lets me attach a console to a node and step >> through code, pull down binaries over the network, check clock >> synchronization, etc. "Old tech" :> > > Oh I am using a monitor which is the basic part of the ROM like > forever, a new board still first comes up talking through an UART > (the flash being written to using boundary scan via jtag, never > had the details of the debug port beyond that, an NDA was not > enough for it and well, I can live without it anyway).Likewise. In my case (on production hardware), the serial port is just a set of pads that can be probed with the right "accessory" (similar to many consumer devices -- except I don't "dedicate" the I/Os to that purpose). If the monitor detects that accessory as being present, then it configures the I/Os as necessary and then spawns a console on that port (overriding any intended use for those pins)> On a booted system it is the same monitor only the terminal is a > window via a "link" driver and a task entering the monitor > does not block the scheduler (but try to have a second task > exit to the monitor while the first one is in it and wait for > the reboot :).My monitor runs in several different modes. In single-threaded mode it controls the processor exclusively -- sort of like the monitors of decades past. This is primarily useful for bringing up new I/O subsystems as I can peek and poke various bits of the hardware without worrying about anything else running on the board. In multi-threaded mode, it (can) "attaches" to a process and let the rest of the system operate normally while the attached process is subject to the control of the monitor. This is more useful in bringing up core services -- like debugging the initial network stack (used before the OS and *its* stack is loaded) -- as it lets other services on the node run that the new service may rely upon (e.g., timing services). Bootstrap is painfully complicated because the code all has to be loaded over the wire. And, the boot ROM doesn't know what I/Os are present on the local node. Plus, the whole transaction has to be "secure" so a node can't be compromised. And, because there is no user interface (other than an idiot light), a node has to convey "issues" to the rest of the system indirectly (and hope something else can get the user's attention). E.g., after power is applied, the PSE expects a hardware handshake in a certain short interval - else it will remove power (this to safeguard against the processor being insane and the hardware being in an indeterminate state -- you wouldn't want a mechanism "in motion" because the hardware had faulted. So, there are lots of "baby steps" between application of power and the intended invocation of "main()". I suspect I will remove the monitor functionality from the boot ROM image as it is unlikely that anyone will ever try to debug (at that level) in the field. In consumer applications, they'll just replace a node thinking it to be "defective". In industrial and commercial applications, they'll swap out a node as downtime isn't worth the cost of diagnosis. [And, I'm not sure how vulnerable things would be if I left this sort of "back door" in such an accessible place!]> I made a (now pretty old) version of this monitor freely available, > there has been no huge crowd downloading it but from time to time > someone does. ( http://tgi-sci.com/tgi/download/m52.htm )My monitors have evolved from simple to incredibly complex (including support for breakpoint and trace hardware before processors had those abilities). And, now, back to simpler (with the exception of things like support for VMM). As with most things, old ideas become new and the cycle endlessly repeats.
Reply by ●January 10, 20222022-01-10
On 1/10/2022 3:55 AM, Carlos E.R. wrote:> On 08/01/2022 14.18, Jeroen Belleman wrote: >> For years, interaction with the internet worked through a >> universal browser. Lately, every service, gadget or whatnot >> wants you to download their special-purpose app. Why?? >> What's the deal? It seems like a huge step backwards to me. > > Not being limited by the browser. > > For example, a radio station promotes their own app to listen to that station. > To make it run, you have to login, so they have you pinpointed. Once there, you > can not refuse their adverts. Your privacy is lost. Of course, they also > provide features to entice you and keep you in.Using any device with it's own unique identifier (think MAC) means your privacy is lost. "I" may not know who you are, today, when I encounter your "identifier". But, if I kabitz with others -- esp places where you are likely to identify yourself directly (like a login/UID) or indirectly (like making a credit card purchase) -- then the identifiers can be correlated and augmented, over time. Amazon, ebay, google, etc. all "recognize" me even without logging in. Even if I *never* log in! Because they can see my IP, fingerprint my browser, etc. So, when/if I ever *do* make a purchase (or otherwise identify myself), they can now *add* my identity to the past observations they have made about my interests, activities, etc.> Even if you close the app, it can keep running in the background, and for > example, tell you that your favourite program is coming now.You can do the same with a browser. But, it is a considerably heavier weight process -- because it has to cover more contingencies -- than an app using (ONLY) the resources that it needs for given functionality.
