Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?
<https://www.vortex86.com/products>
(no financial affiliation)
bitrex <user@example.net> wrote in news:ONPVJ.66196$yi_7.35911
@fx39.iad:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?
<https://www.vortex86.com/products>
(no financial affiliation)
I did not see "486" it says "X86".
Likely a 386 'like' core. I doubt it got copied without big problems
with the 486 API and micro-architecture.
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?
<https://www.vortex86.com/products>
(no financial affiliation)
I really do not know, I use Raspberries these days,
so far so good.
Just add one if needed, 8 GB RAM build in.
Quad core each.
The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware
acceleration PC is dead
There are maller boards with less RAM that make good embedded
systems
https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software
Lighter, smaller, cheaper etc etc :-0)
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote in news:t09n79$ak2$1@dont-email.me:
I really do not know, I use Raspberries these days,
so far so good.
Just add one if needed, 8 GB RAM build in.
Quad core each.
The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware
acceleration PC is dead
There are maller boards with less RAM that make good embedded
systems
https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software
Lighter, smaller, cheaper etc etc :-0)
Wow, this inane verging on croaking angry old fucktard actually did
something right. Amazing!
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrex <us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?
<https://www.vortex86.com/products>
(no financial affiliation)I really do not know, I use Raspberries these days,
so far so good.
Just add one if needed, 8 GB RAM build in.
Quad core each.
The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot, analog audio out,
USB slots, low power, video hardware acceleration
PC is dead
There are maller boards with less RAM that make good embedded systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7 here.
All sorts of oen source software
Lighter, smaller, cheaper etc etc :-0)
On 3/9/2022 4:18 AM, DecadentLinux...@decadence.org wrote:
Jan Panteltje <pNaonSt...@yahoo.com> wrote in news:t09n79$ak2$1...@dont-email.me:
I really do not know, I use Raspberries these days,
so far so good.
Just add one if needed, 8 GB RAM build in.
Quad core each.
The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware
acceleration PC is dead
There are maller boards with less RAM that make good embedded
systems
https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software
Lighter, smaller, cheaper etc etc :-0)
Wow, this inane verging on croaking angry old fucktard actually did something right. Amazing!I think you finally went off your rocker.
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan Panteltje
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrex
<us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so good.
<https://www.vortex86.com/products>
(no financial affiliation)
Just add one if needed, 8 GB RAM build in. Quad core each. The
latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware acceleration
PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc etc
:-0)
Than what? These chips appear to be a pretty complete solution to a
lot of problems. Your rPi has multiple chips on board and that runs
up the cost.
The rPi got a start only because a bunch of money was
thrown at it with no expectation of making a profit.
If the same was
done with these devices I expect a lower cost device could be made
and would become popular because of running Windows as well as Linux
and other OS.
There's nothing magical about the rPi.
There's nothing magical about
the ARM processors they are built on.
On 3/9/2022 4:18 AM, DecadentLinuxUserNumeroUno@decadence.orgwrote:
didJan Panteltje <pNaonStpealmtje@yahoo.com> wrote in
news:t09n79$ak2$1@dont-email.me:
I really do not know, I use Raspberries these days,
so far so good.
Just add one if needed, 8 GB RAM build in.
Quad core each.
The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware
acceleration PC is dead
There are maller boards with less RAM that make good embedded
systems
https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software
Lighter, smaller, cheaper etc etc :-0)
Wow, this inane verging on croaking angry old fucktard actually
something right. Amazing!
I think you finally went off your rocker.
On Wednesday, March 9, 2022 at 10:16:50 AM UTC-5, amdx wrote:
On 3/9/2022 4:18 AM, DecadentLinux...@decadence.org wrote:
Jan Panteltje <pNaonSt...@yahoo.com> wrote inI think you finally went off your rocker.
news:t09n79$ak2$1...@dont-email.me:
I really do not know, I use Raspberries these days,
so far so good.
Just add one if needed, 8 GB RAM build in.
Quad core each.
The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card
slot, analog audio out, USB slots, low power, video hardware
acceleration PC is dead
There are maller boards with less RAM that make good embedded
systems
https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years
24/7 here.
All sorts of oen source software
Lighter, smaller, cheaper etc etc :-0)
Wow, this inane verging on croaking angry old fucktard actually
did something right. Amazing!
That's assuming he was ever on it.
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?
<https://www.vortex86.com/products>
(no financial affiliation)
Than what? These chips appear to be a pretty complete solution to
a lot of problems. Your rPi has multiple chips on board and that
runs up the cost.
On 09/03/2022 16:39, Rick C wrote:
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan Panteltje
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrex
<us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so good.
<https://www.vortex86.com/products>
(no financial affiliation)
Just add one if needed, 8 GB RAM build in. Quad core each. The
latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware acceleration
PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc etc
:-0)
Than what? These chips appear to be a pretty complete solution to aNot many - most of it is in the system-on-a-chip. There are cheaper
lot of problems. Your rPi has multiple chips on board and that runs
up the cost.
embedded Linux cards, but not /much/ cheaper.
The rPi got a start only because a bunch of money wasYes, that's how it started. Then it took off, and it is
thrown at it with no expectation of making a profit.
self-sustaining. The boards are not subsidised. (Nor do the folks
behind it try to make a significant profit.)
If the same was
done with these devices I expect a lower cost device could be made
and would become popular because of running Windows as well as Linux
and other OS.
There have never been any x86 devices at this level that match ARM-based systems for price or power. It's probably not impossible, but basic ARM cores need less die space and less power. Once your costs are dominated
by caches, big SIMD blocks, and the like, it can be a fairer fight.
Would anyone want to run Windows on small devices like this? I guess
people would like it in theory, but in practice Windows is painful even
on small Intel devices. Windows is very much a minor player in embedded cards, even x86 ones. But I expect some of these Vortex chips will be
useful in updates of legacy systems - after all, there are still
embedded systems running DOS (and FreeDOS made a new release recently).
There's nothing magical about the rPi.True.
There's nothing magical aboutTrue.
the ARM processors they are built on.
Other cores could be used. MIPS would make sense if any of the big manufacturers took the chance - but these days, RISC-V is the one to watch.
Other cores could be used. MIPS would make sense if any of the
big manufacturers took the chance - but these days, RISC-V is the
one to watch.
On Wednesday, March 9, 2022 at 11:43:46 AM UTC-5, David Brown wrote:profit company and barely was a breakeven for a non-profit, in addition to the publicity from being a non-profit targeting "education". In Musk's case they never made a profit at $35,000 and now you have to spend something like $45,000 for an entry level
On 09/03/2022 16:39, Rick C wrote:
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan Panteltje
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrex
<us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so good.
<https://www.vortex86.com/products>
(no financial affiliation)
Just add one if needed, 8 GB RAM build in. Quad core each. The
latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware acceleration
PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc etc
:-0)
Ah, so you agree. It's nice for people to support once in a while rather than always arguing.Than what? These chips appear to be a pretty complete solution to aNot many - most of it is in the system-on-a-chip. There are cheaper embedded Linux cards, but not /much/ cheaper.
lot of problems. Your rPi has multiple chips on board and that runs
up the cost.
Didn't say they were. My point is there's not a lot of opportunity to compete given the cost and risk of ramping up a similar project. What made the rPi a success was the Musk approach of announcing a price point that was not sustainable by a for-The rPi got a start only because a bunch of money wasYes, that's how it started. Then it took off, and it is
thrown at it with no expectation of making a profit.
self-sustaining. The boards are not subsidised. (Nor do the folks
behind it try to make a significant profit.)
with a 23 inch monitor and keyboard. He just likes the convenience of the interface, since that's what is used by 99% of people who aren't geeks.If the same was
done with these devices I expect a lower cost device could be made
and would become popular because of running Windows as well as Linux
and other OS.
There have never been any x86 devices at this level that match ARM-based systems for price or power. It's probably not impossible, but basic ARM cores need less die space and less power. Once your costs are dominatedSo you have the details that show this to be the case for the Vortex86?
by caches, big SIMD blocks, and the like, it can be a fairer fight.
Would anyone want to run Windows on small devices like this? I guess people would like it in theory, but in practice Windows is painful evenYou don't know what the market is for a small Windows machine. It has the one humongous advantage of not having to learn Linux. I know a guy who uses a complete small form factor PC for similar things as an rPi would be used for by others, complete
on small Intel devices. Windows is very much a minor player in embedded cards, even x86 ones. But I expect some of these Vortex chips will be useful in updates of legacy systems - after all, there are still
embedded systems running DOS (and FreeDOS made a new release recently).
up using.There's nothing magical about the rPi.True.
There's nothing magical aboutTrue.
the ARM processors they are built on.
Other cores could be used. MIPS would make sense if any of the big manufacturers took the chance - but these days, RISC-V is the one to watch.You are thinking like a geek. Windows is not for geeks. Maybe, if you try hard enough, you can think like a person who isn't a geek. It is not always about which is the "better" product. Beta was a better video tape format, but VHS was the one we ended
onsdag den 9. marts 2022 kl. 18.35.59 UTC+1 skrev gnuarm.del...@gmail.com:profit company and barely was a breakeven for a non-profit, in addition to the publicity from being a non-profit targeting "education". In Musk's case they never made a profit at $35,000 and now you have to spend something like $45,000 for an entry level
On Wednesday, March 9, 2022 at 11:43:46 AM UTC-5, David Brown wrote:
On 09/03/2022 16:39, Rick C wrote:Ah, so you agree. It's nice for people to support once in a while rather than always arguing.
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan PanteltjeNot many - most of it is in the system-on-a-chip. There are cheaper
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrex
<us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so good.
<https://www.vortex86.com/products>
(no financial affiliation)
Just add one if needed, 8 GB RAM build in. Quad core each. The
latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware acceleration
PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc etc
:-0)
Than what? These chips appear to be a pretty complete solution to a
lot of problems. Your rPi has multiple chips on board and that runs
up the cost.
embedded Linux cards, but not /much/ cheaper.
Didn't say they were. My point is there's not a lot of opportunity to compete given the cost and risk of ramping up a similar project. What made the rPi a success was the Musk approach of announcing a price point that was not sustainable by a for-The rPi got a start only because a bunch of money wasYes, that's how it started. Then it took off, and it is
thrown at it with no expectation of making a profit.
self-sustaining. The boards are not subsidised. (Nor do the folks
behind it try to make a significant profit.)
with a 23 inch monitor and keyboard. He just likes the convenience of the interface, since that's what is used by 99% of people who aren't geeks.So you have the details that show this to be the case for the Vortex86?If the same wasThere have never been any x86 devices at this level that match ARM-based >>> systems for price or power. It's probably not impossible, but basic ARM
done with these devices I expect a lower cost device could be made
and would become popular because of running Windows as well as Linux
and other OS.
cores need less die space and less power. Once your costs are dominated
by caches, big SIMD blocks, and the like, it can be a fairer fight.
Would anyone want to run Windows on small devices like this? I guessYou don't know what the market is for a small Windows machine. It has the one humongous advantage of not having to learn Linux. I know a guy who uses a complete small form factor PC for similar things as an rPi would be used for by others, complete
people would like it in theory, but in practice Windows is painful even
on small Intel devices. Windows is very much a minor player in embedded
cards, even x86 ones. But I expect some of these Vortex chips will be
useful in updates of legacy systems - after all, there are still
embedded systems running DOS (and FreeDOS made a new release recently).
but 32bit windows is going the way of the dinosaurs, afaik OEMs have not been able to get windows in 32 bit for few years, and win11 is 64bit onlyended up using.
There's nothing magical about the rPi.True.
There's nothing magical aboutTrue.
the ARM processors they are built on.
Other cores could be used. MIPS would make sense if any of the big
manufacturers took the chance - but these days, RISC-V is the one to watch. >> You are thinking like a geek. Windows is not for geeks. Maybe, if you try hard enough, you can think like a person who isn't a geek. It is not always about which is the "better" product. Beta was a better video tape format, but VHS was the one we
but who other that someone needing to run some prehistoric 32 bit x86 application in some kind of embedded device has any use for a 486?
Lasse Langwadt Christensen wrote:profit company and barely was a breakeven for a non-profit, in addition to the publicity from being a non-profit targeting "education". In Musk's case they never made a profit at $35,000 and now you have to spend something like $45,000 for an entry level
onsdag den 9. marts 2022 kl. 18.35.59 UTC+1 skrev gnuarm.del...@gmail.com:
On Wednesday, March 9, 2022 at 11:43:46 AM UTC-5, David Brown wrote:
On 09/03/2022 16:39, Rick C wrote:Ah, so you agree. It's nice for people to support once in a while rather than always arguing.
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan PanteltjeNot many - most of it is in the system-on-a-chip. There are cheaper
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrex >>>>> <us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so good. >>>>> Just add one if needed, 8 GB RAM build in. Quad core each. The
<https://www.vortex86.com/products>
(no financial affiliation)
latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot, >>>>> analog audio out, USB slots, low power, video hardware acceleration >>>>> PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc etc >>>>> :-0)
Than what? These chips appear to be a pretty complete solution to a >>>> lot of problems. Your rPi has multiple chips on board and that runs >>>> up the cost.
embedded Linux cards, but not /much/ cheaper.
Didn't say they were. My point is there's not a lot of opportunity to compete given the cost and risk of ramping up a similar project. What made the rPi a success was the Musk approach of announcing a price point that was not sustainable by a for-The rPi got a start only because a bunch of money wasYes, that's how it started. Then it took off, and it is
thrown at it with no expectation of making a profit.
self-sustaining. The boards are not subsidised. (Nor do the folks
behind it try to make a significant profit.)
with a 23 inch monitor and keyboard. He just likes the convenience of the interface, since that's what is used by 99% of people who aren't geeks.So you have the details that show this to be the case for the Vortex86? >>> Would anyone want to run Windows on small devices like this? I guessIf the same wasThere have never been any x86 devices at this level that match ARM-based >>> systems for price or power. It's probably not impossible, but basic ARM >>> cores need less die space and less power. Once your costs are dominated >>> by caches, big SIMD blocks, and the like, it can be a fairer fight.
done with these devices I expect a lower cost device could be made
and would become popular because of running Windows as well as Linux >>>> and other OS.
people would like it in theory, but in practice Windows is painful even >>> on small Intel devices. Windows is very much a minor player in embedded >>> cards, even x86 ones. But I expect some of these Vortex chips will be >>> useful in updates of legacy systems - after all, there are still
embedded systems running DOS (and FreeDOS made a new release recently). >> You don't know what the market is for a small Windows machine. It has the one humongous advantage of not having to learn Linux. I know a guy who uses a complete small form factor PC for similar things as an rPi would be used for by others, complete
ended up using.but 32bit windows is going the way of the dinosaurs, afaik OEMs have not been able to get windows in 32 bit for few years, and win11 is 64bit only
You are thinking like a geek. Windows is not for geeks. Maybe, if you try hard enough, you can think like a person who isn't a geek. It is not always about which is the "better" product. Beta was a better video tape format, but VHS was the one weThere's nothing magical about the rPi.True.
There's nothing magical aboutTrue.
the ARM processors they are built on.
Other cores could be used. MIPS would make sense if any of the big
manufacturers took the chance - but these days, RISC-V is the one to watch.
but who other that someone needing to run some prehistoric 32 bit x86 application in some kind of embedded device has any use for a 486?
Hey, I can run DosBox on my phone!
David Brown <david.brown@hesbynett.no> wrote in news:t0alfn$rru$1@dont-email.me:
Other cores could be used. MIPS would make sense if any of the
big manufacturers took the chance - but these days, RISC-V is the
one to watch.
They should have continued developing and upgrading the Cell
processor, but that was doomed by the fact that multiple companies were involved who were long time competitors with each other.
But it was a hell of a CPU, and little lab sized super computers were
even made from it using game consoles, so it was pretty robsut for it's
day and could have easily scaled up to beat Intel or AMD's crap.
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan Panteltje wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrexout,
<us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days,
<https://www.vortex86.com/products>
(no financial affiliation)
so far so good.
Just add one if needed, 8 GB RAM build in.
Quad core each.
The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot, analog audio
USB slots, low power, video hardware acceleration
PC is dead
There are maller boards with less RAM that make good embedded systems
https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7 here.
All sorts of oen source software
Lighter, smaller, cheaper etc etc :-0)
Than what? These chips appear to be a pretty complete solution to a lot of >problems. Your rPi has multiple chips on board and that runs up the cost.
The rPi got a start only because a bunch of money was thrown at it with no
expectation of making a profit. If the same was done with these devices I >expect a lower cost device could be made and would become popular because
of running Windows as well as Linux and other OS.
There's nothing magical about the rPi. There's nothing magical about the ARM >processors they are built on.
Most electronics is reliable. You actually
have to work pretty hard to design non-power electronics that isn't reliable.
It's inherent in the nature of electronics these days.
On Wednesday, March 9, 2022 at 11:43:46 AM UTC-5, David Brown wrote:
On 09/03/2022 16:39, Rick C wrote:
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan PanteltjeNot many - most of it is in the system-on-a-chip. There are cheaper
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened
bitrex <us...@example.net> wrote in
<ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so
<https://www.vortex86.com/products>
(no financial affiliation)
good. Just add one if needed, 8 GB RAM build in. Quad core
each. The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card
slot, analog audio out, USB slots, low power, video hardware
acceleration PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc
etc :-0)
Than what? These chips appear to be a pretty complete solution to
a lot of problems. Your rPi has multiple chips on board and that
runs up the cost.
embedded Linux cards, but not /much/ cheaper.
Ah, so you agree. It's nice for people to support once in a while
rather than always arguing.
The rPi got a start only because a bunch of money was thrown atYes, that's how it started. Then it took off, and it is
it with no expectation of making a profit.
self-sustaining. The boards are not subsidised. (Nor do the folks
behind it try to make a significant profit.)
Didn't say they were. My point is there's not a lot of opportunity
to compete given the cost and risk of ramping up a similar project.
What made the rPi a success was the Musk approach of announcing a
price point that was not sustainable by a for-profit company and
barely was a breakeven for a non-profit, in addition to the publicity
from being a non-profit targeting "education".
In Musk's case they
never made a profit at $35,000 and now you have to spend something
like $45,000 for an entry level car. The rPi is a lot more than $25
now. I see a model for $75. Yup, they took a page out of Elon
Musk's playbook.
If the same was done with these devices I expect a lower costThere have never been any x86 devices at this level that match
device could be made and would become popular because of running
Windows as well as Linux and other OS.
ARM-based systems for price or power. It's probably not impossible,
but basic ARM cores need less die space and less power. Once your
costs are dominated by caches, big SIMD blocks, and the like, it
can be a fairer fight.
So you have the details that show this to be the case for the
Vortex86?
Would anyone want to run Windows on small devices like this? I
guess people would like it in theory, but in practice Windows is
painful even on small Intel devices. Windows is very much a minor
player in embedded cards, even x86 ones. But I expect some of these
Vortex chips will be useful in updates of legacy systems - after
all, there are still embedded systems running DOS (and FreeDOS made
a new release recently).
You don't know what the market is for a small Windows machine. It
has the one humongous advantage of not having to learn Linux. I know
a guy who uses a complete small form factor PC for similar things as
an rPi would be used for by others, complete with a 23 inch monitor
and keyboard. He just likes the convenience of the interface, since
that's what is used by 99% of people who aren't geeks.
There's nothing magical about the rPi.True.
There's nothing magical about the ARM processors they are builtTrue.
on.
Other cores could be used. MIPS would make sense if any of the big
manufacturers took the chance - but these days, RISC-V is the one
to watch.
You are thinking like a geek. Windows is not for geeks. Maybe, if
you try hard enough, you can think like a person who isn't a geek.
It is not always about which is the "better" product. Beta was a
better video tape format, but VHS was the one we ended up using.
but who other that someone needing to run some prehistoric 32 bit x86 application in some kind of embedded device has any use for a 486?
On 09/03/2022 18:29, DecadentLinuxUserNumeroUno@decadence.org
wrote:
David Brown <david.brown@hesbynett.no> wrote in
news:t0alfn$rru$1@dont-email.me:
Other cores could be used. MIPS would make sense if any of the
big manufacturers took the chance - but these days, RISC-V is
the one to watch.
They should have continued developing and upgrading the Cell
processor, but that was doomed by the fact that multiple
companies were involved who were long time competitors with each
other.
But it was a hell of a CPU, and little lab sized super
computers were
even made from it using game consoles, so it was pretty robsut
for it's day and could have easily scaled up to beat Intel or
AMD's crap.
You must be thinking of something other than <https://en.wikipedia.org/wiki/Cell_(microprocessor)>. The
PowerPC ISA has many good points - low cost and low power are not
amongst them. The Cell was a very specialist kind of chip, and
very different from the general-purpose systems-on-a-chip under
discussion.
onsdag den 9. marts 2022 kl. 18.35.59 UTC+1 skrev gnuarm.del...@gmail.com:profit company and barely was a breakeven for a non-profit, in addition to the publicity from being a non-profit targeting "education". In Musk's case they never made a profit at $35,000 and now you have to spend something like $45,000 for an entry level
On Wednesday, March 9, 2022 at 11:43:46 AM UTC-5, David Brown wrote:
On 09/03/2022 16:39, Rick C wrote:
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan Panteltje
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened bitrex
<us...@example.net> wrote in <ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so good. >> Just add one if needed, 8 GB RAM build in. Quad core each. The
<https://www.vortex86.com/products>
(no financial affiliation)
latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card slot,
analog audio out, USB slots, low power, video hardware acceleration >> PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc etc
:-0)
Ah, so you agree. It's nice for people to support once in a while rather than always arguing.Than what? These chips appear to be a pretty complete solution to a lot of problems. Your rPi has multiple chips on board and that runsNot many - most of it is in the system-on-a-chip. There are cheaper embedded Linux cards, but not /much/ cheaper.
up the cost.
Didn't say they were. My point is there's not a lot of opportunity to compete given the cost and risk of ramping up a similar project. What made the rPi a success was the Musk approach of announcing a price point that was not sustainable by a for-The rPi got a start only because a bunch of money wasYes, that's how it started. Then it took off, and it is
thrown at it with no expectation of making a profit.
self-sustaining. The boards are not subsidised. (Nor do the folks
behind it try to make a significant profit.)
with a 23 inch monitor and keyboard. He just likes the convenience of the interface, since that's what is used by 99% of people who aren't geeks.If the same was
done with these devices I expect a lower cost device could be made
and would become popular because of running Windows as well as Linux and other OS.
There have never been any x86 devices at this level that match ARM-based systems for price or power. It's probably not impossible, but basic ARM cores need less die space and less power. Once your costs are dominated by caches, big SIMD blocks, and the like, it can be a fairer fight.So you have the details that show this to be the case for the Vortex86?
Would anyone want to run Windows on small devices like this? I guess people would like it in theory, but in practice Windows is painful even on small Intel devices. Windows is very much a minor player in embedded cards, even x86 ones. But I expect some of these Vortex chips will be useful in updates of legacy systems - after all, there are still embedded systems running DOS (and FreeDOS made a new release recently).You don't know what the market is for a small Windows machine. It has the one humongous advantage of not having to learn Linux. I know a guy who uses a complete small form factor PC for similar things as an rPi would be used for by others, complete
but 32bit windows is going the way of the dinosaurs, afaik OEMs have not been able to get windows in 32 bit for few years, and win11 is 64bit onlyended up using.
There's nothing magical about the rPi.True.
There's nothing magical aboutTrue.
the ARM processors they are built on.
Other cores could be used. MIPS would make sense if any of the big manufacturers took the chance - but these days, RISC-V is the one to watch.You are thinking like a geek. Windows is not for geeks. Maybe, if you try hard enough, you can think like a person who isn't a geek. It is not always about which is the "better" product. Beta was a better video tape format, but VHS was the one we
but who other that someone needing to run some prehistoric 32 bit x86 application in some kind of embedded device has any use for a 486?
On 09/03/2022 18:35, Rick C wrote:
On Wednesday, March 9, 2022 at 11:43:46 AM UTC-5, David Brown wrote:
On 09/03/2022 16:39, Rick C wrote:
On Wednesday, March 9, 2022 at 3:07:16 AM UTC-5, Jan PanteltjeNot many - most of it is in the system-on-a-chip. There are cheaper
wrote:
On a sunny day (Tue, 8 Mar 2022 16:21:49 -0500) it happened
bitrex <us...@example.net> wrote in
<ONPVJ.66196$yi_7....@fx39.iad>:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?I really do not know, I use Raspberries these days, so far so
<https://www.vortex86.com/products>
(no financial affiliation)
good. Just add one if needed, 8 GB RAM build in. Quad core
each. The latest ones can run 64 bit Linux.
Wifi, Bluetooth, **I/O pins**, Ethernet, HDMI, microSD card
slot, analog audio out, USB slots, low power, video hardware
acceleration PC is dead
There are maller boards with less RAM that make good embedded
systems https://en.wikipedia.org/wiki/Raspberry_Pi
Reliable, some older models have been running for 10 years 24/7
here.
All sorts of oen source software Lighter, smaller, cheaper etc
etc :-0)
Than what? These chips appear to be a pretty complete solution to
a lot of problems. Your rPi has multiple chips on board and that
runs up the cost.
embedded Linux cards, but not /much/ cheaper.
Ah, so you agree. It's nice for people to support once in a whileIt's possible to do some googling and look at prices for small embedded Linux boards - including the Pi range (which includes "lite" and "zero" variants). Prices are similar at the low end, varying a little
rather than always arguing.
depending on hardware details. More "professional" or "industrial"
cards are, of course, more expensive - but come with more support, or physical testing, or commitments to long-term availability.
The rPi got a start only because a bunch of money was thrown atYes, that's how it started. Then it took off, and it is
it with no expectation of making a profit.
self-sustaining. The boards are not subsidised. (Nor do the folks
behind it try to make a significant profit.)
Didn't say they were. My point is there's not a lot of opportunityThere are plenty of competitor cards now. But the Pi opened the market.
to compete given the cost and risk of ramping up a similar project.
What made the rPi a success was the Musk approach of announcing aIt would have been a success if it had been 10% more expensive - a solid margin for profit. It would still have been /much/ cheaper than
price point that was not sustainable by a for-profit company and
barely was a breakeven for a non-profit, in addition to the publicity
from being a non-profit targeting "education".
alternatives of the time.
What made it a success was the involvement of Broadcom, and the
marketing as an educational tool. At the time the Pi was conceived, you couldn't get any information on any Broadcom device unless you were
planning on buying 100,000 devices a year. They made (amongst other
things) system-on-a-chip devices for set-top boxes and that kind of
thing. These were ideal for a small, cheap Linux card, but completely
out of reach for small developers. The Pi concept was developed by a
group that included a high-ranking Broadcom employee, who persuaded the company that this would be a great marketing opportunity. This is what
lead to Pi being realisable at a much lower price point than other
embedded Linux cards at the time, which used chips such as Freescale
i.mx devices.
In Musk's case they
never made a profit at $35,000 and now you have to spend something
like $45,000 for an entry level car. The rPi is a lot more than $25
now. I see a model for $75. Yup, they took a page out of Elon
Musk's playbook.
You get a Pi 3 for $35 - that's not at all bad, compared to the first Pi
for $25 a decade ago. You get a lot more variants now, including "Zero" boards for $10 - $15, up to Pi 4 with 8 GB ram for $75.
I can't answer for Musk, but I really don't think it's fair to say the
Pi was introduced and advertised at an artificially low price. It was
as low as they could manage, but not lower.
If the same was done with these devices I expect a lower costThere have never been any x86 devices at this level that match
device could be made and would become popular because of running
Windows as well as Linux and other OS.
ARM-based systems for price or power. It's probably not impossible,
but basic ARM cores need less die space and less power. Once your
costs are dominated by caches, big SIMD blocks, and the like, it
can be a fairer fight.
So you have the details that show this to be the case for the
Vortex86?
No. That's why I said "it's probably not impossible", but certainly it hasn't been achieved before. (And if the Vortex folk manage it, that's great.)
Would anyone want to run Windows on small devices like this? I
guess people would like it in theory, but in practice Windows is
painful even on small Intel devices. Windows is very much a minor
player in embedded cards, even x86 ones. But I expect some of these
Vortex chips will be useful in updates of legacy systems - after
all, there are still embedded systems running DOS (and FreeDOS made
a new release recently).
You don't know what the market is for a small Windows machine. It
has the one humongous advantage of not having to learn Linux. I know
a guy who uses a complete small form factor PC for similar things as
an rPi would be used for by others, complete with a 23 inch monitor
and keyboard. He just likes the convenience of the interface, since
that's what is used by 99% of people who aren't geeks.
It all depends on what you are doing with the device. I don't want to
go into Windows vs. Linux wars (I use Windows /and/ Linux, and need both
for my work, and each has its pros and cons). But you can do more with
Linux on a small system than you can with Windows. There's nothing
wrong with having a small machine for running Windows - these days small form-factor machines are fine for most purposes. However, the minimum
level of computing power (processor power, ram, disk space) needed to do something useful with Windows is a lot higher than the minimum needed
for Linux.
There's nothing magical about the rPi.True.
There's nothing magical about the ARM processors they are builtTrue.
on.
Other cores could be used. MIPS would make sense if any of the big
manufacturers took the chance - but these days, RISC-V is the one
to watch.
You are thinking like a geek. Windows is not for geeks. Maybe, if
you try hard enough, you can think like a person who isn't a geek.
It is not always about which is the "better" product. Beta was a
better video tape format, but VHS was the one we ended up using.
Most people these days have more Linux machines than Windows machines -
they just don't realise it.
"Geek" is about what you do with the
machine, not what OS it has - I am a geek whether I use my Windows PC or
my Linux PC. My mother-in-law is not a geek, though both her desktop
and her laptop run Linux and she hasn't seen Windows for a couple of decades.
However, these kinds of small computers are not aimed at everyday use as
a main PC by a non-geek. They are aimed at people who know what they
are doing - or are learning to know what they are doing. Very few
people use Pi's as a main PC, and very few will use Vortex-based cards
as a main PC (Windows or Linux).
On 3/9/2022 1:29 PM, Lasse Langwadt Christensen wrote:
but who other that someone needing to run some prehistoric 32 bit x86
application in some kind of embedded device has any use for a 486?
I think embedded is the market segment but 32 bit x86 is still a large
market segment thanks to a lil prolific shit bird of an OS called
Windows CE, which likely runs pretty snappy on a 1 GHz 486-ish processor
and is likely still running ten million e.g. mall information kiosks,
bowling alley scoring machines, and "rapid transit" fare card dispensers across this great US of A.
Nobody wants to re write that software, doing it sucked enough the first time.
David Brown <david.brown@hesbynett.no> wrote in news:t0b1b5$c5$1@dont-email.me:
On 09/03/2022 18:29, DecadentLinuxUserNumeroUno@decadence.org
wrote:
David Brown <david.brown@hesbynett.no> wrote in
news:t0alfn$rru$1@dont-email.me:
Other cores could be used. MIPS would make sense if any of the
big manufacturers took the chance - but these days, RISC-V is
the one to watch.
They should have continued developing and upgrading the Cell
processor, but that was doomed by the fact that multiple
companies were involved who were long time competitors with each
other.
But it was a hell of a CPU, and little lab sized super
computers were
even made from it using game consoles, so it was pretty robsut
for it's day and could have easily scaled up to beat Intel or
AMD's crap.
You must be thinking of something other than
<https://en.wikipedia.org/wiki/Cell_(microprocessor)>. The
PowerPC ISA has many good points - low cost and low power are not
amongst them. The Cell was a very specialist kind of chip, and
very different from the general-purpose systems-on-a-chip under
discussion.
Oh OK, so IF the discussion was SOC, and suddenly talking about CPU
power is off, then why did PanJan's rPi get accepted? It is not SOC
or SOM. It too is several components... perhaps using and SOM as
its core. The Cell was years ago, just as SOC ws getting going. So
it was just a CPU and all those accessories were peripherally added,
so sure, I guees not on par with theu guy posting a nice new chip.
It is decidedly not an SOC either. Or if you are talking about
just how many system elements are on the rPi's CPU, then sure. The
Cell had few system accessories built into it.
So OK... then. Before I got my rPi, I used a little known tiny PC
made in Isreal at a company called SolidRun that caters to everything
you are on about, and does so masterfully, but at a higher cost, and
other chips still have to added to make a system. An SOC, for
example cannot also have optical ports on it, like SFP, they are
externally added and just the data I/O goes through the system comm
lanes (bottom link).
<https://www.solid-run.com/embedded-networking/nxp-lx2160a- family/lx2162a-som/>
The little guy I had was an early consuner product they sold, but
they also mainly do SOM.
<https://www.solid-run.com/fanless-computers/cubox/>
<https://www.solid-run.com/embedded-networking/marvell-armada- family/clearfog/>
The Cell chip did have a few peripherals and controllers in the
chip. But the main point of the chip is that it has one fairly
solid general-purpose PowerPC core, and 9 (IIRC) specialised
PowerPC cores with dedicated memory, designed to be a flexible
graphics and game accelerator array. The peripherals on the
device are just a footnote.
They are aimed at anyone who buys them. I'm simply pointing out
there is a market for Windows users who don't want to learn a whole
'nother OS. Like me!
On 10/03/2022 04:54, Rick C wrote:
They are aimed at anyone who buys them. I'm simply pointing out
there is a market for Windows users who don't want to learn a whole
'nother OS. Like me!
You are actually in the segment of users that are most difficult to
"convert" to Linux - people who use their machines for a lot of
different purposes and have a long-term investment in the technical
details and quirks of Windows (whether you like the OS or not). Getting
to the same level of competence on a different system takes time and
effort, and naturally you'd rather avoid that.
That market is not as big as many people think. Most people use Windows machines for browsing, email, watching videos, light "Office" programs, games, and whatever programs their companies say they have to use. For
all but the last two points, you could install a user-friendly Linux distribution like Linux Mint, and people have their email, browsers,
office much like before. Details of appearances change, but they do
that between Windows versions too.
Games are a different matter - there is no doubt that Windows is the
prime platform for games. Steam works on Linux, and many games run fine
on it, but not all. And not all Windows games are on Steam.
Then there are programs used as part of your job. Some might be cross-platform, some might run under Wine, some won't. If I want to use Altium Designer, I use my Windows machine. Almost all of my coding and compiling is done on my Linux machine - but usually I also check that it
all builds fine on my Windows machine too. All my network stuff is
Linux only. For other people, with other programs and needs and
different levels of support and knowledge from their employer, results
will vary.
Common for most people, however, is that computers are tools, and no one wants to change things that they are used to and can work with. It
needs a lot of reason and motivation to change - and the more you have invested in learning about a system, the more reason you need to change.
David Brown <david.brown@hesbynett.no> wrote in news:t0cclc$uc9$1@dont-email.me:
The Cell chip did have a few peripherals and controllers in the
chip. But the main point of the chip is that it has one fairly
solid general-purpose PowerPC core, and 9 (IIRC) specialised
PowerPC cores with dedicated memory, designed to be a flexible
graphics and game accelerator array. The peripherals on the
device are just a footnote.
It had nine identical PowerPC cores and one was a manager and eight
were main compute cores.
It was a badass for its day except they made
it too slow, and then dropped it.
But folks were making their own
miniature supercomputers with a few Playstation consoles and some
software. One college lab used 96 IIRC.
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on >Linux. A few of those being able to run thru "Wine" or whatever makes little >difference, nobody wants their programs to run slower.
Linux is a server operating system.
The below description is pretty good but somewhat of an
understatement.
There are LOTS of programs, very important programs, that do not
run on Linux.
A few of those being able to run thru "Wine" or
whatever makes little difference,
nobody wants their programs to
run slower.
Linux is a server operating system.
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on Linux.
A few of those being able to run thru "Wine" or whatever makes little difference, nobody wants their programs to run slower.the difference is usually minor
Linux is a server operating system.
On 10/03/2022 02:04, bitrex wrote:
On 3/9/2022 1:29 PM, Lasse Langwadt Christensen wrote:
but who other that someone needing to run some prehistoric 32 bit x86
application in some kind of embedded device has any use for a 486?
I think embedded is the market segment but 32 bit x86 is still a large
market segment thanks to a lil prolific shit bird of an OS called
Windows CE, which likely runs pretty snappy on a 1 GHz 486-ish processor
and is likely still running ten million e.g. mall information kiosks,
bowling alley scoring machines, and "rapid transit" fare card dispensers
across this great US of A.
Nobody wants to re write that software, doing it sucked enough the first
time.
That is, I think, the market for this kind of chip. How big a market is another question. People don't want to re-write their software written
for Wince, 32-bit XP, DOS, or whatever. But they also don't want to
have to re-design their boards to use a new x86 chip - they'll use old
stock for as long as they can.
Then they will look at QEMU + Wine on ARM Linux, and see if it is good
enough yet. (I haven't tried it myself.)
On 3/10/2022 3:28 AM, David Brown wrote:
On 10/03/2022 02:04, bitrex wrote:
On 3/9/2022 1:29 PM, Lasse Langwadt Christensen wrote:
but who other that someone needing to run some prehistoric 32 bit x86
application in some kind of embedded device has any use for a 486?
I think embedded is the market segment but 32 bit x86 is still a large
market segment thanks to a lil prolific shit bird of an OS called
Windows CE, which likely runs pretty snappy on a 1 GHz 486-ish processor >>> and is likely still running ten million e.g. mall information kiosks,
bowling alley scoring machines, and "rapid transit" fare card dispensers >>> across this great US of A.
Nobody wants to re write that software, doing it sucked enough the first >>> time.
That is, I think, the market for this kind of chip. How big a market is
another question. People don't want to re-write their software written
for Wince, 32-bit XP, DOS, or whatever. But they also don't want to
have to re-design their boards to use a new x86 chip - they'll use old
stock for as long as they can.
Then they will look at QEMU + Wine on ARM Linux, and see if it is good
enough yet. (I haven't tried it myself.)
The city of Boston Massachusetts, with a transit network serving 5+
million residents, apparently has exactly two machines capable of
printing reduced-fare disability passes for the system, both of which
somehow broke and require waiting months for spare parts from some
German outfit called Scheidt & Bachmann, that could only be sourced from Germany.
<https://archive.ph/i8mRp>
Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail890690e1-28c2-4ca4-9c86-1508ef28fb57n@googlegroups.com> <t0cjcs$685$1@dont-email.me> <t0cqb3$v6o$1@dont-email.me>
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Newsgroups: sci.electronics.design
Subject: Re: Modern 486
Date: Thu, 10 Mar 2022 15:14:41 GMT
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <t0d4lt$280$2@dont-email.me>
References: <ONPVJ.66196$yi_7.35911@fx39.iad> <t09n79$ak2$1@dont-email.me> <ee216fe6-b723-4450-aaca-b77651628f9bn@googlegroups.com> <t0alfn$rru$1@dont-email.me> <3df81790-3b9b-4d81-b5af-d7ef6cbc5a32n@googlegroups.com> <t0b55m$hcm$1@dont-email.me> <
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Mar 2022 15:15:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="471da5809824e0ea060036ad941e7b38"; logging-data="2304"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/fJD25rjdgLRgZReEMJwhit0sCCyHacN0="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:0KT/oxcDZOoUpRcRW+vrE8H8LDE=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform NewsFleX homepage: http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
Xref: reader02.eternal-september.org sci.electronics.design:662604
On a sunny day (Thu, 10 Mar 2022 12:18:44 -0000 (UTC)) it happened John Doe <always.look@message.header> wrote in <t0cqb3$v6o$1@dont-email.me>:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on >>Linux. A few of those being able to run thru "Wine" or whatever makes little >>difference, nobody wants their programs to run slower.
Linux is a server operating system.
No way
There are likely more things running Linux than windows,
For example my Samsung big LCD TV runs Linux (yes the open source is on their site)
Almost all the little WiFi modems run a version of Linux, for example my Linksys ones.
Cameras, what not..
So many embedded systems run Linux, Linux is even present in some satellites. MS windows was dead when they integrated the GUI and OS and it became a salesman's trap for the customer.
Add to that programming in Cplushplush (a Crime Against Humanity language) and nobody sane wants windows it for embedded.
And all them android phones are basically Linux versions.
Path: eternal-september.org!reader02.eternal-september.org!aioe.org!5U2ooNuM5UP0Ynf/GmOnCg.user.46.165.242.91.POSTED!not-for-mail890690e1-28c2-4ca4-9c86-1508ef28fb57n@googlegroups.com> <t0cjcs$685$1@dont-email.me> <t0cqb3$v6o$1@dont-email.me>
From: DecadentLinuxUserNumeroUno@decadence.org
Newsgroups: sci.electronics.design
Subject: Re: Modern 486
Date: Thu, 10 Mar 2022 15:29:39 -0000 (UTC)
Organization: Aioe.org NNTP Server
Message-ID: <t0d5h3$12tt$1@gioia.aioe.org>
References: <ONPVJ.66196$yi_7.35911@fx39.iad> <t09n79$ak2$1@dont-email.me> <ee216fe6-b723-4450-aaca-b77651628f9bn@googlegroups.com> <t0alfn$rru$1@dont-email.me> <3df81790-3b9b-4d81-b5af-d7ef6cbc5a32n@googlegroups.com> <t0b55m$hcm$1@dont-email.me> <
Injection-Info: gioia.aioe.org; logging-data="35773"; posting-host="5U2ooNuM5UP0Ynf/GmOnCg.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org";
User-Agent: Xnews/5.04.25
X-Notice: Filtered by postfilter v. 0.9.2
Xref: reader02.eternal-september.org sci.electronics.design:662608
John Doe <always.look@message.header> wrote in news:t0cqb3$v6o$1@dont-email.me:
The below description is pretty good but somewhat of an
understatement.
You have no clue about OS efficacy.
There are LOTS of programs, very important programs, that do not
run on Linux.
Oh boy!
A few of those being able to run thru "Wine" or
whatever makes little difference,
It makes tons of difference, unless you try to do it with your old
POS 286.
nobody wants their programs to
run slower.
Modern PCs are so very very fast that the difference between many
app being in a VDM envelope or run direct is very little.
Linux is a server operating system.
You're an idiot. UNIX was and is a server OS, but the CAD industry
used UNIX workstations for years as the PC indiustry grew and became
fast enough to be 'workstation' class machines.
Linux was a PERSONAL OS derived from UNIX and can and is also
configurable to be a 'server OS', but operates as a personal OS just
fine.
There are 3D CAD apps and image manipulator app (gimp). all kinds of
apps specifically meant to run on Linux. That decidedly makes it
other than "a server OS" and that claim makes you other than computer
science knowledgeable.
The troll doesn't even know how to format a USENET post...
The reason Bozo cannot figure out how to get Google to keep from
breaking its lines in inappropriate places is because Bozo is
CLUELESS...
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on
Linux.
how many people need much more than a browser and maybe an "office" suite?
A few of those being able to run thru "Wine" or whatever makes littlethe difference is usually minor
difference, nobody wants their programs to run slower.
embedded stuff
Linux is a server operating system.
and many other things, it's greats for servers, desktops, all kind of
and there's about 3 billion Android devices
The troll doesn't even know how to format a USENET post...
The reason Bozo cannot figure out how to get Google to keep from
breaking its lines in inappropriate places is because Bozo is
CLUELESS...
Nothing but a silly troll...
--
Jan Panteltje <pNaonStpealmtje@yahoo.com> wrote:
Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Newsgroups: sci.electronics.design
Subject: Re: Modern 486
Date: Thu, 10 Mar 2022 15:14:41 GMT
Organization: A noiseless patient Spider
Lines: 24
Message-ID: <t0d4lt$280$2@dont-email.me>
References: <ONPVJ.66196$yi_7.35911@fx39.iad> <t09n79$ak2$1@dont-email.me> >> <ee216fe6-b723-4450-aaca-b77651628f9bn@googlegroups.com> <t0alfn$rru$1@dont-email.me> <3df81790-3b9b-4d81-b5af-d7ef6cbc5a32n@googlegroups.com> <t0b55m$hcm$1@dont-email.me>
<890690e1-28c2-4ca4-9c86-1508ef28fb57n@googlegroups.com> <t0cjcs$685$1@dont-email.me> <t0cqb3$v6o$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 10 Mar 2022 15:15:09 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="471da5809824e0ea060036ad941e7b38"; logging-data="2304";
mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/fJD25rjdgLRgZReEMJwhit0sCCyHacN0="
User-Agent: NewsFleX-1.5.7.5 (Linux-2.6.37.6)
Cancel-Lock: sha1:0KT/oxcDZOoUpRcRW+vrE8H8LDE=
X-Newsreader-location: NewsFleX-1.5.7.5 (c) 'LIGHTSPEED' off line news reader for the Linux platform NewsFleX homepage:
http://www.panteltje.com/panteltje/newsflex/ and ftp download ftp://sunsite.unc.edu/pub/linux/system/news/readers/
Xref: reader02.eternal-september.org sci.electronics.design:662604
On a sunny day (Thu, 10 Mar 2022 12:18:44 -0000 (UTC)) it happened John Doe >> <always.look@message.header> wrote in <t0cqb3$v6o$1@dont-email.me>:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on >>>Linux. A few of those being able to run thru "Wine" or whatever makes little >>>difference, nobody wants their programs to run slower.
Linux is a server operating system.
No way
There are likely more things running Linux than windows,
For example my Samsung big LCD TV runs Linux (yes the open source is on their site)
Almost all the little WiFi modems run a version of Linux, for example my Linksys ones.
Cameras, what not..
So many embedded systems run Linux, Linux is even present in some satellites.
MS windows was dead when they integrated the GUI and OS and it became a salesman's trap for the customer.
Add to that programming in Cplushplush (a Crime Against Humanity language) and nobody sane wants windows it for embedded.
And all them android phones are basically Linux versions.
The troll doesn't even know how to format a USENET post...
The reason Bozo cannot figure out how to get Google to keep from
breaking its lines in inappropriate places is because Bozo is
CLUELESS...
Path: eternal-september
The troll doesn't even know how to format a USENET post...
The reason Bozo cannot figure out how to get Google to keep from
breaking its lines in inappropriate places is because Bozo is
CLUELESS...
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on Linux. A few of those being able to run thru "Wine" or whatever makes little difference, nobody wants their programs to run slower.
Linux is a server operating system.
On 10/03/2022 04:54, Rick C wrote:
They are aimed at anyone who buys them. I'm simply pointing out
there is a market for Windows users who don't want to learn a whole 'nother OS. Like me!
You are actually in the segment of users that are most difficult to "convert" to Linux - people who use their machines for a lot of
different purposes and have a long-term investment in the technical
details and quirks of Windows (whether you like the OS or not). Getting
to the same level of competence on a different system takes time and
effort, and naturally you'd rather avoid that.
That market is not as big as many people think. Most people use Windows machines for browsing, email, watching videos, light "Office" programs, games, and whatever programs their companies say they have to use. For
all but the last two points, you could install a user-friendly Linux distribution like Linux Mint, and people have their email, browsers,
office much like before. Details of appearances change, but they do
that between Windows versions too.
Games are a different matter - there is no doubt that Windows is the
prime platform for games. Steam works on Linux, and many games run fine
on it, but not all. And not all Windows games are on Steam.
Then there are programs used as part of your job. Some might be cross-platform, some might run under Wine, some won't. If I want to use Altium Designer, I use my Windows machine. Almost all of my coding and compiling is done on my Linux machine - but usually I also check that it
all builds fine on my Windows machine too. All my network stuff is
Linux only. For other people, with other programs and needs and
different levels of support and knowledge from their employer, results
will vary.
Common for most people, however, is that computers are tools, and no one wants to change things that they are used to and can work with. It
needs a lot of reason and motivation to change - and the more you have invested in learning about a system, the more reason you need to change.
On 10/03/2022 13:18, John Doe wrote:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on Linux. A few of those being able to run thru "Wine" or whatever makes little
difference, nobody wants their programs to run slower.
Many programs run faster under Wine than natively under Windows. It all depends on what the program is doing.
Linux is a server operating system.
It is that too - it covers an incredibly wide range of use-cases.
Embedded systems, laptops, desktops, servers, virtual systems, gaming systems, routers, HPC - pretty anything bigger than a microcontroller.
On Thursday, March 10, 2022 at 4:33:39 PM UTC-5, David Brown wrote:
On 10/03/2022 13:18, John Doe wrote:
The below description is pretty good but somewhat of anMany programs run faster under Wine than natively under Windows. It
understatement.
There are LOTS of programs, very important programs, that do not
run on Linux. A few of those being able to run thru "Wine" or
whatever makes little difference, nobody wants their programs to
run slower.
all depends on what the program is doing.
Linux is a server operating system.It is that too - it covers an incredibly wide range of use-cases.
Embedded systems, laptops, desktops, servers, virtual systems,
gaming systems, routers, HPC - pretty anything bigger than a
microcontroller.
I guess another thread is lost to the great topic drift. This
started out discussing the Vortex86 devices but someone brought up
Linux and now the wars have started.
On 10/03/2022 22:52, Rick C wrote:
On Thursday, March 10, 2022 at 4:33:39 PM UTC-5, David Brown wrote:
On 10/03/2022 13:18, John Doe wrote:
The below description is pretty good but somewhat of anMany programs run faster under Wine than natively under Windows. It
understatement.
There are LOTS of programs, very important programs, that do not
run on Linux. A few of those being able to run thru "Wine" or
whatever makes little difference, nobody wants their programs to
run slower.
all depends on what the program is doing.
Linux is a server operating system.It is that too - it covers an incredibly wide range of use-cases.
Embedded systems, laptops, desktops, servers, virtual systems,
gaming systems, routers, HPC - pretty anything bigger than a
microcontroller.
I guess another thread is lost to the great topic drift. This
started out discussing the Vortex86 devices but someone brought up
Linux and now the wars have started.
Isn't topic drift what this group is all about? :-)
Anyway, the source of this drift was that someone brought up /Windows/ !
If you want to return to the Vortex86 devices - do you think they will
have any use except for newer versions of legacy embedded systems where someone a decade or two wrote the code for Windows or DOS and the manufacturer has to find new hardware for the old software ?
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run on Linux.how many people need much more than a browser and maybe an "office" suite?
A few of those being able to run thru "Wine" or whatever makes little difference, nobody wants their programs to run slower.the difference is usually minor
Linux is a server operating system.and many other things, it's greats for servers, desktops, all kind of embedded stuff
and there's about 3 billion Android devices
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:suffer.
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
Absolutely true, but they use them under Windows. Ask them to use a Linux machine and you have to start training all over again. That may not be more significant than updating to a new version of office tools, but it is an expense most companies won'tThere are LOTS of programs, very important programs, that do not run on Linux.how many people need much more than a browser and maybe an "office" suite?
A few of those being able to run thru "Wine" or whatever makes little difference, nobody wants their programs to run slower.the difference is usually minor
Beta was a better video tape format. Windows is what people use. Linux is for geeks and nerds. You know I'm right.Linux is a server operating system.and many other things, it's greats for servers, desktops, all kind of embedded stuff
and there's about 3 billion Android devices
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:t suffer.
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
Absolutely true, but they use them under Windows. Ask them to use a Linux machine and you have to start training all over again. That may not be more significant than updating to a new version of office tools, but it is an expense most companies won'There are LOTS of programs, very important programs, that do not run onhow many people need much more than a browser and maybe an "office" suite?
Linux.
A few of those being able to run thru "Wine" or whatever makes little difference, nobody wants their programs to run slower.the difference is usually minor
when was the last time you tried something like ubuntu, 15 years ago?Beta was a better video tape format. Windows is what people use. Linux is for geeks and nerds. You know I'm right.Linux is a server operating system.and many other things, it's greats for servers, desktops, all kind of embedded stuff
and there's about 3 billion Android devices
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:won't suffer.
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
Absolutely true, but they use them under Windows. Ask them to use a Linux machine and you have to start training all over again. That may not be more significant than updating to a new version of office tools, but it is an expense most companiesThere are LOTS of programs, very important programs, that do not run onhow many people need much more than a browser and maybe an "office" suite?
Linux.
know about it. Most people don't even know the name Linux, thinking you mean that character from Peanuts.A few of those being able to run thru "Wine" or whatever makes littlethe difference is usually minor
difference, nobody wants their programs to run slower.
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU, because Windows is what they know and it works very well for them.when was the last time you tried something like ubuntu, 15 years ago?Beta was a better video tape format. Windows is what people use. Linux is for geeks and nerds. You know I'm right.Linux is a server operating system.and many other things, it's greats for servers, desktops, all kind of embedded stuff
and there's about 3 billion Android devices
Here's an example. Everyone knows how to download an app from the web. Click the download link and run the file that shows up. Done.
Under Linux... well, uh, sudo apt get something? I only know that from using an rPi. Does Linux have automatic installation from a web site link? I dunno. Most other people don't either. It's not about whether it is easy or not. It's about what people
Most people who would want to have a music server or a file server know how to do things under Windows. They can find software on the web, open source or not, download and install it and get something to work. I remember using Win2K and finding areally useful web site on networking, World Of Windows Networking, WOWN. Someone bought the site and ruined it. :( But I had a home network up and running like clockwork. I struggled mightily to do the same thing with the rPi. Heck, just finding out how
I suppose I could run a remote desktop so I can operate the rPi from the laptop, maybe? Again, I don't know and it would take a bunch of research.
Is this all out of date?
fredag den 11. marts 2022 kl. 19.16.09 UTC+1 skrev gnuarm.del...@gmail.com:won't suffer.
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
Absolutely true, but they use them under Windows. Ask them to use a Linux machine and you have to start training all over again. That may not be more significant than updating to a new version of office tools, but it is an expense most companiesThere are LOTS of programs, very important programs, that do not run onhow many people need much more than a browser and maybe an "office" suite?
Linux.
people know about it. Most people don't even know the name Linux, thinking you mean that character from Peanuts.A few of those being able to run thru "Wine" or whatever makes littlethe difference is usually minor
difference, nobody wants their programs to run slower.
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU, because Windows is what they know and it works very well for them.when was the last time you tried something like ubuntu, 15 years ago?Beta was a better video tape format. Windows is what people use. Linux is for geeks and nerds. You know I'm right.Linux is a server operating system.and many other things, it's greats for servers, desktops, all kind of embedded stuff
and there's about 3 billion Android devices
Here's an example. Everyone knows how to download an app from the web. Click the download link and run the file that shows up. Done.
Under Linux... well, uh, sudo apt get something? I only know that from using an rPi. Does Linux have automatic installation from a web site link? I dunno. Most other people don't either. It's not about whether it is easy or not. It's about what
really useful web site on networking, World Of Windows Networking, WOWN. Someone bought the site and ruined it. :( But I had a home network up and running like clockwork. I struggled mightily to do the same thing with the rPi. Heck, just finding out howMost people who would want to have a music server or a file server know how to do things under Windows. They can find software on the web, open source or not, download and install it and get something to work. I remember using Win2K and finding a
I suppose I could run a remote desktop so I can operate the rPi from the laptop, maybe? Again, I don't know and it would take a bunch of research.
Is this all out of date?yes
Well, at least one part is not out of date. The fact that people know Windows and not Linux. So any product build that supports Windows has a ready base of Windows users compared to the much smaller market for
Linux.
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com: >>
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run >onhow many people need much more than a browser and maybe an "office" suite?
Linux.
Absolutely true, but they use them under Windows. Ask them to use a Linux >machine and you have to start training all over again. That may not be more >significant than updating to a new version of office tools, but it is an >expense most companies won't suffer.
when was the last time you tried something like ubuntu, 15 years ago?Beta was a better video tape format. Windows is what people use. Linux is >for geeks and nerds. You know I'm right.A few of those being able to run thru "Wine" or whatever makes little >>difference, nobody wants their programs to run slower.
the difference is usually minor
and many other things, it's greats for servers, desktops, all kind of >embedded stuff
Linux is a server operating system.
and there's about 3 billion Android devices
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU,
because Windows is what they know and it works very well for them.
Here's
an example. Everyone knows how to download an app from the web. Click
the download link and run the file that shows up. Done.
Under Linux... well, uh, sudo apt get something? I only know that from using >an rPi. Does Linux have automatic installation from a web site link? I >dunno. Most other people don't either. It's not about whether it is easy
or not. It's about what people know about it. Most people don't even know >the name Linux, thinking you mean that character from Peanuts.
Most people who would want to have a music server or a file server know how >to do things under Windows. They can find software on the web, open source >or not, download and install it and get something to work. I remember using >Win2K and finding a really useful web site on networking, World Of Windows >Networking, WOWN. Someone bought the site and ruined it. :( But I had
a home network up and running like clockwork. I struggled mightily to do
the same thing with the rPi. Heck, just finding out how to run a terminal >emulation that would support REPL with file download was no picnic. I got
it done eventually, but I would need to do the research again as I don't remember
the many complications and tricks I had to pull off to get it to work.
Or, on a Windows box, I can just use a remote desktop, done.
I suppose I could run a remote desktop so I can operate the rPi from the laptop,
maybe? Again, I don't know and it would take a bunch of research.
Is this all out of date?
You still fail to understand my point. WINDOWS USERS ARE NOT
GOING TO TRY UBUNTU, because Windows is what they know and it
works very well for them.
On a sunny day (Fri, 11 Mar 2022 10:16:00 -0800 (PST)) it happened Rick C <gnuarm.del...@gmail.com> wrote in
<84793350-1403-44bb...@googlegroups.com>:
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:on
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote: >>
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run
for geeks and nerds. You know I'm right.Linux.how many people need much more than a browser and maybe an "office" suite?
Absolutely true, but they use them under Windows. Ask them to use a Linux >machine and you have to start training all over again. That may not be more >significant than updating to a new version of office tools, but it is an >expense most companies won't suffer.
A few of those being able to run thru "Wine" or whatever makes little
difference, nobody wants their programs to run slower.Beta was a better video tape format. Windows is what people use. Linux is
the difference is usually minor
and many other things, it's greats for servers, desktops, all kind of >embedded stuff
Linux is a server operating system.
and there's about 3 billion Android devices
when was the last time you tried something like ubuntu, 15 years ago?
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU,
because Windows is what they know and it works very well for them.
Here's
an example. Everyone knows how to download an app from the web. Click
the download link and run the file that shows up. Done.
Under Linux... well, uh, sudo apt get something? I only know that from using
an rPi. Does Linux have automatic installation from a web site link? I >dunno. Most other people don't either. It's not about whether it is easy >or not. It's about what people know about it. Most people don't even know >the name Linux, thinking you mean that character from Peanuts.
Most people who would want to have a music server or a file server know how >to do things under Windows. They can find software on the web, open source >or not, download and install it and get something to work. I remember using >Win2K and finding a really useful web site on networking, World Of Windows >Networking, WOWN. Someone bought the site and ruined it. :( But I had
a home network up and running like clockwork. I struggled mightily to do >the same thing with the rPi. Heck, just finding out how to run a terminal >emulation that would support REPL with file download was no picnic. I got >it done eventually, but I would need to do the research again as I don't remember
the many complications and tricks I had to pull off to get it to work.
Or, on a Windows box, I can just use a remote desktop, done.
I suppose I could run a remote desktop so I can operate the rPi from the laptop,
maybe? Again, I don't know and it would take a bunch of research.
Is this all out of date?Well you could read - and ask in comp.sys.raspbery-pi
But google will tell you in a seoond, I use it all the time.
All these thing you just mentioned exist for Pi
That said I wrote most of my own,
from this newsreader to media player / music center to video stuff.
A LOT more - email client, irc client, navigtion program, some is on my website
In Debian (variant of that is raspi OS) apt-get install will
install things for you.
I run and program raspies all the time via SSH from my laptop as the keyboard
is faster than the other wireless ones I have here on the table connected to the raspberries.
I do have a 5 channel HDMI switch on a big monitor to select raspis or security cameras or TV...
But those raspies are so fast even via ssh I can just watch video too that way.
Home network? 3 8 port switches here, everything wired: http://panteltje.com/pub/computer_table_IMX_IMG_0679.JPG
old picture, more has been added.. more groundwarts :-)
And, if you look close you can see several RTL-SDR USB sticks and antennas. Everything talks to everything else.
And that in only downstairs in the back, upstairs is the soldering station and a big PC (seldom used these day).
The black PC is no longer used...
Its what you make of it.
This is a triple ssh example: http://panteltje.com/pub/xgpspc_mon_via_ssh.gif
navigation server with receiver rt-sdr runs on PI address ..73
laptop is on ...20
I connect via ssh with ...96 (is also 95) from ....20
and start cient program xgpspc_mon (you could use web browser too, but this is faster smaller better)
and now have the display on the laptop I use to type this with my own editor in an other full screen xterm in my NewsFleX Usenet newsreader
and take a screenshot with
import -screen xgpspc_mon_via_ssh.gif
from that terminal (I have 9 virtual screens with 8 rxvt terminals open on the fvwm filemanager on the laptop)
and then send it to my webserver's 'pub' directory in 'merrica via ssh like this:
#to_website2 xgpspc_mon_via_ssh.gif
so the world can see it.
You can just see an airplane coming in belonging to United Arab Emirates I think (UAE) likely heading for Germany.
Scripts is the solution to everything so you do not have to remember every detail of all the thousands of commands
zsh is a much more pleasant shell to use than bash at least for sysadmins.
On Friday, March 11, 2022 at 3:04:25 PM UTC-5, Jan Panteltje wrote:brought up many pages telling me how great lithium batteries are or what's going on with the latest lithium powered gadget, etc. God forbid you use a search term that is in the title of a song or movie, you'll never get past that.
On a sunny day (Fri, 11 Mar 2022 10:16:00 -0800 (PST)) it happened Rick C <gnuarm.del...@gmail.com> wrote in <84793350-1403-44bb...@googlegroups.com>:
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:on
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run
machine and you have to start training all over again. That may not be moreLinux.how many people need much more than a browser and maybe an "office" suite?
Absolutely true, but they use them under Windows. Ask them to use a Linux
significant than updating to a new version of office tools, but it is an >expense most companies won't suffer.
embedded stuffA few of those being able to run thru "Wine" or whatever makes little
difference, nobody wants their programs to run slower.
the difference is usually minor
and many other things, it's greats for servers, desktops, all kind of
Linux is a server operating system.
for geeks and nerds. You know I'm right.and there's about 3 billion Android devicesBeta was a better video tape format. Windows is what people use. Linux is
when was the last time you tried something like ubuntu, 15 years ago?
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU,
because Windows is what they know and it works very well for them.
Here's
an example. Everyone knows how to download an app from the web. Click >the download link and run the file that shows up. Done.
Under Linux... well, uh, sudo apt get something? I only know that from using
an rPi. Does Linux have automatic installation from a web site link? I >dunno. Most other people don't either. It's not about whether it is easy >or not. It's about what people know about it. Most people don't even know >the name Linux, thinking you mean that character from Peanuts.
Most people who would want to have a music server or a file server know how
to do things under Windows. They can find software on the web, open source
or not, download and install it and get something to work. I remember using
Win2K and finding a really useful web site on networking, World Of Windows
Networking, WOWN. Someone bought the site and ruined it. :( But I had
a home network up and running like clockwork. I struggled mightily to do >the same thing with the rPi. Heck, just finding out how to run a terminal >emulation that would support REPL with file download was no picnic. I got >it done eventually, but I would need to do the research again as I don't remember
the many complications and tricks I had to pull off to get it to work.
Or, on a Windows box, I can just use a remote desktop, done.
I suppose I could run a remote desktop so I can operate the rPi from the laptop,
maybe? Again, I don't know and it would take a bunch of research.
The conversation is here. I suppose you can call this a conversation.Is this all out of date?Well you could read - and ask in comp.sys.raspbery-pi
But google will tell you in a seoond, I use it all the time.No, little is found through a web search in a "second". It often take many minutes or even hours to wade through the ever increasing dross to find a topic you are looking for. I was just trying to find the market cost of lithium carbonate and it
the things you can do. I do a print screen by pressing a button on the keyboard, with the ALT key if I only want the window in focus rather than the whole screen. Why would I want to bother to learn "import -screen xgpspc_mon_via_ssh.gif"??? Learn it? IAll these thing you just mentioned exist for Pi
That said I wrote most of my own,
from this newsreader to media player / music center to video stuff.
A LOT more - email client, irc client, navigtion program, some is on my website
In Debian (variant of that is raspi OS) apt-get install will
install things for you.
I run and program raspies all the time via SSH from my laptop as the keyboard
is faster than the other wireless ones I have here on the table connected to the raspberries.
I do have a 5 channel HDMI switch on a big monitor to select raspis or security cameras or TV...
But those raspies are so fast even via ssh I can just watch video too that way.
Home network? 3 8 port switches here, everything wired: http://panteltje.com/pub/computer_table_IMX_IMG_0679.JPG
old picture, more has been added.. more groundwarts :-)
And, if you look close you can see several RTL-SDR USB sticks and antennas.
Everything talks to everything else.
And that in only downstairs in the back, upstairs is the soldering station and a big PC (seldom used these day).
The black PC is no longer used...
Its what you make of it.
This is a triple ssh example: http://panteltje.com/pub/xgpspc_mon_via_ssh.gif
navigation server with receiver rt-sdr runs on PI address ..73
laptop is on ...20
I connect via ssh with ...96 (is also 95) from ....20
and start cient program xgpspc_mon (you could use web browser too, but this is faster smaller better)
and now have the display on the laptop I use to type this with my own editor in an other full screen xterm in my NewsFleX Usenet newsreader
and take a screenshot with
import -screen xgpspc_mon_via_ssh.gif
from that terminal (I have 9 virtual screens with 8 rxvt terminals open on the fvwm filemanager on the laptop)
and then send it to my webserver's 'pub' directory in 'merrica via ssh like this:
#to_website2 xgpspc_mon_via_ssh.gif
so the world can see it.
You can just see an airplane coming in belonging to United Arab Emirates I think (UAE) likely heading for Germany.
Scripts is the solution to everything so you do not have to remember every detail of all the thousands of commandsI don't really care what is available for Linux... well, not at the moment, although this conversation is making me want to fire up the rPi and pickup where I left off a few years ago.
zsh is a much more pleasant shell to use than bash at least for sysadmins.
My point is there is a market for people who would like to do some of the things you did, but using Windows because that's what they know. Why swim upstream and learn a new OS? Not everyone is a geek or wants to learn all the gory details of how to do
fredag den 11. marts 2022 kl. 22.11.02 UTC+1 skrev gnuarm.del...@gmail.com:brought up many pages telling me how great lithium batteries are or what's going on with the latest lithium powered gadget, etc. God forbid you use a search term that is in the title of a song or movie, you'll never get past that.
On Friday, March 11, 2022 at 3:04:25 PM UTC-5, Jan Panteltje wrote:
On a sunny day (Fri, 11 Mar 2022 10:16:00 -0800 (PST)) it happened Rick C
<gnuarm.del...@gmail.com> wrote in <84793350-1403-44bb...@googlegroups.com>:
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote: >> fredag den 11. marts 2022 kl. 13.48.20 UTC+1 skrev gnuarm.del...@gmail.com:
on
On Thursday, March 10, 2022 at 11:45:42 AM UTC-5, lang...@fonz.dk wrote:
torsdag den 10. marts 2022 kl. 13.18.55 UTC+1 skrev John Doe:
The below description is pretty good but somewhat of an understatement.
There are LOTS of programs, very important programs, that do not run
machine and you have to start training all over again. That may not be moreLinux.how many people need much more than a browser and maybe an "office" suite?
Absolutely true, but they use them under Windows. Ask them to use a Linux
significant than updating to a new version of office tools, but it is an
expense most companies won't suffer.
embedded stuffA few of those being able to run thru "Wine" or whatever makes little
difference, nobody wants their programs to run slower.
the difference is usually minor
and many other things, it's greats for servers, desktops, all kind of
Linux is a server operating system.
for geeks and nerds. You know I'm right.and there's about 3 billion Android devicesBeta was a better video tape format. Windows is what people use. Linux is
when was the last time you tried something like ubuntu, 15 years ago?
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO TRY UBUNTU,
because Windows is what they know and it works very well for them.
Here's
an example. Everyone knows how to download an app from the web. Click >the download link and run the file that shows up. Done.
Under Linux... well, uh, sudo apt get something? I only know that from using
an rPi. Does Linux have automatic installation from a web site link? I >dunno. Most other people don't either. It's not about whether it is easy
or not. It's about what people know about it. Most people don't even know
the name Linux, thinking you mean that character from Peanuts.
Most people who would want to have a music server or a file server know how
to do things under Windows. They can find software on the web, open source
or not, download and install it and get something to work. I remember using
Win2K and finding a really useful web site on networking, World Of Windows
Networking, WOWN. Someone bought the site and ruined it. :( But I had >a home network up and running like clockwork. I struggled mightily to do
the same thing with the rPi. Heck, just finding out how to run a terminal
emulation that would support REPL with file download was no picnic. I got
it done eventually, but I would need to do the research again as I don't remember
the many complications and tricks I had to pull off to get it to work.
Or, on a Windows box, I can just use a remote desktop, done.
I suppose I could run a remote desktop so I can operate the rPi from the laptop,
maybe? Again, I don't know and it would take a bunch of research.
The conversation is here. I suppose you can call this a conversation.Is this all out of date?Well you could read - and ask in comp.sys.raspbery-pi
But google will tell you in a seoond, I use it all the time.No, little is found through a web search in a "second". It often take many minutes or even hours to wade through the ever increasing dross to find a topic you are looking for. I was just trying to find the market cost of lithium carbonate and it
do the things you can do. I do a print screen by pressing a button on the keyboard, with the ALT key if I only want the window in focus rather than the whole screen. Why would I want to bother to learn "import -screen xgpspc_mon_via_ssh.gif"??? Learn it?All these thing you just mentioned exist for Pi
That said I wrote most of my own,
from this newsreader to media player / music center to video stuff.
A LOT more - email client, irc client, navigtion program, some is on my website
In Debian (variant of that is raspi OS) apt-get install will
install things for you.
I run and program raspies all the time via SSH from my laptop as the keyboard
is faster than the other wireless ones I have here on the table connected to the raspberries.
I do have a 5 channel HDMI switch on a big monitor to select raspis or security cameras or TV...
But those raspies are so fast even via ssh I can just watch video too that way.
Home network? 3 8 port switches here, everything wired: http://panteltje.com/pub/computer_table_IMX_IMG_0679.JPG
old picture, more has been added.. more groundwarts :-)
And, if you look close you can see several RTL-SDR USB sticks and antennas.
Everything talks to everything else.
And that in only downstairs in the back, upstairs is the soldering station and a big PC (seldom used these day).
The black PC is no longer used...
Its what you make of it.
This is a triple ssh example: http://panteltje.com/pub/xgpspc_mon_via_ssh.gif
navigation server with receiver rt-sdr runs on PI address ..73
laptop is on ...20
I connect via ssh with ...96 (is also 95) from ....20
and start cient program xgpspc_mon (you could use web browser too, but this is faster smaller better)
and now have the display on the laptop I use to type this with my own editor in an other full screen xterm in my NewsFleX Usenet newsreader
and take a screenshot with
import -screen xgpspc_mon_via_ssh.gif
from that terminal (I have 9 virtual screens with 8 rxvt terminals open on the fvwm filemanager on the laptop)
and then send it to my webserver's 'pub' directory in 'merrica via ssh like this:
#to_website2 xgpspc_mon_via_ssh.gif
so the world can see it.
You can just see an airplane coming in belonging to United Arab Emirates I think (UAE) likely heading for Germany.
Scripts is the solution to everything so you do not have to remember every detail of all the thousands of commandsI don't really care what is available for Linux... well, not at the moment, although this conversation is making me want to fire up the rPi and pickup where I left off a few years ago.
zsh is a much more pleasant shell to use than bash at least for sysadmins.
My point is there is a market for people who would like to do some of the things you did, but using Windows because that's what they know. Why swim upstream and learn a new OS? Not everyone is a geek or wants to learn all the gory details of how to
and you can do exactly the same in Ubuntu et. al.
printscreen for the whole desktop, alt-printscreen for a window, shift-printscreen for a selectable area
or, just like on windows, you can hit the start/windows key and start typing screenshoot and you get a window
with all the settings, what you want to copy, where you want to save it, if you want the pointer hidden etc.
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
when was the last time you tried something like ubuntu, 15 years ago?
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TO
TRY UBUNTU, because Windows is what they know and it works very well
for them.
[...]
Under Linux... well, uh, sudo apt get something? I only know that
from using an rPi. Does Linux have automatic installation from a web
site link? I dunno. Most other people don't either. It's not about
whether it is easy or not. It's about what people know about it.
Most people don't even know the name Linux, thinking you mean that
character from Peanuts.
Most people who would want to have a music server or a file server
know how to do things under Windows. They can find software on the
web, open source or not, download and install it and get something to
work. I remember using Win2K and finding a really useful web site on networking, World Of Windows Networking, WOWN. Someone bought the
site and ruined it. :( But I had a home network up and running like clockwork. I struggled mightily to do the same thing with the rPi.
Heck, just finding out how to run a terminal emulation that would
support REPL with file download was no picnic. I got it done
eventually, but I would need to do the research again as I don't
remember the many complications and tricks I had to pull off to get it
to work. Or, on a Windows box, I can just use a remote desktop, done.
I suppose I could run a remote desktop so I can operate the rPi from
the laptop, maybe? Again, I don't know and it would take a bunch of research.
Is this all out of date?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Friday, March 11, 2022 at 12:01:09 PM UTC-5, lang...@fonz.dk wrote:
when was the last time you tried something like ubuntu, 15 years ago?
You still fail to understand my point. WINDOWS USERS ARE NOT GOING TOI see "hey I'm a new Linux user" almost daily on the linux IRC channels
TRY UBUNTU, because Windows is what they know and it works very well
for them.
I frequent, so at least some Windows users are trying it out.
[...]You use the package manager ("app store"); same as your trusty iOS /
Under Linux... well, uh, sudo apt get something? I only know that
from using an rPi. Does Linux have automatic installation from a web
site link? I dunno. Most other people don't either. It's not about
whether it is easy or not. It's about what people know about it.
Most people don't even know the name Linux, thinking you mean that character from Peanuts.
Android device. I hear Windows / Microsoft also has a builtin "store"
now too. No hunting all over the internet or downloading random "trust
me" software from some guy's blog.
Most people who would want to have a music server or a file serverQuick read on google makes REPL look like a python-based ... IDE maybe?
know how to do things under Windows. They can find software on the
web, open source or not, download and install it and get something to work. I remember using Win2K and finding a really useful web site on networking, World Of Windows Networking, WOWN. Someone bought the
site and ruined it. :( But I had a home network up and running like clockwork. I struggled mightily to do the same thing with the rPi.
Heck, just finding out how to run a terminal emulation that would
support REPL with file download was no picnic. I got it done
eventually, but I would need to do the research again as I don't
remember the many complications and tricks I had to pull off to get it
to work. Or, on a Windows box, I can just use a remote desktop, done.
I dunno, the site really isn't that descriptive beyond "this is a crutch
for beginners". Not going to make any judgement of it one way or the
other.
If it IS just a python-based program, I'd wager that the difficulty came from "which version of Python is installed" -- that's always a stumbling block (especially with Python 2 -> 3 conversions).
I suppose I could run a remote desktop so I can operate the rPi fromDepends "why" you're accessing the rPi remotely -- a graphical interface isn't necessarily always the best answer (then again, it might be for
the laptop, maybe? Again, I don't know and it would take a bunch of research.
you, I dunno).
Is this all out of date?Partially.
I
don't really care what is available for Linux... well, not at the moment, >although this conversation is making me want to fire up the rPi and pickup >where I left off a few years ago.
My point is there is a market for people who would like to do some of the things
you did, but using Windows because that's what they know. Why swim upstream >and learn a new OS? Not everyone is a geek or wants to learn all the
gory details of how to do the things you can do. I do a print screen by >pressing a button on the keyboard, with the ALT key if I only want the window >in focus rather than the whole screen. Why would I want to bother to learn >"import -screen xgpspc_mon_via_ssh.gif"??? Learn it? I don't even want
to type it! Click, click.
This is why people don't use DOS.
On a sunny day (Fri, 11 Mar 2022 13:10:53 -0800 (PST)) it happened Rick C <gnuarm.del...@gmail.com> wrote in
<79268cfe-04a0-4e40...@googlegroups.com>:
I
don't really care what is available for Linux... well, not at the moment, >although this conversation is making me want to fire up the rPi and pickup >where I left off a few years ago.
My point is there is a market for people who would like to do some of the things
you did, but using Windows because that's what they know. Why swim upstream >and learn a new OS? Not everyone is a geek or wants to learn all the
gory details of how to do the things you can do. I do a print screen by >pressing a button on the keyboard, with the ALT key if I only want the window
in focus rather than the whole screen. Why would I want to bother to learn >"import -screen xgpspc_mon_via_ssh.gif"??? Learn it? I don't even want
to type it! Click, click.
This is why people don't use DOS.When [if] you install a standard Rasoi OS you can do the click thing for almost anything.
Not much new to learn, just like going to a new supermarket
and the first time you find things are in a different place,
get used to it fast...
I have the GUI too in one of the 9 virtual screens on any system I run.
The advantage of a 'command line' is like going to hardware shop and saying "I need whatever" and the guy will put it in front of you in a second.
When you have a million things to chose from a click menu is so silly and slow.
And not to mention voice input for the visual disabled,
What is it these days? "Siri where .." sort of things.
I have voice input on my old PC for teefee
Show BBC1
works.
I never use it, remote on my cheap HD Chinese sat box is faster and more quiet.
In this world everything has a learning curve,
I have been in foreign countries and trying to convey something
by pointing or drawing is possible but a difficult way to communicate
Learn the language, something US folks seem not to be busy with.
Here at high school 4 languages are already required
Dutch, French, German, English, and some also have Latin.
So I always say: 'My computer speaks English' typing is faster than working through silly menus
You can make your own language; by naming the command scripts you write.
Now you could argue that learning is so hard, well then you are dead
Life is learning
"He who is nit busy being born is busy dying" https://www.bobdylan.com/songs/its-alright-ma-im-only-bleeding/
On Friday, March 11, 2022 at 7:47:38 PM UTC-5, Dan Purgert wrote:
Quick read on google makes REPL look like a python-based ... IDE maybe?
I dunno, the site really isn't that descriptive beyond "this is a crutch
for beginners". Not going to make any judgement of it one way or the
other.
If it IS just a python-based program, I'd wager that the difficulty came
from "which version of Python is installed" -- that's always a stumbling
block (especially with Python 2 -> 3 conversions).
I think you have the wrong REPL. It's really just a way to say an interpretive interface.
I work with Forth which has a command line. Code can be executed from
the bottom up as it is written. Typically word definitions (Forth's
idea of subroutines) are small, often only one or two lines and can be
tested interactively. So you write the word defintion, execute it and
print out the stack to see if it did what you expected. This would
seem to be simple debugging, but when you construct your code in small definitions, it works very effectively.
It often is done via a serial port interface, often emulated through
USB, but can be done with network protocols. It does require a
terminal emulator to be running somewhere to provide the user
interface to the user.
Is this all out of date?Partially.
Yes, as others have told me. I think the scheme I used before was to
run a terminal emulator on the laptop using sockets perhaps? But I
don't recall how that connection to the rPi was connected to the USB
serial cable on the rPi. Somewhere in the process I was trying to use
a terminal emulator on the rPi, but that is an alien concept under
Linux because a command line is a terminal interface (or so I was
repeatedly told)... just not what I needed. I don't remember the
details. I just recall it was a huge PITA to get running because of
Linux. If I had plugged the serial port into the laptop, it would
have been a slam dunk. But I wanted the unit under test to be in
another room. Maybe I should have bought a 50 foot serial cable and
run the interface at 9600 bps rather than 200,000, or was it 2 Mbps?
The speed was fast enough that the screen would blink and was
completely rewritten.
In the Forth group some guy is talking about trying to make hardware
as easy to interface at a modular level as software. I'd like to make software as easy to interface as hardware.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Friday, March 11, 2022 at 7:47:38 PM UTC-5, Dan Purgert wrote:
Quick read on google makes REPL look like a python-based ... IDE maybe? >> I dunno, the site really isn't that descriptive beyond "this is a crutch >> for beginners". Not going to make any judgement of it one way or the
other.
If it IS just a python-based program, I'd wager that the difficulty came >> from "which version of Python is installed" -- that's always a stumbling >> block (especially with Python 2 -> 3 conversions).
I think you have the wrong REPL. It's really just a way to say an interpretive interface.Ah, yeah, I skipped over those initial hits, as I thought you were
talking about an actual piece of software; instead of a "concept" (which isn't really that good of a word, but I can't really think of anything better).
I work with Forth which has a command line. Code can be executed fromI've not done Forth, but it sounds a lot like connecting to an
the bottom up as it is written. Typically word definitions (Forth's
idea of subroutines) are small, often only one or two lines and can be tested interactively. So you write the word defintion, execute it and print out the stack to see if it did what you expected. This would
seem to be simple debugging, but when you construct your code in small definitions, it works very effectively.
interactive shell, such as bash or python (others exist).
It often is done via a serial port interface, often emulated throughQuite similar to the aforementioned shells (although more likely these
USB, but can be done with network protocols. It does require a
terminal emulator to be running somewhere to provide the user
interface to the user.
days to be ssh than serial/usb when it comes to interacting with a Linux shell).
Is this all out of date?Partially.
Yes, as others have told me. I think the scheme I used before was toIt's messy, mostly because of how things have changed since the 60s/70s.
run a terminal emulator on the laptop using sockets perhaps? But I
don't recall how that connection to the rPi was connected to the USB serial cable on the rPi. Somewhere in the process I was trying to use
a terminal emulator on the rPi, but that is an alien concept under
Linux because a command line is a terminal interface (or so I was repeatedly told)... just not what I needed. I don't remember the
Assuming you're running something graphical (e.g. xfce); then your
*terminal emulator* (commandline) will be xterm or xfce4-terminal or gnome-terminal (or a few other options). This application will connect
to a pseudo-teletype (pty) instance that the kernel is running. When it
is spun up, you get an instance of your interactive shell (e.g. bash) spawned, so you can give the computer commands.
While it is possible to read from / write to a serial interface directly from your shell (e.g. 'cat /dev/ttyS0' to read whatever it's printing
back or 'echo C > /dev/ttyS0' to write the character 'C' to it),
normally you'd want to use something like _minicom_ or _screen_ (they're analogous to the windows tools HyperTerm or PuTTY).
details. I just recall it was a huge PITA to get running because ofI don't think I saw that specific question. For the sake of discussion
Linux. If I had plugged the serial port into the laptop, it would
have been a slam dunk. But I wanted the unit under test to be in
another room. Maybe I should have bought a 50 foot serial cable and
run the interface at 9600 bps rather than 200,000, or was it 2 Mbps?
The speed was fast enough that the screen would blink and was
completely rewritten.
and assuming a generally hypothetical scenario ... for this scenario,
you have three devices in play:
1. a PC in some room
2. a DUT in another room
3. a rPi in the same room as DUT, which you're connecting to via ssh.
So in that case, I'd ssh into the rPi; then fire up whatever application
I was using to perform the test (Forth, python, whatever) with
appropriate parameters to connect to /dev/ttyS0 (assuming that's the
correct serial port on the rPi, of course).
Again -- I'm considering this a hypothetical, as I don't know all the specifics you ran into / what you've already done / tried / etc, and
don't want to waste your time telling you to do things that you've
already tried.
In the Forth group some guy is talking about trying to make hardwareThey're both easy, in their own ways. Each has its caveats though
as easy to interface at a modular level as software. I'd like to make software as easy to interface as hardware.
software is getting _harder_ nowadays, when we're talking "old comms"
such as serial or parallel ... I mean it's been a good 20-25 years since serial was truly "required" in the general case.
On Saturday, March 12, 2022 at 3:21:33 PM UTC-5, Dan Purgert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Friday, March 11, 2022 at 7:47:38 PM UTC-5, Dan Purgert wrote:Ah, yeah, I skipped over those initial hits, as I thought you were
Quick read on google makes REPL look like a python-based ... IDE maybe? >> >> I dunno, the site really isn't that descriptive beyond "this is a crutch >> >> for beginners". Not going to make any judgement of it one way or the
other.
If it IS just a python-based program, I'd wager that the difficulty came >> >> from "which version of Python is installed" -- that's always a stumbling >> >> block (especially with Python 2 -> 3 conversions).
I think you have the wrong REPL. It's really just a way to say an
interpretive interface.
talking about an actual piece of software; instead of a "concept" (which
isn't really that good of a word, but I can't really think of anything
better).
I've not done Forth, but it sounds a lot like connecting to an
I work with Forth which has a command line. Code can be executed from
the bottom up as it is written. Typically word definitions (Forth's
idea of subroutines) are small, often only one or two lines and can be
tested interactively. So you write the word defintion, execute it and
print out the stack to see if it did what you expected. This would
seem to be simple debugging, but when you construct your code in small
definitions, it works very effectively.
interactive shell, such as bash or python (others exist).
Not really a shell. It's a programming language based on a virtual
stack machine. I'm sure you seen those before. The difference this
one uses the virtual stack machine as the programming language. No
parameter lists, data is pushed onto the stack (or left from previous
words) and each word gets its inputs from the stack, leaves outputs on
the stack. The fact that it is interpretive is just icing on the
cake. It is also compiled, so the best of both worlds.
It often is done via a serial port interface, often emulated throughQuite similar to the aforementioned shells (although more likely these
USB, but can be done with network protocols. It does require a
terminal emulator to be running somewhere to provide the user
interface to the user.
days to be ssh than serial/usb when it comes to interacting with a Linux
shell).
Yeah, SSH rings a bell. Like I said, it's been years since I ran this
from other parts of the house. In my case the rPi was not the client,
but an intermediary to provide the serial port to the small MCU
target.
It's messy, mostly because of how things have changed since the 60s/70s.Is this all out of date?Partially.
Yes, as others have told me. I think the scheme I used before was to
run a terminal emulator on the laptop using sockets perhaps? But I
don't recall how that connection to the rPi was connected to the USB
serial cable on the rPi. Somewhere in the process I was trying to use
a terminal emulator on the rPi, but that is an alien concept under
Linux because a command line is a terminal interface (or so I was
repeatedly told)... just not what I needed. I don't remember the
Assuming you're running something graphical (e.g. xfce); then your
*terminal emulator* (commandline) will be xterm or xfce4-terminal or
gnome-terminal (or a few other options). This application will connect
to a pseudo-teletype (pty) instance that the kernel is running. When it
is spun up, you get an instance of your interactive shell (e.g. bash)
spawned, so you can give the computer commands.
Most of that means little to me. Under Windows you just run a terminal emulator program and done.
While it is possible to read from / write to a serial interface directly
from your shell (e.g. 'cat /dev/ttyS0' to read whatever it's printing
back or 'echo C > /dev/ttyS0' to write the character 'C' to it),
normally you'd want to use something like _minicom_ or _screen_ (they're
analogous to the windows tools HyperTerm or PuTTY).
Minicom rings a bell too. Whatever I used on the rPi was not very
full featured. It needs to be able to link the keyboard and screen to
the serial port, but also send files to the target for compilation.
Forth runs on the target and you send source code over the serial port
or other comms channel. Sometimes if the target is more capable, the
target has a file system, so can act as the entire development system
running an editor. This case was a little TI MCU with maybe 4kB of
RAM and some 32 or 64kB of Flash. So the files were edited on the PC
or rPi and downloaded for each compile.
details. I just recall it was a huge PITA to get running because ofI don't think I saw that specific question. For the sake of discussion
Linux. If I had plugged the serial port into the laptop, it would
have been a slam dunk. But I wanted the unit under test to be in
another room. Maybe I should have bought a 50 foot serial cable and
run the interface at 9600 bps rather than 200,000, or was it 2 Mbps?
The speed was fast enough that the screen would blink and was
completely rewritten.
and assuming a generally hypothetical scenario ... for this scenario,
you have three devices in play:
1. a PC in some room
2. a DUT in another room
3. a rPi in the same room as DUT, which you're connecting to via ssh.
Yeah, that's right.
So in that case, I'd ssh into the rPi; then fire up whatever application
I was using to perform the test (Forth, python, whatever) with
appropriate parameters to connect to /dev/ttyS0 (assuming that's the
correct serial port on the rPi, of course).
That sounds like what I did, except there's nothing to run on the rPi
other than connecting the link from the PC to the serial port to the
target. Forth runs on the target. I like Codewright for an editor,
so I would have been editing the files on the PC and shooting them
down to the target. I seem to recall that was the part I had the most trouble with. Trying to make all this work like it was one pipe
between the PC and the target.
They're both easy, in their own ways. Each has its caveats though
software is getting _harder_ nowadays, when we're talking "old comms"
such as serial or parallel ... I mean it's been a good 20-25 years since
serial was truly "required" in the general case.
Hardware has gotten mostly to the point of interconnecting large
blocks called ASICs, much as software has done the same. Both require
some amount of glue to make everything play nicely together. When you
really need to design digital hardware, that's mostly done in FPGAs,
so we are back to software, kinda, sorta.
Rick C wrote:
On Saturday, March 12, 2022 at 3:21:33 PM UTC-5, Dan Purgert wrote:
Assuming you're running something graphical (e.g. xfce); then your
*terminal emulator* (commandline) will be xterm or xfce4-terminal or
gnome-terminal (or a few other options). This application will connect
to a pseudo-teletype (pty) instance that the kernel is running. When it >> is spun up, you get an instance of your interactive shell (e.g. bash)
spawned, so you can give the computer commands.
Most of that means little to me. Under Windows you just run a terminal emulator program and done.Ugh, editing error on my part. The programs mentioned are the GUI
equivalent of running the Windows command interpreter (it's still "cmd", right?)
While it is possible to read from / write to a serial interface directly >> from your shell (e.g. 'cat /dev/ttyS0' to read whatever it's printing
back or 'echo C > /dev/ttyS0' to write the character 'C' to it),
normally you'd want to use something like _minicom_ or _screen_ (they're >> analogous to the windows tools HyperTerm or PuTTY).
Minicom rings a bell too. Whatever I used on the rPi was not veryGiven the description here, definitely sounds like minicom with
full featured. It needs to be able to link the keyboard and screen to
the serial port, but also send files to the target for compilation.
Forth runs on the target and you send source code over the serial port
or other comms channel. Sometimes if the target is more capable, the
probably a zmodem helper for sending files.
target has a file system, so can act as the entire development system running an editor. This case was a little TI MCU with maybe 4kB ofOoh, which one? I haven't played with any TI MCUs yet ... mostly play
RAM and some 32 or 64kB of Flash. So the files were edited on the PC
or rPi and downloaded for each compile.
around with AVR parts.
I don't think I saw that specific question. For the sake of discussion
and assuming a generally hypothetical scenario ... for this scenario,
you have three devices in play:
1. a PC in some room
2. a DUT in another room
3. a rPi in the same room as DUT, which you're connecting to via ssh.
Yeah, that's right.
So in that case, I'd ssh into the rPi; then fire up whatever application >> I was using to perform the test (Forth, python, whatever) with
appropriate parameters to connect to /dev/ttyS0 (assuming that's the
correct serial port on the rPi, of course).
That sounds like what I did, except there's nothing to run on the rPi other than connecting the link from the PC to the serial port to the target. Forth runs on the target. I like Codewright for an editor,OH -- okay so then the corrected approach would be to ssh to the pi,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .
NOTE -- I keep writing /dev/ttyS0 since that's the first serial port
("COM0" in windows, if I'm remembering correctly). Big difference with
Linux and Windows in this regard is that if you have USB serial devices, they'll probably enumerate as "/dev/ttyUSBn" or "/dev/ttyACMn"; whereas windows would (IIRC) just keep calling them "COMn"
so I would have been editing the files on the PC and shooting themYes, sticking the intermediary would be a source of "fun(tm)",
down to the target. I seem to recall that was the part I had the most trouble with. Trying to make all this work like it was one pipe
between the PC and the target.
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
They're both easy, in their own ways. Each has its caveats though
software is getting _harder_ nowadays, when we're talking "old comms"
such as serial or parallel ... I mean it's been a good 20-25 years since >> serial was truly "required" in the general case.
Hardware has gotten mostly to the point of interconnecting largeFPGAs (and [C]PLDs) are still new territory for me. Have a something or other devboard that plays nice on Linux and has an open devchain ... but
blocks called ASICs, much as software has done the same. Both require
some amount of glue to make everything play nicely together. When you really need to design digital hardware, that's mostly done in FPGAs,
so we are back to software, kinda, sorta.
I haven't gotten much farther than "here's a blinkenLED".
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
You are describing quite a common way to arrange things.
I assume your "terminal emulator" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.
It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I personally have never liked either, but they are immensely powerful for those that have invested the time and effort into learning them.)
And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than "real" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.
That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.
On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:You are describing quite a common way to arrange things.
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
I assume your "terminal emulator" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.
It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for
those that have invested the time and effort into learning them.)
And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over
ssh. (This is less efficient than "real" network file systems, but very
easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client.
That way you have the same view of the files on your development PC and
the Pi, and you can skip the file transfer step.
There's nothing on the rPi to edit. No files live on the rPi. The
work is done on the PC talking to the compiler on the target.
The
rPi is there to connect the target serial port to the network. It's
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don't
need to run a browser on it. I think the mail limitation is the
limited memory actually.
The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn't matter.
I'm pretty sure I ran something on the rPi that was like a terminal
emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I'm trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn't work out ok. I don't think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don't recall.
On 13/03/2022 22:03, Rick C wrote:
On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:You are describing quite a common way to arrange things.
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
I assume your "terminal emulator" on the PC is something like Putty or
Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.
It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for >> those that have invested the time and effort into learning them.)
And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With
a *nix host system you can also use NFS or even sshfs - file share over >> ssh. (This is less efficient than "real" network file systems, but very >> easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either
way - it works fine to use the Pi as the server and the PC as the client. >>
That way you have the same view of the files on your development PC and >> the Pi, and you can skip the file transfer step.
There's nothing on the rPi to edit. No files live on the rPi. TheOK. You didn't include any compilation stage in your description - a
work is done on the PC talking to the compiler on the target.
lot of people use Python on the Pi.
The
rPi is there to connect the target serial port to the network. It's
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don't
need to run a browser on it. I think the mail limitation is the
limited memory actually.
The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn't matter.
My standard source of laptops is left-overs from the sales folk or other administration people.
When they get too slow running Windows, I wipe
the disks and install Linux - the machines are faster than they were
when new. (If only Linux could make them as thin and light as modern machines, and reverse the battery wear!)
I'm pretty sure I ran something on the rPi that was like a terminal emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I'm trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn't work out ok. I don't think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don't recall.
I'm not quite sure what you are trying to do, but these links might have some ideas:
<https://unix.stackexchange.com/questions/96718/how-do-i-use-a-serial-port-on-linux-like-a-pipe-or-netcat>
<https://www.brainboxes.com/faq/how-to-use-netcat-to-pipe-serial-data-over-tcp>
<https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp>
<https://serverfault.com/questions/384741/forwarding-serial-port-over-network-and-back-to-serial-char-device-on-remote-hos>
If you want to run programs on the Pi and let them keep running after
you disconnect, an extremely useful program is "screen" (especially with
the "byobu" program that makes it a little nicer).
<https://en.wikipedia.org/wiki/GNU_Screen>
On Sunday, March 13, 2022 at 7:17:16 PM UTC-4, David Brown wrote:that size.
On 13/03/2022 22:03, Rick C wrote:
On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:OK. You didn't include any compilation stage in your description - a
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:You are describing quite a common way to arrange things.
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
This is starting to come back to me now. The comms program on the PC >>>>> gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
I assume your "terminal emulator" on the PC is something like Putty or >>>> Tera Term Pro. Both are fine for the purpose. In each case, you will
be using the terminal as an ssh client to log into the device.
It is possible to edit things directly on the Pi, using a text-based
editor such as nano. That works fine for small changes, but is less
than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for >>>> those that have invested the time and effort into learning them.)
And there are many other ways to transfer files to the Pi. The best
ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and
mount the share on the Pi, or have both use a common file server. With >>>> a *nix host system you can also use NFS or even sshfs - file share over >>>> ssh. (This is less efficient than "real" network file systems, but very >>>> easy to set up ad-hoc.) With a Windows development system, standard
Windows CIFS sharing is probably the easiest. And you can do it either >>>> way - it works fine to use the Pi as the server and the PC as the client. >>>>
That way you have the same view of the files on your development PC and >>>> the Pi, and you can skip the file transfer step.
There's nothing on the rPi to edit. No files live on the rPi. The
work is done on the PC talking to the compiler on the target.
lot of people use Python on the Pi.
Yes, I did. I said to send it to the target. The target compiles it. I'm sure I mentioned that the compiler is in the flash of the target. That's why I think it has 16kB of flash. 8kB is a bit cramped for a Forth compiler although many exist in
TheMy standard source of laptops is left-overs from the sales folk or other
rPi is there to connect the target serial port to the network. It's
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don't
need to run a browser on it. I think the mail limitation is the
limited memory actually.
The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn't matter.
administration people.
I am the admin and sales force. I am done with a laptop when it no longer works.
When they get too slow running Windows, I wipe
the disks and install Linux - the machines are faster than they were
when new. (If only Linux could make them as thin and light as modern
machines, and reverse the battery wear!)
I'm pretty sure I ran something on the rPi that was like a terminalI'm not quite sure what you are trying to do, but these links might have
emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I'm trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn't work out ok. I don't think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don't recall.
some ideas:
<https://unix.stackexchange.com/questions/96718/how-do-i-use-a-serial-port-on-linux-like-a-pipe-or-netcat>
<https://www.brainboxes.com/faq/how-to-use-netcat-to-pipe-serial-data-over-tcp>
<https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp>
<https://serverfault.com/questions/384741/forwarding-serial-port-over-network-and-back-to-serial-char-device-on-remote-hos>
If you want to run programs on the Pi and let them keep running after
you disconnect, an extremely useful program is "screen" (especially with
the "byobu" program that makes it a little nicer).
<https://en.wikipedia.org/wiki/GNU_Screen>
What part of what I'm doing is not clear? I wish to establish the
equivalent of a serial port connection from my PC to the target that
is physically connected to an rPi. That's it.
The terminal emulator
on the PC does everything I need, typing to the command line on the
target, sending a file through the pipe as if I had done a cat to
stdio or whatever the command would be under Linux. I have used
terminal emulators on the PC for that. As someone mentioned, I think
it used SSH to get to the rPi, I just don't recall the details of
what was happening on the rPi. It may have been running minicom. I
recall having issues with the rPi part that connected the incoming
connection from the PC to the serial port, but I don't recall the
details. This was some years ago.
I want the terminal emulator program on the PC to work as if the
target was connected to the PC. As far as I'm concerned, the rPi can
be invisible... other than wanting a way to boot the target, and by
boot the target, I mean cycle power to the USB port powering it. I
never found a good way to do that. I tried to find a USB hub with
that capability, but the ones I found were either a bit expensive or
didn't really do what I wanted.
I would also like to be able to do this remotely as in across the
Internet. But that's a whole 'nother thing. I've never figured out
how to get past the router. I used to play with that stuff, but it
never seemed to work reliably. Especially using dedicated IP
addresses on different routers. The durn thing would mess with me
and give me an address I didn't ask for.
Am I correct in thinking on a Linux command line the ampersand spawns
the command off as a new process and returns for a new command? The explanation for this talked about Bash, but is this true for other
command interpreters as well?
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:
Rick C wrote:
That sounds like what I did, except there's nothing to run on the rPiOH -- okay so then the corrected approach would be to ssh to the pi,
other than connecting the link from the PC to the serial port to the
target. Forth runs on the target. I like Codewright for an editor,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .
So running a SSH program on the PC would give me a console that is
actually the minicom on the rPi? I should try to resurrect this as I
may need to use it again. I am living in Puerto Rico and it would be
nice to operate a target in the mainland. Other than the need to
reset the target when things get really fouled up. That's why I
wanted a USB hub that could cut power to individual plugs.. or even
the whole hub. Doesn't matter. I just need it to be controllable
from the rPi so it can reboot the target. I guess in theory I could
tie an output from the rPi to the reset line on the target, but there
are times when a power cycle is useful too.
[...]
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
This is starting to come back to me now. The comms program on the PC
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
[...]
What sort of things are you interested in doing in FPGAs?
On 14/03/2022 01:12, Rick C wrote:size.
On Sunday, March 13, 2022 at 7:17:16 PM UTC-4, David Brown wrote:
On 13/03/2022 22:03, Rick C wrote:
On Sunday, March 13, 2022 at 4:16:06 PM UTC-4, David Brown wrote:OK. You didn't include any compilation stage in your description - a
On 13/03/2022 15:38, Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote: >>>>>>You are describing quite a common way to arrange things.
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PC
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
This is starting to come back to me now. The comms program on the PC >>>>> gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
I assume your "terminal emulator" on the PC is something like Putty or >>>> Tera Term Pro. Both are fine for the purpose. In each case, you will >>>> be using the terminal as an ssh client to log into the device.
It is possible to edit things directly on the Pi, using a text-based >>>> editor such as nano. That works fine for small changes, but is less >>>> than ideal for big development. (You can also use vim or emacs - I
personally have never liked either, but they are immensely powerful for >>>> those that have invested the time and effort into learning them.)
And there are many other ways to transfer files to the Pi. The best >>>> ways, for development purposes, is not transfer them at all - use
network filesystems of some kind. Use Windows shares on your PC and >>>> mount the share on the Pi, or have both use a common file server. With >>>> a *nix host system you can also use NFS or even sshfs - file share over >>>> ssh. (This is less efficient than "real" network file systems, but very >>>> easy to set up ad-hoc.) With a Windows development system, standard >>>> Windows CIFS sharing is probably the easiest. And you can do it either >>>> way - it works fine to use the Pi as the server and the PC as the client.
That way you have the same view of the files on your development PC and >>>> the Pi, and you can skip the file transfer step.
There's nothing on the rPi to edit. No files live on the rPi. The
work is done on the PC talking to the compiler on the target.
lot of people use Python on the Pi.
Yes, I did. I said to send it to the target. The target compiles it. I'm sure I mentioned that the compiler is in the flash of the target. That's why I think it has 16kB of flash. 8kB is a bit cramped for a Forth compiler although many exist in that
OK, I see what you are getting at now.
Is there no hosted Forth cross-compiler for your target?
TheMy standard source of laptops is left-overs from the sales folk or other >> administration people.
rPi is there to connect the target serial port to the network. It's
just a pipe. I could use anything for this that runs an OS,
including another laptop. I have a netbook running Windows 7, but it
is so under powered it can barely run a browser. Good thing I don't
need to run a browser on it. I think the mail limitation is the
limited memory actually.
The latest rPi is available with 8 GB I believe. Sounding more like
a Windows machine every day. I should try booting the netbook under
Linux. The screen is rather tiny for my eyes though, but using it
remote the screen doesn't matter.
I am the admin and sales force. I am done with a laptop when it no longer works.
When they get too slow running Windows, I wipe
the disks and install Linux - the machines are faster than they were
when new. (If only Linux could make them as thin and light as modern
machines, and reverse the battery wear!)
I'm pretty sure I ran something on the rPi that was like a terminalI'm not quite sure what you are trying to do, but these links might have >> some ideas:
emulator. Is there a way to easily connect the serial port on the
rPi to the connection from the PC? I'm trying to remember and it
seems like there was a problem that had to do with someone capturing
a special keystroke that didn't work out ok. I don't think it had to
do with the target as that is strictly a TTY type connection. No
need for special keys of any sort. Forth either responds, or you
have to reboot the target. I don't recall.
<https://unix.stackexchange.com/questions/96718/how-do-i-use-a-serial-port-on-linux-like-a-pipe-or-netcat>
<https://www.brainboxes.com/faq/how-to-use-netcat-to-pipe-serial-data-over-tcp>
<https://stackoverflow.com/questions/22624653/create-a-virtual-serial-port-connection-over-tcp>
<https://serverfault.com/questions/384741/forwarding-serial-port-over-network-and-back-to-serial-char-device-on-remote-hos>
If you want to run programs on the Pi and let them keep running after
you disconnect, an extremely useful program is "screen" (especially with >> the "byobu" program that makes it a little nicer).
<https://en.wikipedia.org/wiki/GNU_Screen>
What part of what I'm doing is not clear? I wish to establish the equivalent of a serial port connection from my PC to the target thatYour target is connected to the serial port on the Pi. The Pi is
is physically connected to an rPi. That's it.
connected to your PC by network (I presume). Is that not correct?
If
it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or Tera
Term Pro) to connect to the Pi. What you type in the terminal, goes out
on the serial port, and vice versa. Downloading a file to the target is
just netcat, or whatever equivalent there is on Windows (there's bound
to be a port of netcat).
The terminal emulator
on the PC does everything I need, typing to the command line on the target, sending a file through the pipe as if I had done a cat to
stdio or whatever the command would be under Linux. I have used
terminal emulators on the PC for that. As someone mentioned, I think
it used SSH to get to the rPi, I just don't recall the details of
what was happening on the rPi. It may have been running minicom. I
recall having issues with the rPi part that connected the incoming connection from the PC to the serial port, but I don't recall the
details. This was some years ago.
I want the terminal emulator program on the PC to work as if the
target was connected to the PC. As far as I'm concerned, the rPi can
be invisible... other than wanting a way to boot the target, and by
boot the target, I mean cycle power to the USB port powering it. I
never found a good way to do that. I tried to find a USB hub with
that capability, but the ones I found were either a bit expensive or didn't really do what I wanted.
I would also like to be able to do this remotely as in across the Internet. But that's a whole 'nother thing. I've never figured out
how to get past the router. I used to play with that stuff, but it
never seemed to work reliably. Especially using dedicated IP
addresses on different routers. The durn thing would mess with me
and give me an address I didn't ask for.
Am I correct in thinking on a Linux command line the ampersand spawns
the command off as a new process and returns for a new command? The explanation for this talked about Bash, but is this true for other
command interpreters as well?
Yes, that works on all shells for *nix - at least, all standard ones. There's rarely much reason to use something other than bash, however,
unless you have a minimal Linux system (and then you use Busybox's shell).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:
Rick C wrote:
That sounds like what I did, except there's nothing to run on the rPi >> > other than connecting the link from the PC to the serial port to theOH -- okay so then the corrected approach would be to ssh to the pi,
target. Forth runs on the target. I like Codewright for an editor,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .
So running a SSH program on the PC would give me a console that is actually the minicom on the rPi? I should try to resurrect this as INot really. Things are gonna get a little ugly here, as I haven't used Windows since WindowsXP ... so ... bear with me.
For the sake of discussion / explanation:
DUT = Device Under Test
SerialHost = The machine with a serial port, connected to DUT
PC = Other PC not connected at all to DUT
In an all-windows setup, your workflow is "probably" something like this (or, well, close enough for the sake of discussion)
1. On PC, open up RemoteDesktop, and connect to SerialHost
2. On SerialHost, open up HyperTerm (whatever) and open connection to
COM0, or whatever serial port the DUT is connected to.
3. Tell DUT to start executing your test suite
Since you're using an rPi running linux however, your workflow will be
more like this:
1. On PC, open up PowerShell, PuTTY or (if linux) your terminal
emulator; and SSH into SerialHost
2. On SerialHost, open up minicom, and connect to /dev/ttyS0, or
whatever serial port the DUT is connected to
3. Tell the DUT to start executing the test suite
may need to use it again. I am living in Puerto Rico and it would beIndeed. Offhand I'm not aware of any USB hubs where you can cycle the
nice to operate a target in the mainland. Other than the need to
reset the target when things get really fouled up. That's why I
wanted a USB hub that could cut power to individual plugs.. or even
the whole hub. Doesn't matter. I just need it to be controllable
from the rPi so it can reboot the target. I guess in theory I could
tie an output from the rPi to the reset line on the target, but there
are times when a power cycle is useful too.
power like that. I'd probably just break out VUSB from the cable, and control a FET or something via the Pi's GPIO pins.
[...]
Yes, sticking the intermediary would be a source of "fun(tm)",
regardless of OS. Any OS is going to be something like
1. Write program on main PC
2. Copy program to intermediary PC (or use a network share)
3. Login to intermediary PC
4. Launch whatever to kick the file down the serial port
More like,
1) Run terminal emulator on PCFair enough -- I seemed to pick up at about your step3.
2) Login to rPi, run comms program on rPi
3) Edit application in editor on PC
4) Using PC comms program, send file through rPi to target
5) Test on target interactively
6) Analyze results and return to step 3)
One thing to keep in mind, you're not very likely to send straight from
PC to DUT via your rPi. Rather you'll have to do it in two stages:
4.1 -> Transfer new payload from PC to rPi with SFTP (or other comms program. SFTP is just kind of "dead simple" because you're
already using ssh to access the rPi in the first place.
4.2 -> Using an appropriate serial protocol, transfer the file from
the rPi to the DUT.
This is starting to come back to me now. The comms program on the PCMostly just learning about them. I have no true use for the things
gives me a Linux shell, so I can do other things if I want, like
toggle the reset line on the target or even the power source.
[...]
What sort of things are you interested in doing in FPGAs?
right now (hence devboard thing I have); but they seem to be a decent
tool to have in the toolbox ... one of these days, anyway.
On Sunday, March 13, 2022 at 8:42:20 PM UTC-4, David Brown wrote:...
Am I correct in thinking on a Linux command line the ampersand spawns the command off as a new process and returns for a new command? The explanation for this talked about Bash, but is this true for other command interpreters as well?
Yes, that works on all shells for *nix - at least, all standard ones. There's rarely much reason to use something other than bash, however, unless you have a minimal Linux system (and then you use Busybox's shell).What terminates the process that was spun off? When it completes and would have otherwise returned to the command line?
On Sunday, March 13, 2022 at 8:41:57 PM UTC-4, Dan Purgert wrote:
Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:Not really. Things are gonna get a little ugly here, as I haven't used
Rick C wrote:
That sounds like what I did, except there's nothing to run on the rPi >> >> > other than connecting the link from the PC to the serial port to theOH -- okay so then the corrected approach would be to ssh to the pi,
target. Forth runs on the target. I like Codewright for an editor,
then launch whatever serial modem application (e.g. minicom) is
necessary to talk to the DUT on /dev/ttyS0 .
So running a SSH program on the PC would give me a console that is
actually the minicom on the rPi? I should try to resurrect this as I
Windows since WindowsXP ... so ... bear with me.
For the sake of discussion / explanation:
DUT = Device Under Test
SerialHost = The machine with a serial port, connected to DUT
PC = Other PC not connected at all to DUT
Not sure why you need to rename everything, but ok.
[...]
Since you're using an rPi running linux however, your workflow will be
more like this:
1. On PC, open up PowerShell, PuTTY or (if linux) your terminal
emulator; and SSH into SerialHost
2. On SerialHost, open up minicom, and connect to /dev/ttyS0, or
whatever serial port the DUT is connected to
2.5) Send file from PC to DUT using a feature in Putty. rPi simply transfers the bytes from the file the same as if you typed them.
[...]Indeed. Offhand I'm not aware of any USB hubs where you can cycle the
tie an output from the rPi to the reset line on the target, but there
are times when a power cycle is useful too.
power like that. I'd probably just break out VUSB from the cable, and
control a FET or something via the Pi's GPIO pins.
If I'm doing that, I can just use an rPi I/O pin to toggle the reset
on the target... I mean DUT. I'd prefer to toggle power, but it's not essential. It's just to get out of an infinite loop and restore the
state of the DUT>
[...]
4.2 -> Using an appropriate serial protocol, transfer the file from
the rPi to the DUT.
Protocol? You aren't grasping the situation. From the rPi the file
would would be sent by cat file.f >blah.blah/ttys0 or whatever the
syntax is to simply send the bytes out the serial port. But that's
not important because the file will never be on the rPi. It's sent
from the PC directly through the connection to the terminal. The same
putty or other terminal program will let me dump the file as if it
were a text stream.
[...]Mostly just learning about them. I have no true use for the things
What sort of things are you interested in doing in FPGAs?
right now (hence devboard thing I have); but they seem to be a decent
tool to have in the toolbox ... one of these days, anyway.
Yeah, people mostly don't get FPGAs. Often people think they are only
large, power hungry beasts, only useful for massive number crunching
tasks or insanely parallel problems. The last 20 years I've used
nearly nothing but, small, low power, inexpensive FPGAs that are easy
to work with in 100 pin QFP packages.
Your target is connected to the serial port on the Pi. The Pi is
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
David Brown <david...@hesbynett.no> wrote in news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi isPutty rules!
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Sunday, March 13, 2022 at 8:41:57 PM UTC-4, Dan Purgert wrote:
Rick C wrote:
On Sunday, March 13, 2022 at 9:20:23 AM UTC-4, Dan Purgert wrote:Not really. Things are gonna get a little ugly here, as I haven't used
Rick C wrote:
That sounds like what I did, except there's nothing to run on the rPinecessary to talk to the DUT on /dev/ttyS0 .
other than connecting the link from the PC to the serial port to the >> >> > target. Forth runs on the target. I like Codewright for an editor, >> >> OH -- okay so then the corrected approach would be to ssh to the pi, >> >> then launch whatever serial modem application (e.g. minicom) is
So running a SSH program on the PC would give me a console that is
actually the minicom on the rPi? I should try to resurrect this as I
Windows since WindowsXP ... so ... bear with me.
For the sake of discussion / explanation:
DUT = Device Under Test
SerialHost = The machine with a serial port, connected to DUT
PC = Other PC not connected at all to DUT
Not sure why you need to rename everything, but ok.It was merely for the purposes of keeping the three devices "generic" in
two scenarios; without getting bogged down too much with specific
devices or not (or whether they could run a given OS, etc).
However, it was written before I had seen your conversation with David Brown, after reading which this morning, the workflows I presented last night were not what you were actually describing / attempting to
accomplish.
[...]
Since you're using an rPi running linux however, your workflow will be
more like this:
1. On PC, open up PowerShell, PuTTY or (if linux) your terminal
emulator; and SSH into SerialHost
2. On SerialHost, open up minicom, and connect to /dev/ttyS0, or
whatever serial port the DUT is connected to
2.5) Send file from PC to DUT using a feature in Putty. rPi simply transfers the bytes from the file the same as if you typed them.I've used PuTTY a bit as an interactive ssh and serial port client, but
I'm not aware of it being able to handle things non-interactively.
Is it part of the supporting suite of applications (psftp/pscp/plink/
etc)? If so, I admittedly haven't used them all that much; but will
happily RTFM if you can point me in the right direction.
tie an output from the rPi to the reset line on the target, but there >> > are times when a power cycle is useful too.Indeed. Offhand I'm not aware of any USB hubs where you can cycle the
power like that. I'd probably just break out VUSB from the cable, and
control a FET or something via the Pi's GPIO pins.
If I'm doing that, I can just use an rPi I/O pin to toggle the resetI was specifically commenting on "there are times where a power cycle is useful". I should've done better trimming :(
on the target... I mean DUT. I'd prefer to toggle power, but it's not essential. It's just to get out of an infinite loop and restore the
state of the DUT>
4.2 -> Using an appropriate serial protocol, transfer the file from
the rPi to the DUT.
Protocol? You aren't grasping the situation. From the rPi the fileIndeed -- I was under the impression that you were sending actual files
would would be sent by cat file.f >blah.blah/ttys0 or whatever the
syntax is to simply send the bytes out the serial port. But that's
not important because the file will never be on the rPi. It's sent
from the PC directly through the connection to the terminal. The same putty or other terminal program will let me dump the file as if it
were a text stream.
to the DUT (e.g. using zmodem). I see now that you only intend to send
the file contents.
I think I asked already -- but which feature of PuTTY are you referring
to? The description isn't ringing any bells (well, other than
copy/paste the file content into your interactive session).
[...]Mostly just learning about them. I have no true use for the things
What sort of things are you interested in doing in FPGAs?
right now (hence devboard thing I have); but they seem to be a decent
tool to have in the toolbox ... one of these days, anyway.
Yeah, people mostly don't get FPGAs. Often people think they are only large, power hungry beasts, only useful for massive number crunchingI'd consider 100 pins to be on the large side :). I mostly play around
tasks or insanely parallel problems. The last 20 years I've used
nearly nothing but, small, low power, inexpensive FPGAs that are easy
to work with in 100 pin QFP packages.
with 32-or-fewer pin packages. FPGA (and/or their older PLD/whatever brethren) seem like they're going to be required for a few of my
long-term "big-project" ideas (that I'll probably never get around to,
but oh well).
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in news:t0m311$u6l$1...@dont-email.me:Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
Your target is connected to the serial port on the Pi. The Pi is connected to your PC by network (I presume). Is that not correct?Putty rules!
If it is, then the links I gave you could be useful. You make a serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
On Monday, March 14, 2022 at 10:41:09 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:You don't.
David Brown <david...@hesbynett.no> wrote in news:t0m311$u6l$1...@dont-email.me:Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
Your target is connected to the serial port on the Pi. The Pi is connected to your PC by network (I presume). Is that not correct?Putty rules!
If it is, then the links I gave you could be useful. You make a serial-to-tcpip connection on the Pi, then from the PC you can use telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
You sftp file to rPi, then "cat file > /dev/ttyUSB" from ssh on rPi.
On Monday, March 14, 2022 at 1:52:14 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 10:41:09 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:You don't.
David Brown <david...@hesbynett.no> wrote in news:t0m311$u6l$1...@dont-email.me:Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
Your target is connected to the serial port on the Pi. The Pi is connected to your PC by network (I presume). Is that not correct?Putty rules!
If it is, then the links I gave you could be useful. You make a serial-to-tcpip connection on the Pi, then from the PC you can use telnet (standard Windows application, or something like Putty or Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever equivalent there is on Windows (there's bound to be a port of netcat).
You sftp file to rPi, then "cat file > /dev/ttyUSB" from ssh on rPi.A simple "I don't know" would suffice.
On Monday, March 14, 2022 at 11:25:08 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 1:52:14 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 10:41:09 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:You don't.
David Brown <david...@hesbynett.no> wrote in news:t0m311$u6l$1...@dont-email.me:Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
Your target is connected to the serial port on the Pi. The Pi is connected to your PC by network (I presume). Is that not correct? If it is, then the links I gave you could be useful. You make a serial-to-tcpip connection on the Pi, then from the PC you can use telnet (standard Windows application, or something like Putty or Tera Term Pro) to connect to the Pi. What you type in the terminal, goes out on the serial port, and vice versa.Putty rules!
Downloading a file to the target is just netcat, or whatever equivalent there is on Windows (there's bound to be a port of netcat).
characters. At the very minimum, insert delay between lines:But i do know.You sftp file to rPi, then "cat file > /dev/ttyUSB" from ssh on rPi.A simple "I don't know" would suffice.
Even if you have a version of putty that can transparently forward file. It's not going to solve the delays and errors in your device. Your dumb device (without full buffering) will need time to process commands. Otherwise, it will be dropping
#include <stdio.h>
main()
{
char buf[80];
while(fgets(buf, 80, stdin) != 0)
{
fputs(buf, stdout);
sleep(1);
}
}
The proper way is to read the prompt from your device and process accordingly.
On Monday, March 14, 2022 at 2:31:41 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 11:25:08 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 1:52:14 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 10:41:09 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:You don't.
David Brown <david...@hesbynett.no> wrote in news:t0m311$u6l$1...@dont-email.me:Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
Your target is connected to the serial port on the Pi. The Pi is connected to your PC by network (I presume). Is that not correct?Putty rules!
If it is, then the links I gave you could be useful. You make a serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or Tera Term Pro) to connect to the Pi. What you type in the terminal, goes out on the serial port, and vice versa. Downloading a file to the target is just netcat, or whatever equivalent there is on Windows (there's bound to be a port of netcat).
characters. At the very minimum, insert delay between lines:But i do know.You sftp file to rPi, then "cat file > /dev/ttyUSB" from ssh on rPi.A simple "I don't know" would suffice.
Even if you have a version of putty that can transparently forward file. It's not going to solve the delays and errors in your device. Your dumb device (without full buffering) will need time to process commands. Otherwise, it will be dropping
#include <stdio.h>
main()
{
char buf[80];
while(fgets(buf, 80, stdin) != 0)
{
fputs(buf, stdout);
sleep(1);
}
}
The proper way is to read the prompt from your device and process accordingly.Ed, you know nothing about my application. So you certainly can't predict the failures. I have done this. I'm 99% sure I used ExtraPutty. I know it works. So please stop embarrassing yourself.
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The PiPutty rules!
is connected to your PC by network (I presume). Is that not
correct? If it is, then the links I gave you could be useful.
You make a serial-to-tcpip connection on the Pi, then from the
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and
vice versa. Downloading a file to the target is just netcat, or
whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
David Brown <david.brown@hesbynett.no> wrote in news:t0m311$u6l$1@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi is
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
Putty rules!
On Sunday, March 13, 2022 at 8:42:20 PM UTC-4, David Brown wrote:
On 14/03/2022 01:12, Rick C wrote:
Yes, that works on all shells for *nix - at least, all standard
Am I correct in thinking on a Linux command line the ampersand
spawns the command off as a new process and returns for a new
command? The explanation for this talked about Bash, but is this
true for other command interpreters as well?
ones. There's rarely much reason to use something other than bash,
however, unless you have a minimal Linux system (and then you use
Busybox's shell).
What terminates the process that was spun off? When it completes and
would have otherwise returned to the command line?
I'm surprised I don't remember that. Maybe I didn't use that feature
before.
I looked for the board today and didn't find it. I found the box it
came in with some serial port cables and other components. I think I
put it in a nice box as I was not going to work with it for a while.
But I can't recall what it looked like, so I can't find it. I need
to do some other things the next few days and then will be heading
back to Puerto Rico. Maybe I'll play with this next week.
The only reason I'm thinking of this is because I want to work on
some software that runs on a board I don't want to take to Puerto
Rico. I'm thinking I can do the same thing from Puerto Rico, with
the target in the mainland. But getting through the router, etc. is
a whole 'nother animal.
When you check a web site to give you your IP address, that's the IP
of the router, right? The cable modem is transparent for that?
On Monday, March 14, 2022 at 8:34:09 AM UTC-4, Dan Purgert wrote:
I've used PuTTY a bit as an interactive ssh and serial port client, but
I'm not aware of it being able to handle things non-interactively.
I'm not sure what you mean exactly by "non-interactively". I guess
this is a feature not very often used if you aren't talking to a Forth console. While running Putty or some other terminal emulator, they
often support sending a file as if it were being typed at the console.
No handshake, no protocol. Just transmitting. There might be a
programmable delay following an end line character.
[...] ExtraPutty is the most likely candidate.
[...]
I think I asked already -- but which feature of PuTTY are you referring
to? The description isn't ringing any bells (well, other than
copy/paste the file content into your interactive session).
You mean to shoot a file out the serial port? I don't know, but if it doesn't have that, there are plenty that do. I think they see it as a
way to send a set of commands to the target which is what I am doing, actually.
[...]
I'd consider 100 pins to be on the large side :). I mostly play around
with 32-or-fewer pin packages. FPGA (and/or their older PLD/whatever
brethren) seem like they're going to be required for a few of my
long-term "big-project" ideas (that I'll probably never get around to,
but oh well).
Yeah, you can find those too, but few and far between. Lattice has
some iCE devices and maybe some of the other parts too. I have a full product line sheet that covers those details. I've marked it up to
circle the chips I might use.
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi isPutty rules!
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
Maybe you would know. How do you sent a file to the serial port in
Putty? No, xmodem or protocol, just a dump of the file contents. I
assume there's a command/control for that?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 8:34:09 AM UTC-4, Dan Purgert wrote:
I've used PuTTY a bit as an interactive ssh and serial port client, but
I'm not aware of it being able to handle things non-interactively.
I'm not sure what you mean exactly by "non-interactively". I guessLiterally "you're not interacting with it" :)
this is a feature not very often used if you aren't talking to a Forth console. While running Putty or some other terminal emulator, they
often support sending a file as if it were being typed at the console.
No handshake, no protocol. Just transmitting. There might be a
programmable delay following an end line character.
That is, it could be spawned, execute a thing, and then hang up / close
down all without you doing anything after spawning it.
[...] ExtraPutty is the most likely candidate.
Oh, that would explain it then; "ExtraPutty" is not "PuTTY".
[...]
I think I asked already -- but which feature of PuTTY are you referring
to? The description isn't ringing any bells (well, other than
copy/paste the file content into your interactive session).
You mean to shoot a file out the serial port? I don't know, but if it doesn't have that, there are plenty that do. I think they see it as aWell, PuTTY can do that, but only to a locally connected device. There
way to send a set of commands to the target which is what I am doing, actually.
would be hoops to jump through to have an SSH session be able to do
this.
On Monday, March 14, 2022 at 4:58:12 PM UTC-7, Dan Purgert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 8:34:09 AM UTC-4, Dan Purgert wrote:Literally "you're not interacting with it" :)
I've used PuTTY a bit as an interactive ssh and serial port client, but >> >> I'm not aware of it being able to handle things non-interactively.
I'm not sure what you mean exactly by "non-interactively". I guess
this is a feature not very often used if you aren't talking to a Forth
console. While running Putty or some other terminal emulator, they
often support sending a file as if it were being typed at the console.
No handshake, no protocol. Just transmitting. There might be a
programmable delay following an end line character.
That is, it could be spawned, execute a thing, and then hang up / close
down all without you doing anything after spawning it.
[...] ExtraPutty is the most likely candidate.
Oh, that would explain it then; "ExtraPutty" is not "PuTTY".
Well, PuTTY can do that, but only to a locally connected device. There[...]
I think I asked already -- but which feature of PuTTY are you referring >> >> to? The description isn't ringing any bells (well, other than
copy/paste the file content into your interactive session).
You mean to shoot a file out the serial port? I don't know, but if it
doesn't have that, there are plenty that do. I think they see it as a
way to send a set of commands to the target which is what I am doing,
actually.
would be hoops to jump through to have an SSH session be able to do
this.
Perhaps some other terminal emulator, but not Putty or extraPutty. *Putty won't send raw file over ssh.
On Monday, March 14, 2022 at 1:05:03 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 2:31:41 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 11:25:08 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 1:52:14 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 10:41:09 AM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:You don't.
David Brown <david...@hesbynett.no> wrote in news:t0m311$u6l$1...@dont-email.me:Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
Your target is connected to the serial port on the Pi. The Pi isPutty rules!
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the terminal, goes out on the serial port, and vice versa. Downloading a file to the target is just netcat, or whatever equivalent there is on Windows (there's bound to be a port of netcat).
characters. At the very minimum, insert delay between lines:But i do know.You sftp file to rPi, then "cat file > /dev/ttyUSB" from ssh on rPi.A simple "I don't know" would suffice.
Even if you have a version of putty that can transparently forward file. It's not going to solve the delays and errors in your device. Your dumb device (without full buffering) will need time to process commands. Otherwise, it will be dropping
#include <stdio.h>
main()
{
char buf[80];
while(fgets(buf, 80, stdin) != 0)
{
fputs(buf, stdout);
sleep(1);
}
}
Did you use it on a PC connected to your device?The proper way is to read the prompt from your device and process accordingly.Ed, you know nothing about my application. So you certainly can't predict the failures. I have done this. I'm 99% sure I used ExtraPutty. I know it works. So please stop embarrassing yourself.
Now, you are talking about PC -> rPi -> device.
You are asking for a Putty to forward from file to connection on the window, and a second Putty to forward from connection 1 to connection 2 on the rPi, which i know it does not support. If you think that's possible, please tell us how.
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:target board.
Rick C <gnuarm.del...@gmail.com> wrote in news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The PiPutty rules!
is connected to your PC by network (I presume). Is that not
correct? If it is, then the links I gave you could be useful.
You make a serial-to-tcpip connection on the Pi, then from the
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and
vice versa. Downloading a file to the target is just netcat, or
whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
There needs to be a protocol. You are connecting to devices togetherSorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
over a connection. That is one thing, but passing files is another,
and one still needs a packet routine.
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network interface for the
Rick C <gnuarm.del...@gmail.com> wrote in news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The PiPutty rules!
is connected to your PC by network (I presume). Is that not
correct? If it is, then the links I gave you could be useful.
You make a serial-to-tcpip connection on the Pi, then from the
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and
vice versa. Downloading a file to the target is just netcat, or
whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
There needs to be a protocol. You are connecting to devices together
over a connection. That is one thing, but passing files is another,
and one still needs a packet routine.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 8:34:09 AM UTC-4, Dan Purgert wrote:
I've used PuTTY a bit as an interactive ssh and serial port client, but >> I'm not aware of it being able to handle things non-interactively.
I'm not sure what you mean exactly by "non-interactively". I guessLiterally "you're not interacting with it" :)
this is a feature not very often used if you aren't talking to a Forth console. While running Putty or some other terminal emulator, they
often support sending a file as if it were being typed at the console.
No handshake, no protocol. Just transmitting. There might be a programmable delay following an end line character.
That is, it could be spawned, execute a thing, and then hang up / close
down all without you doing anything after spawning it.
[...] ExtraPutty is the most likely candidate.
Oh, that would explain it then; "ExtraPutty" is not "PuTTY".
I think I asked already -- but which feature of PuTTY are you referring >> to? The description isn't ringing any bells (well, other than
copy/paste the file content into your interactive session).
You mean to shoot a file out the serial port? I don't know, but if it doesn't have that, there are plenty that do. I think they see it as aWell, PuTTY can do that, but only to a locally connected device. There
way to send a set of commands to the target which is what I am doing, actually.
would be hoops to jump through to have an SSH session be able to do
this.
I'd consider 100 pins to be on the large side :). I mostly play around
with 32-or-fewer pin packages. FPGA (and/or their older PLD/whatever
brethren) seem like they're going to be required for a few of my
long-term "big-project" ideas (that I'll probably never get around to,
but oh well).
Yeah, you can find those too, but few and far between. Lattice has'iCE' sounds very familiar.
some iCE devices and maybe some of the other parts too. I have a full product line sheet that covers those details. I've marked it up to
circle the chips I might use.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi isPutty rules!
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
Maybe you would know. How do you sent a file to the serial port inIf you have the device connected to the SAME machine that PuTTY is
Putty? No, xmodem or protocol, just a dump of the file contents. I
assume there's a command/control for that?
connected to, you select the "Serial" connection type (as opposed to the default type -- I believe it's SSH); and then select the correct COM#
port, and provide the correct connection parameters (e.g. 9600 8N1).
However, this is for a device connected locally. If the device is
connected to another computer; you have to connect to that computer
first (e.g. Remote desktop if it's a Windows-based machine; or ssh if
it's Linux).
On Monday, March 14, 2022 at 8:34:47 PM UTC-7, gnuarm.del...@gmail.com wrote:the target board.
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote in news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The PiPutty rules!
is connected to your PC by network (I presume). Is that not
correct? If it is, then the links I gave you could be useful.
You make a serial-to-tcpip connection on the Pi, then from the
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and
vice versa. Downloading a file to the target is just netcat, or
whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
There needs to be a protocol. You are connecting to devices together over a connection. That is one thing, but passing files is another,Sorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
and one still needs a packet routine.
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network interface for
Then it must be another terminal emulator. (Extra)Putty does not pass raw file via ssh. It allows ftp or sftp transfer, but with another connection and possibly another process. There is no way to send a raw file with the same control connection. Iknow there are other emulator sending raw file with the same serial port, but not Putty and not via ssh.
On Monday, March 14, 2022 at 11:44:16 PM UTC-4, Ed Lee wrote:the target board.
On Monday, March 14, 2022 at 8:34:47 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote in news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The PiPutty rules!
is connected to your PC by network (I presume). Is that not
correct? If it is, then the links I gave you could be useful.
You make a serial-to-tcpip connection on the Pi, then from the
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and >> > vice versa. Downloading a file to the target is just netcat, or >> > whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
There needs to be a protocol. You are connecting to devices together over a connection. That is one thing, but passing files is another, and one still needs a packet routine.Sorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network interface for
know there are other emulator sending raw file with the same serial port, but not Putty and not via ssh.Then it must be another terminal emulator. (Extra)Putty does not pass raw file via ssh. It allows ftp or sftp transfer, but with another connection and possibly another process. There is no way to send a raw file with the same control connection. I
Using SSH on Putty, can I talk to the command line on the remote computer with a terminal like interface?
On Monday, March 14, 2022 at 9:18:33 PM UTC-7, gnuarm.del...@gmail.com wrote:for the target board.
On Monday, March 14, 2022 at 11:44:16 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 8:34:47 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote in news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi >> > is connected to your PC by network (I presume). Is that notPutty rules!
correct? If it is, then the links I gave you could be useful. >> > You make a serial-to-tcpip connection on the Pi, then from the >> > PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and >> > vice versa. Downloading a file to the target is just netcat, or >> > whatever equivalent there is on Windows (there's bound to be a >> > port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
There needs to be a protocol. You are connecting to devices together over a connection. That is one thing, but passing files is another, and one still needs a packet routine.Sorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network interface
know there are other emulator sending raw file with the same serial port, but not Putty and not via ssh.Then it must be another terminal emulator. (Extra)Putty does not pass raw file via ssh. It allows ftp or sftp transfer, but with another connection and possibly another process. There is no way to send a raw file with the same control connection. I
Using SSH on Putty, can I talk to the command line on the remote computer with a terminal like interface?Yes, but there is no option to send a raw file.
On Tuesday, March 15, 2022 at 12:24:28 AM UTC-4, Ed Lee wrote:for the target board.
On Monday, March 14, 2022 at 9:18:33 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 11:44:16 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 8:34:47 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote in news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi >> > is connected to your PC by network (I presume). Is that not >> > correct? If it is, then the links I gave you could be useful. >> > You make a serial-to-tcpip connection on the Pi, then from thePutty rules!
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi. >> > What you type in the terminal, goes out on the serial port, and
vice versa. Downloading a file to the target is just netcat, or
whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
There needs to be a protocol. You are connecting to devices togetherSorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
over a connection. That is one thing, but passing files is another,
and one still needs a packet routine.
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network interface
I know there are other emulator sending raw file with the same serial port, but not Putty and not via ssh.Then it must be another terminal emulator. (Extra)Putty does not pass raw file via ssh. It allows ftp or sftp transfer, but with another connection and possibly another process. There is no way to send a raw file with the same control connection.
Then why do you keep talking about SSH?Using SSH on Putty, can I talk to the command line on the remote computer with a terminal like interface?Yes, but there is no option to send a raw file.
If it can't transfer a "raw file" on SSH, are you saying it can over a serial port?
I think what you aren't grasping is this is not a file transfer. So try to put that out of your mind. This is simply using the file as a container on the PC to hold the commands to be typed on the console.
On Monday, March 14, 2022 at 9:41:56 PM UTC-7, gnuarm.del...@gmail.com wrote:interface for the target board.
On Tuesday, March 15, 2022 at 12:24:28 AM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 9:18:33 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 11:44:16 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 8:34:47 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote in news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The PiPutty rules!
is connected to your PC by network (I presume). Is that not >> > correct? If it is, then the links I gave you could be useful.
You make a serial-to-tcpip connection on the Pi, then from the
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and
vice versa. Downloading a file to the target is just netcat, or
whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file contents. I assume there's a command/control for that?
There needs to be a protocol. You are connecting to devices togetherSorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
over a connection. That is one thing, but passing files is another,
and one still needs a packet routine.
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network
connection. I know there are other emulator sending raw file with the same serial port, but not Putty and not via ssh.Then it must be another terminal emulator. (Extra)Putty does not pass raw file via ssh. It allows ftp or sftp transfer, but with another connection and possibly another process. There is no way to send a raw file with the same control
Because you have to do telnet or ssh protocol over the net.Then why do you keep talking about SSH?Using SSH on Putty, can I talk to the command line on the remote computer with a terminal like interface?Yes, but there is no option to send a raw file.
If it can't transfer a "raw file" on SSH, are you saying it can over a serial port?No, someone else said it could. I don't think there is any option to send a local raw (not over ftp or tftp) file in serial port either. You can argue that Putty should, but it does not.
I think what you aren't grasping is this is not a file transfer. So try to put that out of your mind. This is simply using the file as a container on the PC to hold the commands to be typed on the console.I am not saying it's file transfer. You have your command file in the local PC. You have to somehow get the content of the file over on top of telnet/ftp protocol. Putty just does not have this feature.
On Monday, March 14, 2022 at 8:03:17 PM UTC-4, Dan Purgert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:If you have the device connected to the SAME machine that PuTTY is
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi isPutty rules!
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use
telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
Maybe you would know. How do you sent a file to the serial port in
Putty? No, xmodem or protocol, just a dump of the file contents. I
assume there's a command/control for that?
connected to, you select the "Serial" connection type (as opposed to the
default type -- I believe it's SSH); and then select the correct COM#
port, and provide the correct connection parameters (e.g. 9600 8N1).
However, this is for a device connected locally. If the device is
connected to another computer; you have to connect to that computer
first (e.g. Remote desktop if it's a Windows-based machine; or ssh if
it's Linux).
That's not what I'm asking. I'm asking about the control in Putty to
cause the contents of a file to be sent to the port. I'm asking how
to get inside the supermarket and you are giving me directions on how
to drive there from two locations.
I'm pretty sure that once in Putty, you make the port connection, it
doesn't matter which type of port, the controls in the program work
the same to do the same functions.
It's probably better to wait until I have time to fire up the setup.
Then I can explore it myself without having so much trouble being misunderstood.
On Monday, March 14, 2022 at 7:58:12 PM UTC-4, Dan Purgert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 8:34:09 AM UTC-4, Dan Purgert wrote:Literally "you're not interacting with it" :)
I've used PuTTY a bit as an interactive ssh and serial port client, but >> >> I'm not aware of it being able to handle things non-interactively.
I'm not sure what you mean exactly by "non-interactively". I guess
this is a feature not very often used if you aren't talking to a Forth
console. While running Putty or some other terminal emulator, they
often support sending a file as if it were being typed at the console.
No handshake, no protocol. Just transmitting. There might be a
programmable delay following an end line character.
That is, it could be spawned, execute a thing, and then hang up / close
down all without you doing anything after spawning it.
Sorry, I don't know what "it" you are talking about.
Of course I would be interacting with Putty. I type commands to the
target through Putty. I tell Putty to send the file when I want to
compile.
[...] ExtraPutty is the most likely candidate.
Oh, that would explain it then; "ExtraPutty" is not "PuTTY".
It would explain what? I used to use Putty, but changed to ExtraPutty because it sounded like it was "extra". I didn't see any reason to
not use it and it worked pretty much the same.
[...]Well, PuTTY can do that, but only to a locally connected device. There
You mean to shoot a file out the serial port? I don't know, but if it
doesn't have that, there are plenty that do. I think they see it as a
way to send a set of commands to the target which is what I am doing,
actually.
would be hoops to jump through to have an SSH session be able to do
this.
Sorry, I have no idea how it would be different. If I'm running the
terminal emulator, it looks and works the same whether I'm on a local
serial port or on a SSH connection to the rPi. What is different?
... yeah, I did notice that. It's kinda why I was gravitating toward[...][...]
'iCE' sounds very familiar.
I believe this is the only logic family with open source tools, 100%
open source tools, including the bitstream generation. The guys who
did this have a big notch on their belts.
On Tuesday, March 15, 2022 at 12:24:28 AM UTC-4, Ed Lee wrote:for the target board.
On Monday, March 14, 2022 at 9:18:33 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 11:44:16 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 8:34:47 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote inSorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4,There needs to be a protocol. You are connecting to devices together >> > > > > over a connection. That is one thing, but passing files is another, >> > > > > and one still needs a packet routine.
DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi >> > > > > >> > is connected to your PC by network (I presume). Is that notPutty rules!
correct? If it is, then the links I gave you could be useful. >> > > > > >> > You make a serial-to-tcpip connection on the Pi, then from the >> > > > > >> > PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi.
What you type in the terminal, goes out on the serial port, and >> > > > > >> > vice versa. Downloading a file to the target is just netcat, or >> > > > > >> > whatever equivalent there is on Windows (there's bound to be a >> > > > > >> > port of netcat).
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network interface
I know there are other emulator sending raw file with the same serial port, but not Putty and not via ssh.Then it must be another terminal emulator. (Extra)Putty does not pass raw file via ssh. It allows ftp or sftp transfer, but with another connection and possibly another process. There is no way to send a raw file with the same control connection.
Yes, but there is no option to send a raw file.
Using SSH on Putty, can I talk to the command line on the remote computer with a terminal like interface?
Then why do you keep talking about SSH? If it can't transfer a "raw file" on SSH, are you saying it can over a serial port?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 7:58:12 PM UTC-4, Dan Purgert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 8:34:09 AM UTC-4, Dan Purgert wrote:Literally "you're not interacting with it" :)
I've used PuTTY a bit as an interactive ssh and serial port client, but
I'm not aware of it being able to handle things non-interactively.
I'm not sure what you mean exactly by "non-interactively". I guess
this is a feature not very often used if you aren't talking to a Forth >> > console. While running Putty or some other terminal emulator, they
often support sending a file as if it were being typed at the console. >> > No handshake, no protocol. Just transmitting. There might be a
programmable delay following an end line character.
That is, it could be spawned, execute a thing, and then hang up / close >> down all without you doing anything after spawning it.
Sorry, I don't know what "it" you are talking about.Whatever application(s) you're using to attempt to read a file and
submit the contents contained therein to the ultimate destination.
Of course I would be interacting with Putty. I type commands to thePuTTY is a Windows application. The only serial ports it can talk to
target through Putty. I tell Putty to send the file when I want to compile.
are those serial ports physically present on the machine it's running.
If you are using it as an SSH client to a remote host, it cannot
directly talk to the serial ports on that remote host. You need
something else running on that remote host to handle talking to that
host's serial port; such as minicom or (as you said) cat file >
/dev/ttyS0.
[...] ExtraPutty is the most likely candidate.
Oh, that would explain it then; "ExtraPutty" is not "PuTTY".
It would explain what? I used to use Putty, but changed to ExtraPutty because it sounded like it was "extra". I didn't see any reason toIt would explain why I'm completely unaware of the feature you mentioned about being able to be handed a file, read said file, and then send the contents over the wire.
not use it and it worked pretty much the same.
^^^^ clarity here --> you'd have to open the file in Notepad (etc.) and copy/paste the contents into the PuTTY-terminal window.You mean to shoot a file out the serial port? I don't know, but if it >> > doesn't have that, there are plenty that do. I think they see it as a >> > way to send a set of commands to the target which is what I am doing, >> > actually.Well, PuTTY can do that, but only to a locally connected device. There
would be hoops to jump through to have an SSH session be able to do
this.
Sorry, I have no idea how it would be different. If I'm running the terminal emulator, it looks and works the same whether I'm on a local serial port or on a SSH connection to the rPi. What is different?Assuming a standard configuration, using SSH from host1 to host2 does nothing more than open a shell for you. It is akin to sitting down at "host2", logging in, then opening the terminal emulator. That's it.
Think of it this way --
"When I RDP into a machine, I can open HyperTerm and talk to my DUT on
COM1. However, when I open HyperTerm on my main machine, it complains
it can't talk to the device; what is different?"
... yeah, I did notice that. It's kinda why I was gravitating toward[...][...]
'iCE' sounds very familiar.
I believe this is the only logic family with open source tools, 100%
open source tools, including the bitstream generation. The guys who
did this have a big notch on their belts.
it. All the other players are "use Windows!"
On 2022-03-15, Rick C <gnuarm.del...@gmail.com> wrote:interface for the target board.
On Tuesday, March 15, 2022 at 12:24:28 AM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 9:18:33 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 11:44:16 PM UTC-4, Ed Lee wrote:
On Monday, March 14, 2022 at 8:34:47 PM UTC-7, gnuarm.del...@gmail.com wrote:
On Monday, March 14, 2022 at 4:19:43 PM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote inSorry, I have no idea what you think is going on. I'm not passing files between computers. Try to read what has been written and understand.
news:575bfc3d-f27b-4ba7...@googlegroups.com:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4,There needs to be a protocol. You are connecting to devices together
DecadentLinux...@decadence.org wrote:
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The PiPutty rules!
is connected to your PC by network (I presume). Is that not >> > > > > >> > correct? If it is, then the links I gave you could be useful.
You make a serial-to-tcpip connection on the Pi, then from the
PC you can use telnet (standard Windows application, or
something like Putty or Tera Term Pro) to connect to the Pi. >> > > > > >> > What you type in the terminal, goes out on the serial port, and
vice versa. Downloading a file to the target is just netcat, or
whatever equivalent there is on Windows (there's bound to be a
port of netcat).
Maybe you would know. How do you sent a file to the serial port >> > > > > > in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
over a connection. That is one thing, but passing files is another,
and one still needs a packet routine.
The entire software on the two computes running an OS are trying to provide a path from Putty (or some other terminal emulator) on the PC to the target as if it were on a serial port on the PC. The rPi is acting as a serial to network
I know there are other emulator sending raw file with the same serial port, but not Putty and not via ssh.Then it must be another terminal emulator. (Extra)Putty does not pass raw file via ssh. It allows ftp or sftp transfer, but with another connection and possibly another process. There is no way to send a raw file with the same control connection.
Yes, but there is no option to send a raw file.
Using SSH on Putty, can I talk to the command line on the remote computer with a terminal like interface?
Then why do you keep talking about SSH? If it can't transfer a "raw file" on SSH, are you saying it can over a serial port?ssh can transfer raw files, I use it for that frequently. As GUI application putty probably doesn't support this.
The ssh that comes with git bash should support it though. something
like this:
ssh user@raspberry "cat > /dev/ttyACM0" < C:\windows\users\jasen\source.4th
Sorry, I have no idea what you think is going on. I'm not passing
files between computers. Try to read what has been written and
understand.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 8:03:17 PM UTC-4, Dan Purgert wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Rick C wrote:
On Monday, March 14, 2022 at 10:09:04 AM UTC-4, DecadentLinux...@decadence.org wrote:If you have the device connected to the SAME machine that PuTTY is
David Brown <david...@hesbynett.no> wrote in
news:t0m311$u6l$1...@dont-email.me:
Your target is connected to the serial port on the Pi. The Pi isPutty rules!
connected to your PC by network (I presume). Is that not correct?
If it is, then the links I gave you could be useful. You make a
serial-to-tcpip connection on the Pi, then from the PC you can use >> >> > telnet (standard Windows application, or something like Putty or
Tera Term Pro) to connect to the Pi. What you type in the
terminal, goes out on the serial port, and vice versa.
Downloading a file to the target is just netcat, or whatever
equivalent there is on Windows (there's bound to be a port of
netcat).
Maybe you would know. How do you sent a file to the serial port in
Putty? No, xmodem or protocol, just a dump of the file contents. I
assume there's a command/control for that?
connected to, you select the "Serial" connection type (as opposed to the >> default type -- I believe it's SSH); and then select the correct COM#
port, and provide the correct connection parameters (e.g. 9600 8N1).
However, this is for a device connected locally. If the device is
connected to another computer; you have to connect to that computer
first (e.g. Remote desktop if it's a Windows-based machine; or ssh if
it's Linux).
That's not what I'm asking. I'm asking about the control in Putty toAFAIK, with PuTTY, it'd be that you connect to the serial port (or ssh/telnet/whatever else it offers), and then copy/paste the contents
cause the contents of a file to be sent to the port. I'm asking how
to get inside the supermarket and you are giving me directions on how
to drive there from two locations.
into the resulting terminal window once the connection is established.
A lot like running remote desktop between two windows machines (uh, I
think -- I haven't used windows / RDP since WindowsXP; I could very well
be mistaken in my memory).
I'm pretty sure that once in Putty, you make the port connection, it doesn't matter which type of port, the controls in the program workYes and no - what is understood in the terminal window is wholly
the same to do the same functions.
dependent on what you've connected to.
For example -> using PuTTY on my windows tablet thingie, I can either
(1) connect to an Arduino on COM1 OR
(2) SSH to my main laptop
in case (1), it's only going to understand the input "hi" (because
that's all I've programmed the MCU to look for)
in case (2), it's going to understand whatever 'bash' (i.e. my shell on
that machine) understands.
It's probably better to wait until I have time to fire up the setup.perhaps :) but the discussion is interesting nonetheless (even if we're
Then I can explore it myself without having so much trouble being misunderstood.
not completely on the same page.
On Tuesday, March 15, 2022 at 5:33:11 AM UTC-4, Dan Purgert wrote:
Rick C wrote:
Of course I would be interacting with Putty. I type commands to thePuTTY is a Windows application. The only serial ports it can talk to
target through Putty. I tell Putty to send the file when I want to
compile.
are those serial ports physically present on the machine it's running.
If you are using it as an SSH client to a remote host, it cannot
directly talk to the serial ports on that remote host. You need
something else running on that remote host to handle talking to that
host's serial port; such as minicom or (as you said) cat file >
/dev/ttyS0.
Have you not been in this conversation until now? I have said
several times I was running something like minicom on the rPi.
On Tuesday, March 15, 2022 at 9:01:08 AM UTC-4, Jasen Betts wrote:^^ (line break inserted for usenet)
[...]
ssh user@raspberry "cat > /dev/ttyACM0" < \
C:\windows\users\jasen\source.4th
I never did that. I'm not sure how the rPi would know what C:\windows\users\jasen\source.4th would mean. Regardless, I used a
feature of Putty to send the contents of the file to the rPi command
line which was running something like minicom.
On 08/03/2022 21:21, bitrex wrote:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?
<https://www.vortex86.com/products>
(no financial affiliation)
A couple of things that use it ...
This Commercial Kitchen Appliance Uses an Original Pentium Clone CPU
(and Runs DOS)!
https://www.youtube.com/watch?v=BdSJgoP2a88
MSTI PDX-1000 1 GHz Vortex86DX Linux thin client PC https://www.youtube.com/watch?v=pkqtQ3ySE6c
On 3/9/2022 12:18 PM, Adrian Caspersz wrote:
On 08/03/2022 21:21, bitrex wrote:
Who hasn't wanted a 1 GHz dual-core 486 that supports DDR3?
<https://www.vortex86.com/products>
(no financial affiliation)
A couple of things that use it ...
This Commercial Kitchen Appliance Uses an Original Pentium Clone CPU
(and Runs DOS)!
https://www.youtube.com/watch?v=BdSJgoP2a88
MSTI PDX-1000 1 GHz Vortex86DX Linux thin client PC https://www.youtube.com/watch?v=pkqtQ3ySE6c
Yes, I learned from a reliable source that e.g. FreeBSD detects these processors as ""UnknownPentium"
Rick C <gnuarm.del...@gmail.com> wrote in news:6ae91ddc-e353-45a8...@googlegroups.com:
Sorry, I have no idea what you think is going on. I'm not passingpassing files in a serial manner using putty.
files between computers. Try to read what has been written and
understand.
On Tuesday, March 15, 2022 at 11:11:52 AM UTC-4, DecadentLinux...@decadence.org wrote:typing at a terminal.
Rick C <gnuarm.del...@gmail.com> wrote in news:6ae91ddc-e353-45a8...@googlegroups.com:No, no files are being passed. Data is being sent to the target on a serial stream. No files. Files have names and structure and live in a file system. There is no file system on the recipient of the data. The target just sees a serial stream like
Sorry, I have no idea what you think is going on. I'm not passingpassing files in a serial manner using putty.
files between computers. Try to read what has been written and understand.
ssh user@raspberry "cat > /dev/ttyACM0" < C:\windows\users\jasen\source.4th
I never did that. I'm not sure how the rPi would know what C:\windows\users\jasen\source.4th would mean.
Regardless, I used a
feature of Putty to send the contents of the file to the rPi command
line which was running something like minicom.
On Tuesday, March 15, 2022 at 11:11:52 AM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote in
news:6ae91ddc-e353-45a8...@googlegroups.com:
Sorry, I have no idea what you think is going on. I'm notpassing files in a serial manner using putty.
passing files between computers. Try to read what has been
written and understand.
No, no files are being passed. Data is being sent to the target
on a serial stream. No files. Files have names and structure and
live in a file system. There is no file system on the recipient
of the data. The target just sees a serial stream like typing at
a terminal.
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
Rick C <gnuarm.del...@gmail.com> wrote in news:c9920488-0056-4677...@googlegroups.com:
On Tuesday, March 15, 2022 at 11:11:52 AM UTC-4, DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.del...@gmail.com> wrote in
news:6ae91ddc-e353-45a8...@googlegroups.com:
Sorry, I have no idea what you think is going on. I'm notpassing files in a serial manner using putty.
passing files between computers. Try to read what has been
written and understand.
No, no files are being passed. Data is being sent to the target
on a serial stream. No files. Files have names and structure and
live in a file system. There is no file system on the recipient
of the data. The target just sees a serial stream like typing at
a terminal.
In your last post you specifically mentioned passing files.
quote:
Maybe you would know. How do you sent a file to the serial port
in Putty? No, xmodem or protocol, just a dump of the file
contents. I assume there's a command/control for that?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 230 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 53:17:03 |
| Calls: | 4,911 |
| Calls today: | 8 |
| Files: | 11,508 |
| Messages: | 3,971,999 |
| Posted today: | 1 |
