Not entirely, and reluctantly being dragged into the new century.
The new toy ( Asus Eee Box B202 ) needs XP because SATA drivers for 98 are apparently dog-slow, while work has meant I've had to use XP on a daily basis so have rewritten most of my apps to work with that. I still prefer 98 but XP does have its advantages - particularly on the USB and WiFi front - though some things are a step backwards from 98 IMO. Even with as much eye candy turned off it still has the feel of 'My First Computer'
BradC,
I have your California dreaming demo running with the USB_03.zip. I can't seem to get the USB_Serial_005.spin code to work though. I see USB_Serial_009.spin here but not some of the other dependencies. What would it take to make a USB serial port work? Thanks.
jazzed said...
BradC,
I have your California dreaming demo running with the USB_03.zip. I can't seem to get the USB_Serial_005.spin code to work though. I see USB_Serial_009.spin here but not some of the other dependencies. What would it take to make a USB serial port work? Thanks.
This is the latest serial code (when I say latest it's probably nearly a year old and has been 24/7 to my linux server)
heater said...
Brad, in that package you mention that 2 kernel mods are required for this to work under Linux.
What might they be?
On page 1 of this thread you will find a post from me with a usb patch attached. If you can't get that to apply, let me know what kernel version you are compiling for and I'll knock one up specifically.
Basically in drivers/usb/core/config.c you need to comment out the code that converts low speed bulk endpoints to interrupt endpoints.
In /drivers/usb/host/uhci-q.c there are two places that return -EINVAL if an attempt is made to queue a bulk URB with a low speed device that need to be commented out.
These days my server runs an nvidia chipset which uses the OHCI driver, so I only need to make the change to config.c, but the uhci changes don't hurt in any case.
I've had a crack at submitting a patch to the kernel that allows blatant spec violations, but it got rejected (for very good reason) with comments and 12 months later I've not got around to fixing it and resubmitting it. I'll get there one day. In the mean time, linux needs the patches and windows needs the .inf file. MacOS users are golden [noparse]:)[/noparse]
<edit> Oh my, the kernel has changed quite a bit since I did the original USB stuff. You'll need the attached patch also.
jazzed said...
HI Brad. Thanks for the updated .zip. What do I do about the CDC-ADM-HACK driver install? Where do I get it?
The avrcdc.inf file in the top post should work in theory. It matches based on VID/PID and I've not changed them. I've not actually plugged it into a windows box since hippy was helping me with it early on, but the CDC interface and descriptors have not changed such that it should make a difference.
So, the USB_Demo_Main_001.spin should work with some changes to start and including the right driver?
I see the device installed as COM9 and PST actually recognizes it, but I don't get characters echoing back.
Any ideas?
So, the USB_Demo_Main_001.spin should work with some changes to start and including the right driver?
I see the device installed as COM9 and PST actually recognizes it, but I don't get characters echoing back.
Any ideas?
Yes it should. No I have no idea. Having said that, I built an XP VM yesterday so I could test some other stuff, so if you give me the weekend I'll fire it up and make sure it works as it should on Windows.
Given Windows has detected the port you are 95% of the way there. That used to be the hard bit. The fact she's not running is probably something I've modified that works on Linux and OSX but causes Windows to quirk out. I'll get it sorted.
Oh, you are using PST. Does toggling the DTR help? From memory I've put DTR control in there and it won't send if the DTR is low.
jazzed said...
Yup, setting DTR fixed it [noparse]:)[/noparse] Is it possible to ease that requirement ?
Completely untested in all forms, but try changing the following
IF_NZ or _out, #2 ' We are off hook, enable data transmission
IF_Z andn _out, #2 ' Stop transmission of DATA
to
or _out, #2 ' We are off hook, enable data transmission
That _should_ make it completely ignore the DTR state, while still recording and acking it properly to keep Windows happy.
You _should_ be able to get nearly 8KB/s in theory. Over 200MB loopbacks I think I averaged about 6.5KB/s from memory. It's been a while since I tested it. Half duplex should be about 8KB (single 8 byte data packets, plus overhead at 1000 packets per second). This is the absolute best you can expect to get from low speed USB. I built a 57,600baud->USB converter for giggles and the USB kept up with the inbound serial stream with no problems.
Cool [noparse]:)[/noparse]
Looks like we need to transmit an end of line $a or $d for a usb.str(...) to work. That behavior is reasonable based on history.
A txflush would be useful in such cases. I'll play around with the other "serial" functions.
BradC said...
bst[noparse][[/noparse]cl] on Linux and Win32 have native support for loading and playing with the prop using a HID bootloader already
Brad what does this mean ... maybe I'm overlooking something obvious but whats an "HID" bootloader and what capabilities will it have?
HID means Human Interface Device. It's a specification that allows devices to be accessed using standard OS supplied methods and not need user installed drivers (think keyboards, mice, joysticks).
I still have that code in bst, but to be honest when it takes 7 seconds to load the prop over the FTDI interface, and about 45 over the USB interface I just stopped working on it.
I still have the bootloader code around here somewhere. It takes 2 cogs, 3 pins and communicates using the last 16 longs of ram. It allows you to play with the propeller while the bootloader is still active, provided you don't use the last 16 longs and only 6 cogs. I set it up so it can read/write ram/eeprom plus launch new binaries on the fly.. but then I must say I lost interest as it's still _slow_. Once I got the bit packed, double baud rate downloads working the serial interface is just so much faster.
Plus, I never got it working on OSX (not that I tried extremely hard).
If I ever get around to getting libusb to work properly on OSX, I might get back into it, but it's not high on my list.
@Cluso99, the Serial object as been doing serial between the prop and a linux PC 24/7 for about a year and a half now. So I guess the answer is yes.
OSX works out of the box, Win32 requires an .inf file (it's in this thread somewhere) and Linux requires a kernel patch (in this thread)
A generic text to keyboard object has been on my todo list for a while (as has a joystick emulator, touchscreen emulator and all manner of funky hid things). I guess I got caught up and side tracked elsewhere [noparse]:)[/noparse]
@TexFly, unzip them somewhere and load the California_Dreamin object in a tool, compile and load.
The CRC and low level objects are pulled in automatically.
I forget now, but it's either num/scroll/caps lock any or all that will cause it to spit out the lyrics. As soon as the prop starts though it should enumerate as a keyboard (evident using lsusb or similar).
The lowlevel object is the one than handles the usb communication while the other object sits above it at the application level. The low level cog is common to the serial and hid objects. The CRC was put into a separate object simply so I could use it commonly across all the objects and not worry about updates.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I got sidetracked from my SphinxOS & RamBlade with a thought about using Bluetooth. Don't ask how that happened because I don't know. I didn't even have a project in mind :-(
Anyway, I was thinking if it would be possible to use a prop to drive a USB Bluetooth adapter (just as a serial device) so we could communicate with other Bluetooth devices (firstup PC - dare I say XP or Vista). I don't care if it is non-compliant as long as it works. see http://forums.parallax.com/forums/default.aspx?f=25&m=429977
I note the circuit is a little more that I expected. I intended to use an existing PS2 socket but I would need to add a third prop pin via a resistor and maybe change the series 100R to 68R and remove the 2x10K pullups. Use a PS2 to USB adapter or replace the PS2 connector with a USB-A connector.
Reading your thread indiates that the adapters are using the PC for more work. Is that likely with the USB Bluetooth ??? Might this work ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I note the circuit is a little more that I expected. I intended to use an existing PS2 socket but I would need to add a third prop pin via a resistor and maybe change the series 100R to 68R and remove the 2x10K pullups. Use a PS2 to USB adapter or replace the PS2 connector with a USB-A connector.
Reading your thread indiates that the adapters are using the PC for more work. Is that likely with the USB Bluetooth ??? Might this work ???
Not very likely I'm afraid. For a USB host you'd need to run the Prop at precisely 96Mhz, and at best you'll get low_speed USB which is not allowed to have bulk endpoints. Have you looked at some of the source for a usb-hid bluetooth stack? It's enormous. Just the enumeration and configuration of the bluetooth dongle is a huge task.
Not sayin' it can't be done... but there are plenty of cheap bluetooth-serial modules available for *far* less effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I had incorrectly assumed the bluetooth code would be handled within the bluetooth device.[noparse][[/noparse]/quote
Oooooh no... Like Microsoft with their "WinPrinters" the whole thing surrounding USB originally was that it was (is) a completely dumb bus. The devices that connect to the end of it are also dumb (unlike firewire) and therefore it wins by default on the back of it being cheap. Slow & CPU intensive but cheap.
Most USB devices are nothing more than interfaces between the software and the minimal hardware required to perform the task. All the smarts lie in the driver.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC said...
Oooooh no... Like Microsoft with their "WinPrinters" the whole thing surrounding USB originally was that it was (is) a completely dumb bus. The devices that connect to the end of it are also dumb (unlike firewire) and therefore it wins by default on the back of it being cheap. Slow & CPU intensive but cheap.
Most USB devices are nothing more than interfaces between the software and the minimal hardware required to perform the task. All the smarts lie in the driver.
I didn't understand, so I fed your reply into the internet language translator and this is what it translated to...
Hardware is reduced. Software is moved from a controller to the PC as a driver. The driver is way more complex as it has to interface to bloatware, so becomes bloated itself. Cost is increased. Then the supplier has to have it approved and Bill receives a big chunk of $$ for this. Now the supplier is hooked Bill brings out a new version of the OS and the supplier has to jump through hoops to make his driver work again. For this luxury, Bill receives another big chunk of $$.
Meanwhile, the customer sees that the hardware is now tiny and thinks the supplier is ripping him off. Every time Bill releases a new version of the OS, the customer complains to the supplier that his driver is Smile.
Is this what you meant to say
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Oooooh no... Like Microsoft with their "WinPrinters" the whole thing surrounding USB originally was that it was (is) a completely dumb bus. The devices that connect to the end of it are also dumb (unlike firewire) and therefore it wins by default on the back of it being cheap. Slow & CPU intensive but cheap.
Most USB devices are nothing more than interfaces between the software and the minimal hardware required to perform the task. All the smarts lie in the driver.
I didn't understand, so I fed your reply into the internet language translator and this is what it translated to...
Hardware is reduced. Software is moved from a controller to the PC as a driver. The driver is way more complex as it has to interface to bloatware, so becomes bloated itself. Cost is increased. Then the supplier has to have it approved and Bill receives a big chunk of $$ for this. Now the supplier is hooked Bill brings out a new version of the OS and the supplier has to jump through hoops to make his driver work again. For this luxury, Bill receives another big chunk of $$.
Meanwhile, the customer sees that the hardware is now tiny and thinks the supplier is ripping him off. Every time Bill releases a new version of the OS, the customer complains to the supplier that his driver is Smile.
Is this what you meant to say
Actually, no it's not. What I meant to say was :
Hardware is cheap and cheery making all the intelligence reside in the driver. This has 2 "benefits" :
A) It slows the machine down requiring faster processors (Intel Wins - after all they played a large part in designing it) The manufacturers tie up all their intelligence in a windows-only binary driver and don't release the specs on how to actually use their product meaning you need to be using windows to use their product (Microsoft Wins).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Actually, I cannot wait until everything goes back onto the Internet servers and we just use a dumb terminal. No virus software to soak half the performance, etc, etc.
Then maybe our Prop or PropII will be the frontline processor of choice for the masses. Well, we can always hope anyway
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Actually, I cannot wait until everything goes back onto the Internet servers and we just use a dumb terminal. No virus software to soak half the performance, etc, etc.
I don't like that from a loss of control perspective more than anything. Thin clients were all well and good, but I like to have as low level control over my environment as possible.
Trust no-one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I just discovered this, I was planning in modifying an old joystick to act as a keyboard (to play team fortress 2!, as I am old-skool where all was done with 5 keys and not keys+mouse!)... I have to figure how to use this lowlevel object...
Ale: Did you get anywhere with this? I am currently trying. I have a simple demo program just echoing what it receives from the pc back to the pc, but no-go yet. I am on XP SP2. The .inf file has been loaded ok.
Comments
Not entirely, and reluctantly being dragged into the new century.
The new toy ( Asus Eee Box B202 ) needs XP because SATA drivers for 98 are apparently dog-slow, while work has meant I've had to use XP on a daily basis so have rewritten most of my apps to work with that. I still prefer 98 but XP does have its advantages - particularly on the USB and WiFi front - though some things are a step backwards from 98 IMO. Even with as much eye candy turned off it still has the feel of 'My First Computer'
I have your California dreaming demo running with the USB_03.zip. I can't seem to get the USB_Serial_005.spin code to work though. I see USB_Serial_009.spin here but not some of the other dependencies. What would it take to make a USB serial port work? Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
This is the latest serial code (when I say latest it's probably nearly a year old and has been 24/7 to my linux server)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
What might they be?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
On page 1 of this thread you will find a post from me with a usb patch attached. If you can't get that to apply, let me know what kernel version you are compiling for and I'll knock one up specifically.
Basically in drivers/usb/core/config.c you need to comment out the code that converts low speed bulk endpoints to interrupt endpoints.
In /drivers/usb/host/uhci-q.c there are two places that return -EINVAL if an attempt is made to queue a bulk URB with a low speed device that need to be commented out.
These days my server runs an nvidia chipset which uses the OHCI driver, so I only need to make the change to config.c, but the uhci changes don't hurt in any case.
I've had a crack at submitting a patch to the kernel that allows blatant spec violations, but it got rejected (for very good reason) with comments and 12 months later I've not got around to fixing it and resubmitting it. I'll get there one day. In the mean time, linux needs the patches and windows needs the .inf file. MacOS users are golden [noparse]:)[/noparse]
<edit> Oh my, the kernel has changed quite a bit since I did the original USB stuff. You'll need the attached patch also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Post Edited (BradC) : 7/17/2009 1:56:35 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
The avrcdc.inf file in the top post should work in theory. It matches based on VID/PID and I've not changed them. I've not actually plugged it into a windows box since hippy was helping me with it early on, but the CDC interface and descriptors have not changed such that it should make a difference.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
So, the USB_Demo_Main_001.spin should work with some changes to start and including the right driver?
I see the device installed as COM9 and PST actually recognizes it, but I don't get characters echoing back.
Any ideas?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Yes it should. No I have no idea. Having said that, I built an XP VM yesterday so I could test some other stuff, so if you give me the weekend I'll fire it up and make sure it works as it should on Windows.
Given Windows has detected the port you are 95% of the way there. That used to be the hard bit. The fact she's not running is probably something I've modified that works on Linux and OSX but causes Windows to quirk out. I'll get it sorted.
Oh, you are using PST. Does toggling the DTR help? From memory I've put DTR control in there and it won't send if the DTR is low.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Thanks Brad.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Completely untested in all forms, but try changing the following
IF_NZ or _out, #2 ' We are off hook, enable data transmission IF_Z andn _out, #2 ' Stop transmission of DATA to or _out, #2 ' We are off hook, enable data transmissionThat _should_ make it completely ignore the DTR state, while still recording and acking it properly to keep Windows happy.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Release the hounds!
Looks like we need to transmit an end of line $a or $d for a usb.str(...) to work. That behavior is reasonable based on history.
A txflush would be useful in such cases. I'll play around with the other "serial" functions.
BTW: Excellent Work!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Brad what does this mean ... maybe I'm overlooking something obvious but whats an "HID" bootloader and what capabilities will it have?
HID means Human Interface Device. It's a specification that allows devices to be accessed using standard OS supplied methods and not need user installed drivers (think keyboards, mice, joysticks).
I still have that code in bst, but to be honest when it takes 7 seconds to load the prop over the FTDI interface, and about 45 over the USB interface I just stopped working on it.
I still have the bootloader code around here somewhere. It takes 2 cogs, 3 pins and communicates using the last 16 longs of ram. It allows you to play with the propeller while the bootloader is still active, provided you don't use the last 16 longs and only 6 cogs. I set it up so it can read/write ram/eeprom plus launch new binaries on the fly.. but then I must say I lost interest as it's still _slow_. Once I got the bit packed, double baud rate downloads working the serial interface is just so much faster.
Plus, I never got it working on OSX (not that I tried extremely hard).
If I ever get around to getting libusb to work properly on OSX, I might get back into it, but it's not high on my list.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<This space for rent>
Would you please publish a quick tutorial to make the keyboard emulator working?
I mean: Propeller pins connection to computer (to emulate the keyboard) and steps to take with the software...
Thanks!
Post Edited (TexFly) : 2/14/2010 9:42:40 PM GMT
Change this line :
OK := ll.start(Pcrcmask, epb, 0,1,2)
To whatever you have D- / D+ / Enable connected to.
Load propeller and your machine should detect a USB keyboard connected. The caps lock key will make it type out the lyrics to California Dreaming.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I see three files inside the zip archive...what do they do exactly?
Do I need to load all of them?
Alex
IIRC you have played with this sort of USB thing for a while. The hardware is so simple
Are you able to do a simple serial (both directions) with it to the pc ??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
OSX works out of the box, Win32 requires an .inf file (it's in this thread somewhere) and Linux requires a kernel patch (in this thread)
A generic text to keyboard object has been on my todo list for a while (as has a joystick emulator, touchscreen emulator and all manner of funky hid things). I guess I got caught up and side tracked elsewhere [noparse]:)[/noparse]
@TexFly, unzip them somewhere and load the California_Dreamin object in a tool, compile and load.
The CRC and low level objects are pulled in automatically.
I forget now, but it's either num/scroll/caps lock any or all that will cause it to spit out the lyrics. As soon as the prop starts though it should enumerate as a keyboard (evident using lsusb or similar).
The lowlevel object is the one than handles the usb communication while the other object sits above it at the application level. The low level cog is common to the serial and hid objects. The CRC was put into a separate object simply so I could use it commonly across all the objects and not worry about updates.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I got sidetracked from my SphinxOS & RamBlade with a thought about using Bluetooth. Don't ask how that happened because I don't know. I didn't even have a project in mind :-(
Anyway, I was thinking if it would be possible to use a prop to drive a USB Bluetooth adapter (just as a serial device) so we could communicate with other Bluetooth devices (firstup PC - dare I say XP or Vista). I don't care if it is non-compliant as long as it works. see http://forums.parallax.com/forums/default.aspx?f=25&m=429977
I note the circuit is a little more that I expected. I intended to use an existing PS2 socket but I would need to add a third prop pin via a resistor and maybe change the series 100R to 68R and remove the 2x10K pullups. Use a PS2 to USB adapter or replace the PS2 connector with a USB-A connector.
Reading your thread indiates that the adapters are using the PC for more work. Is that likely with the USB Bluetooth ??? Might this work ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Not very likely I'm afraid. For a USB host you'd need to run the Prop at precisely 96Mhz, and at best you'll get low_speed USB which is not allowed to have bulk endpoints. Have you looked at some of the source for a usb-hid bluetooth stack? It's enormous. Just the enumeration and configuration of the bluetooth dongle is a huge task.
Not sayin' it can't be done... but there are plenty of cheap bluetooth-serial modules available for *far* less effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
I had incorrectly assumed the bluetooth code would be handled within the bluetooth device.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Hardware is reduced. Software is moved from a controller to the PC as a driver. The driver is way more complex as it has to interface to bloatware, so becomes bloated itself. Cost is increased. Then the supplier has to have it approved and Bill receives a big chunk of $$ for this. Now the supplier is hooked Bill brings out a new version of the OS and the supplier has to jump through hoops to make his driver work again. For this luxury, Bill receives another big chunk of $$.
Meanwhile, the customer sees that the hardware is now tiny and thinks the supplier is ripping him off. Every time Bill releases a new version of the OS, the customer complains to the supplier that his driver is Smile.
Is this what you meant to say
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Actually, no it's not. What I meant to say was :
Hardware is cheap and cheery making all the intelligence reside in the driver. This has 2 "benefits" :
A) It slows the machine down requiring faster processors (Intel Wins - after all they played a large part in designing it)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
Then maybe our Prop or PropII will be the frontline processor of choice for the masses.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
I don't like that from a loss of control perspective more than anything. Thin clients were all well and good, but I like to have as low level control over my environment as possible.
Trust no-one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
You only ever need two tools in life. If it moves and it shouldn't use Duct Tape. If it does not move and it should use WD40.
BradC: Are you still around???