Re: inpout32
- Posted by jimcbrown (admin) 3 weeks ago
- 777 views
I didn't look too hard, but I thought it was a "switch op do" statement - and wondered why the op parameter was declared object rather than integer(/enum).
And i suppose the info Pete and Greg need to solve this is in the OE readme?
Kat
Nope, assuming https://github.com/OpenEuphoria/euphoria/blob/master/README.md is the one. But that's not surprising considering that Greg's the one who wrote it...
The list was huge, and would be growing,
It almost sounds like it could have been a major lift just going through the lift, even assuming there was some trivial solution to the connection problem that was put into play.
If i didn't randomly pick a different line item each time, you'd fixate on one controllable item
In the interests of finding alternative solutions that don't require solving the below:
when the issue is the connection from the computer to any of the items.
I mean, this is both the most controllable and uncontrollable element at the same time.
This is basically a solved problem. So to make it work, you just need to:
a) Learn C, and Windows Kernel Device Driver programming
or
b) Learn Unix
or
c) Integrate one of the modernized Commodore 64 solutions into the system to do the job
d) pay someone who knows a) or b) already to make something you can use. Note though that you'd probably get charged per line item, so this is the most difficult as well as the most expensive way to go.
Since when is a 8-bit parallel port or RS-232 serial port (for that mouse and keybd) specialized?
It's a much older protocol that's not so used nowadays. I wanna say it was the mid-aughts that the transition happened. But now they're like DR-DOS - once general purpose, but now not in common use, mostly in specialized applications nowadays.
You know what would be wonderfully "specialised"? A selection of small sbc that restore the olde parport support of EU, and solve some 30 year old deficiencies of it.
Agreed. As EU never had parport support in it's standard library (unless one counts the OS supporting opening it as a file or something like "LPT1:") it would indeed be quite the feat to accomplish this.
And you know what? I'd offer the same $1000's of money i offered up till they took it away and gave us only usb ports,
The problem with this is that both Windows Kernel and Unix devs tend to earn six figure salaries.
and locked them down in software.
Well, not if one is using the right OS, but then again, see note about Unix dev salaries above.
than re-establish OE's connectivity to the real world.
I mean, we have a number of examples of that working, which you even quoted from. It's just - none of the ways work for you, and you're being a bit tight lipped about why.
Now of course that's your right - but think of it like a crossword puzzle. I have no idea what seven letter word T I A Y H C - plus a missing letter - should unscramble too, but if you give me the hint of "starts with CHA and ends with ITY" I could much more easily guess that the missing letter is R and the final word is CHARITY.
Going back to the above list of a, b, c, & d - d is obviously a non-starter for being too expensive, and a or b would be a tough pill to swallow (C or Unix?)
The reason why c got rejected remains unclear, which is unfortunate since with the limited view that you've shared on the matter, it's not clear how else to solve the puzzle here.
basically what i hear here is variations on "anyone can do it, so no one will"
Well, of course not. If anyone could write Windows Kernel Device Drivers, we'd see a lot more of it. Also, the folks who do it wouldn't be making such high six figure salaries.
or "spend a lot of time on 1000 different possibilities we can list but not prove can work, because no one here will".
Ha! I wish there were 1000 different possibilities, instead of four. Much easier to find a winning combo this way.
So this forum goes on about "mower? changing goalposts!",
Yeah, but this sort of misunderstanding is ripe for the picking when the entire ask is not fully spelled out.
but cannot do the same with [snip] OE code.
Well, it can be done, but... see entire post above.
This forum makes excuses the same way humans do in real life.
Kat
I mean, if the way forward is to program an Ultimate64 to monitor your water delivery and order water delivery from Walmart for you...
What was the excuse for not using an Ultimate64 again?
Actually, there are a number of examples on this forum (of using Eu to communicate with an rPi, Arduino, etc), including this one from irv himself.
Even one from ryanj, https://openeuphoria.org/forum/m/123448.wc
That's the one i put money into.
I did not know that.
Note the date of the post: Dec 28, 2013. I heard the same assurances there'd be forthcoming code several times this year.
I also did not know that. I'm surprised you are still getting assurances after a decade (as opposed to just silence or not being able to find anyone still connected to the project).
I'd have put more money into it, but the project has been dead at Ryan's end for 11 years now.
Not clear it would have helped anyways - at the time of the post at least, it only worked with FTDI USB UART devices if I'm understanding correctly. Though it sounds like you have more up to date information on this anyways.
That's the problem with the Windoze approach - each one seems to be using their own device drivers, and each time it's different. There's no one "generic" device driver that can talk to everything, rather you pick a product to talk to and then you hope a device driver exists to talk to that specific product over the type of GPIO that you want to use.
Which used a existing wireless net set up by a smart phone, or using the smart phone as a hotspot of some sort to a network. I have no smart phone, and never needed one to turn on a lamp before.
It's nice to be able to do it from a smart phone if you have one, but I totally get this being a non-starter if one doesn't have one.
it's as if a GPIO port [snip] might be useable only to operate [snip] a lawn mower, but not both!?!
How the heck does one drive a lawn mower with a single general purpose input output digital signal pin? Surely steering requires more than just on/off?
I think that's part of the problem here though. What katsmeow wants this to be used for seemingly keeps changing (car engine monitoring? turning on a fan on a roof? driving a lawn mower?), so even if someone were to devote all the effort to fixing one aspect, a more complex one would arise.
Golly gee, it's as if a GPIO port is "specialised" after all,
Well, no. It's in the name in fact - "general purpose"
But there are multiple types of GPIO. Parallel and RS232 Serial, and USB (actually each type like USB A, USB B, USB C is different), but others like FireWire too.
And talking to each type of GPIO is different and requires specific code for that. You can't really write one driver that talks on all GPIOs.
How in the heck can anything i plan on using it for change the OE code of write(parport,{16,12,"no"}) ?
I think there's a typo, let me fix that for you.
How in the heck can anything i plan on using it for exchange with the OE code of write(parport,{16,12,"no"}) ?
I hope I got it right.
I never asked anyone to design or build the device the serial or parallel cable plugs into. What i asked for was how to get OE once again able to read and write pins which i can connect chips to.
And you were given answers, but the problem is, there are no easy answers. You can pick from a), b), c), or d) - or maybe you can offer a few more details and we might be able to come up with a fifth option? Unlikely but...
It's a shame that Euphoria/Phix must be tied to windoze for this particular user to be useful, since Linux in particular makes it really easy to directly access physical memory like so:
mem = open("/dev/mem", "rw")
Great, how to i get the smoke detector and anemometer into memory?
Kat
For the sake of example, assuming that the computer is an older one with a PCI bus and you have PCI cards that hook into them and expose via hardware DMA.
Considering your expertise in hardware and tinkering - esp with getting connections to work with a C64 - I will presume that you know this step better than I, and what's needed here is just the (Eu) software piece.
The manufactor of the PCI cards should be able to tell you what address to use for DMA, but let's assume for this example it's 0x1304006c. And you need to read the first eight bytes from there.
include std/io.e mem = open("/dev/mem", "u") seek(mem, 319029356) sequence values = io:get_bytes(mem, 8)
And now to write a command down at 0x1704006d
seek(mem, 386138221) puts(mem, new_values)
