hinv said...
Well, I tried it, but got frustrated with the dumb USB pseudo serial ports. I was able to have the prop login, and start up wish, but there was so much garbage characters going back and forth that I was unable to accomplish anything.
I will try a real serial port tomorrow night.
If you are connecting to a Linux or Mac system, a "real" serial port will behave *precisely* the same as a "dumb USB pseudo" serial port.
What did you have on the Linux end for the prop to log in to? If you are using Getty or similar, make sure the terminal type is being set correctly and you are not getting ANSI/VT100 codes shot down the line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
I've investigated only superficially Linux options.
Linux seems easier in that you can just open the serial port as a file with fopen and fread/fwrite to it.
However, this is hardly ideal because you need to poll the file for changes.·
I've been programming Qt's ver of C++·for work and you can set signals/slots to notify when things are changed.· I think the best way is to start a new thread then throw out a signal whenever the condition matches what you need or better yet throw an interrupt whenever a Rs232 character is received and write an ISR (how it's done in WinCE).
Under WinCE, the serialport component already takes care of all that under the C# .net serial component.· You just doubleclick on the DataReceived callback.
I played with the FriendlyARM device over the weekend and it's great. WinCE 6 is actually very stable and powerful platform.· The response is basically instant with the 400mhz ARM9.· All driver C source code is provided and you can just modify something if it doesn't work right.· Takes about 15 minutes to compile a WinCE image each time on my Quadcore 3ghz PC however.
I was able to get the Rs232 working and also the FTDI_ser.dll for RS232 over serial under WinCE and communicate with the propeller no problem at 115.2k.
I will try the FTDI_dxx.dll next which will be much better and allow for 8mbps+ with an FT245r or FT2232H.
fullspeceng said...
I've investigated only superficially Linux options.
Linux seems easier in that you can just open the serial port as a file with fopen and fread/fwrite to it.
However, this is hardly ideal because you need to poll the file for changes.
I've been programming Qt's ver of C++ for work and you can set signals/slots to notify when things are changed. I think the best way is to start a new thread then throw out a signal whenever the condition matches what you need or better yet throw an interrupt whenever a Rs232 character is received and write an ISR (how it's done in WinCE).
It's only "hardly ideal" if you are unfamiliar with it. In fact, once you get your head around it you find it's a pretty natural way to handle IO.
Just a hint here, but Qt polls for events and sets signals in its main event loop.
As you say, a separate thread is one way of doing it. Most sane software looks for IO events in its main event loop and just dispatches as required. Select() or Poll() is great for that.
If you want to use Interrupt based IO you can install a signal handler on SIGIO, but you really don't want to try and handle interrupts in userspace code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
While I'm sure it's "possible", "easier" is debatable.· I'd love to check out some real time linux options if you have the links.· MS WinCE charges $3 a device but free is always better.·· I think there's decent code in RTLinux with predictable ISR times but I have never tried it.· Not sure if it is easily compiled on an arm platform.
@Brad,
Thanks for the help. I think you are right. my inittab line reads:
S0:12345[noparse]:respawn:[/noparse]/sbin/agetty -L 9600 ttyUSB0 vt102
What would you suggest for the terminal type field. Can I just leave it off and just get ascii? What baud rate to I specify to get the fullest out the serial port?
@fullspeceng
You really should check out Tcl/Tk. I used to be able to put together simple applications for my traders (I used to work at the evil Goldman Sachs) in just a few hours. It is very handy, and is used in many applications.
A "dumb" terminal doesn't understand stuff like cursor movement commands so most Unix/Linux programs won't feel compelled to send them. I suspect that what you are seeing (other than the data you are trying to transfer) are various terminal codes, as BradC suggested.
As for baud rate, you can basically push it as high as the propeller will keep up. I've gone at 115.2k with FullDuplexSerial without a problem. You probably will want to keep it at 9600, though, until you get your communication channel mostly debugged to keep down on the number of things that could possibly be wrong, though...
One other possibility, BTW, is to write a program on the Linux side that opens /dev/ttyUSB0 directly instead of using the agetty with a login prompt. That way, you're sending data back and forth without the Propeller having to directly spawn Unix commands. To do that, however, you'll need to set the baud rate in your C (or Perl or TCL or...) code which is easy, but I don't remember off the top of my head how to do it...
Yep, that is a problem. Thanks. It now "logs in" quite reliably. I have a problem though. When the prop sends something to "wish" it is echoed back to the prop. Anybody know how to turn that off? I used to know how to do that with stty, but it has so much more options than I am used to under linux.
This catches my imagination.Have you installed any programs you've made using Visual Studio. Whats that like.
Couple more things that would help. Is that screen daylight readable, and do you think it would work in cold climates?
Would like to get one just for personal use as well, but would like to know if it could handle an industrial app!
I've been using the WinCE platform for a few weeks and it works pretty well and I like it a lot.·
Guis take me no more than 5-10mins each in C#.· I just drag and drop buttons/pictureboxes/etc.
Communication has been with RS232 so far and it works great but UART speed is limited to 115.2k.·
I have dove deeply into the advanced WinCE programming and have written my own device drivers for the GPIO ports and PWM on the friendlyarm.· It's pretty easy once you figure out how to Dllimport all the functions into C# from C++ and wrap them into a nice .NET api.· I would program just in C++ but the Win32API library is a bear.· I think it was mostly written in C before programmers transitioned in classes and abstraction so all the functions take about 10 parameters (half of which are not used).· I'm not sure why they didn't overload the functions in C++ so if all you wanted to do was OpenFile("myfile") you wouldn't need to specify the other 9 parameters.· I still program the kernel level drivers in C++ because there's not as much clutter but forget about generating GUI code.
Actually it's very similar to Linux in that way·because most device drivers·are registered as a "stream" file which can be opened with Win32 api CreateFile and read/written with ReadFile/WriteFile but it also has DeviceIOControl which you define in the drivers.
They wanted to use some version of real time Linux badly but couldn't compile it to work without rewritting·most of·the kernel drivers and I figure they probably knew what they were working.
Under WinCE, there's a standard example for handling an interrupt and writing an ISR.· The ISR creates a IST in a priority queue and is handled by the OS.· It makes a lot of sense and I·would have implemented it the same way.
The LCD is·pretty good quality.· Haven't tried reading it outdoors.· There's a 7" version available from the same company also.
You forget what's it is like to have a "real" computer and compiler.· The Samsung ARM9 processor runs at 400mhz and is very fast.· Real USB drivers to plug in your mouse and keyboard or USB flashkey makes life easier.· 64megs SDRAM and a fast filesystem opens a lot of possibilities.
Having access to a real Bitmap class and C++ STL for things like vector/map make my life a lot easier.
I was going back to the original question about implementing an interface with the propeller to the WinCE arm device.···Now that I have some experience writing device drivers under WinCE, I would think an 8 bit bus that drives an interrupt line on the Arm would be useful.· We would connect to the propeller using CreateFile("Prop1:"). Reading/Writing is done with ReadFile/WriteFile.· The same thing could be rewritten into a linux kernel driver.
Implementation on the propeller probably wouldn't be feasible as it runs at 33mhz like PCI.· Both SPI and I2C ports are supported under the WinCE and Linux platforms of the FriendlyArm and I think that would be an easy solution to write a fast SPI or I2C slave driver for the propeller (maybe one exists?).
I've been using the FT245R with the propeller on another project and it works well but adds cost and takes a lot of pins.
Anyway, life is good having full I/O access, touchscreen LCD and advanced compiler support in a small·$80 package.·
Just need to marry the Propeller with a faster bus than RS232.
FTDI supplies a nice example in C# that you can verify works right away.
I hooked up the propeller and am able to transmit around 1MB/sec just like the PC. Impressive and solves all my problems with communicating with WinCE machines. D2xx compiles on both the PC and WinCE platform so no code changes needed.
I loaded the drivers by pasting the FTDI info from the .reg and copying it into my project.reg and edited the project.bib file to copy over the FTDI drivers at bootup during my WinCE platform builder compile.
These SoC ARM chips are amazing. The OMAP and Samsung S3C2440 are very cheap. I saw somewhere the Samsung chip is around $8. This includes a real SDRAM driver, USB phy, LCD controller, touch screen controller and more all on a chip.
Mini2440 +3.5" LCD is 109.95 with free shipping in the US at www.andahammer.com, the US distributor listed on the FriendlyARM web site.
Now the basic unit has 128M NAND 64M RAM, options for 256M NAND and 1G NAND. I think it tops out at about $125 for the 1Gig version. 7" 800x480 LCD and TP systems are about $185. All are 405MHz with 100 MHz RAM bus. Aside from the Linux and CE6 BSP, they also come with uC-OS/II for hard real-time and there is a GREAT book for that OS. I'm using a mini2440 with 3.5 as a hub for data collection from a bunch of ARM7 based Coridium boards that fit the Arduino Pro shield boards from Sparkfun for $29 each. That's 60MHz of 32 bit ARM7 for $29! I must be getting old because that impresses the hell out of me.
Someone brought up doing the same with the Propeller products and it looks very attractive. [noparse][[/noparse]BTW, for those who don't know, ARM7 is Princetion Architecture - instructions and data share memory, and ARM9 is Harvard -- separate memory like a DSP and most are SOC with memory manager and a major leap in complexity over ARM7.]
My app is a complicated ballistics test setup, but the Propeller possibility is a massive data collection net of temperature and humidity for a researcher who wants to run a dozen strings of devices up the jungle canopy with sensors about a foot apart. We can find the ideal layer for Tarzan's tree house.
Note: There are eBay "cut&paste" sellers who have somehow laid their hands on quantities of Mini2440. A lot have a spec that says 64M NAND and some have a software spec that lists three GNU C compilers for generating the systems and Linux pre 2.6.29. These are Specs from a year ago. What they actually have is anybodies guess. The manufacturer no longer makes the 64M NAND version and any that say the LCD is NEC are using specs from last July. Since then they have had LCDs from Toppoly.
Anyway, you can't beat the price/performance for anything with a display unless you hack NintendoDS (ARM7 and ARM9 + two displays and touch pad - but not as fast). Which reminds me, I have a device and tools for doing just that and want to sell them.
On ebay, I paid $85 + $20 shipping for mine. Came from China. About the same price for 1 unit but more than 1 unit then it's quite a bit of savings. Didn't have any problems.
The ARMmite doesn't seem to be anything special however. On the cheap you can get a Silabs Toolstick 8051CF340 runing at 48mhz for $10 with integrated USB assembled. For more processing power/ease of use, I would go with the Propeller or XMOS for the multicore capabilities.
There are some good eBay sellers. I have heard good things about Esky-sh out of Shanghai. There are some very odd things appearing on the Asian and Chinese commerce sites like people who are not distributors listing Mini2440 in quantity 500 with old specs. I think I'll query them and see what happens.
I'll admit I was intrigued by the ARMmite Pro and bought one. The compiled BASIC hooked me. I'm generally not a BASIC fan unless it is compiled instead of interpreted -- I use RealBASIC on a Mac to make apps that compile for Mac, Windows, and Linux simultaneously --, but also not crazy about C on little micros (though the compilers today do a great job). The BASIC is a breeze and on a 60 MHz ARM does better than 10 million lines of code a second. It couldn't be easier, and made the communication end of the data collection a trivial problem. It includes the usual C compiler as well.
I'll look at the Silabs, oops. 8051. Sorry, I'm allergic
Comments
If you are connecting to a Linux or Mac system, a "real" serial port will behave *precisely* the same as a "dumb USB pseudo" serial port.
What did you have on the Linux end for the prop to log in to? If you are using Getty or similar, make sure the terminal type is being set correctly and you are not getting ANSI/VT100 codes shot down the line.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
Linux seems easier in that you can just open the serial port as a file with fopen and fread/fwrite to it.
However, this is hardly ideal because you need to poll the file for changes.·
I've been programming Qt's ver of C++·for work and you can set signals/slots to notify when things are changed.· I think the best way is to start a new thread then throw out a signal whenever the condition matches what you need or better yet throw an interrupt whenever a Rs232 character is received and write an ISR (how it's done in WinCE).
Under WinCE, the serialport component already takes care of all that under the C# .net serial component.· You just doubleclick on the DataReceived callback.
I played with the FriendlyARM device over the weekend and it's great. WinCE 6 is actually very stable and powerful platform.· The response is basically instant with the 400mhz ARM9.· All driver C source code is provided and you can just modify something if it doesn't work right.· Takes about 15 minutes to compile a WinCE image each time on my Quadcore 3ghz PC however.
I was able to get the Rs232 working and also the FTDI_ser.dll for RS232 over serial under WinCE and communicate with the propeller no problem at 115.2k.
I will try the FTDI_dxx.dll next which will be much better and allow for 8mbps+ with an FT245r or FT2232H.
·
It's only "hardly ideal" if you are unfamiliar with it. In fact, once you get your head around it you find it's a pretty natural way to handle IO.
Just a hint here, but Qt polls for events and sets signals in its main event loop.
As you say, a separate thread is one way of doing it. Most sane software looks for IO events in its main event loop and just dispatches as required. Select() or Poll() is great for that.
If you want to use Interrupt based IO you can install a signal handler on SIGIO, but you really don't want to try and handle interrupts in userspace code.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
WinCE handles it for you·in an easy to use callback.· http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/WCE032_WH06.ppt·suggests 3.3us average ISR starts with the 200mhz arm and I would suspect better performance on the 400mhz arm.
Thanks for the help. I think you are right. my inittab line reads:
S0:12345[noparse]:respawn:[/noparse]/sbin/agetty -L 9600 ttyUSB0 vt102
What would you suggest for the terminal type field. Can I just leave it off and just get ascii? What baud rate to I specify to get the fullest out the serial port?
@fullspeceng
You really should check out Tcl/Tk. I used to be able to put together simple applications for my traders (I used to work at the evil Goldman Sachs) in just a few hours. It is very handy, and is used in many applications.
A "dumb" terminal doesn't understand stuff like cursor movement commands so most Unix/Linux programs won't feel compelled to send them. I suspect that what you are seeing (other than the data you are trying to transfer) are various terminal codes, as BradC suggested.
As for baud rate, you can basically push it as high as the propeller will keep up. I've gone at 115.2k with FullDuplexSerial without a problem. You probably will want to keep it at 9600, though, until you get your communication channel mostly debugged to keep down on the number of things that could possibly be wrong, though...
One other possibility, BTW, is to write a program on the Linux side that opens /dev/ttyUSB0 directly instead of using the agetty with a login prompt. That way, you're sending data back and forth without the Propeller having to directly spawn Unix commands. To do that, however, you'll need to set the baud rate in your C (or Perl or TCL or...) code which is easy, but I don't remember off the top of my head how to do it...
Yep, that is a problem. Thanks. It now "logs in" quite reliably. I have a problem though. When the prop sends something to "wish" it is echoed back to the prop. Anybody know how to turn that off? I used to know how to do that with stty, but it has so much more options than I am used to under linux.
Thanks,
Doug
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Life may be "too short", but it's the longest thing we ever do.
This catches my imagination.Have you installed any programs you've made using Visual Studio. Whats that like.
Couple more things that would help. Is that screen daylight readable, and do you think it would work in cold climates?
Would like to get one just for personal use as well, but would like to know if it could handle an industrial app!
Guis take me no more than 5-10mins each in C#.· I just drag and drop buttons/pictureboxes/etc.
Communication has been with RS232 so far and it works great but UART speed is limited to 115.2k.·
I have dove deeply into the advanced WinCE programming and have written my own device drivers for the GPIO ports and PWM on the friendlyarm.· It's pretty easy once you figure out how to Dllimport all the functions into C# from C++ and wrap them into a nice .NET api.· I would program just in C++ but the Win32API library is a bear.· I think it was mostly written in C before programmers transitioned in classes and abstraction so all the functions take about 10 parameters (half of which are not used).· I'm not sure why they didn't overload the functions in C++ so if all you wanted to do was OpenFile("myfile") you wouldn't need to specify the other 9 parameters.· I still program the kernel level drivers in C++ because there's not as much clutter but forget about generating GUI code.
Actually it's very similar to Linux in that way·because most device drivers·are registered as a "stream" file which can be opened with Win32 api CreateFile and read/written with ReadFile/WriteFile but it also has DeviceIOControl which you define in the drivers.
I'm not that familiar with other·real time full OS but it appears WinCE is much better at realtime than most Linux varieties according to http://www.ece.northwestern.edu/EXTERNAL/realtime/
They wanted to use some version of real time Linux badly but couldn't compile it to work without rewritting·most of·the kernel drivers and I figure they probably knew what they were working.
Under WinCE, there's a standard example for handling an interrupt and writing an ISR.· The ISR creates a IST in a priority queue and is handled by the OS.· It makes a lot of sense and I·would have implemented it the same way.
The LCD is·pretty good quality.· Haven't tried reading it outdoors.· There's a 7" version available from the same company also.
You forget what's it is like to have a "real" computer and compiler.· The Samsung ARM9 processor runs at 400mhz and is very fast.· Real USB drivers to plug in your mouse and keyboard or USB flashkey makes life easier.· 64megs SDRAM and a fast filesystem opens a lot of possibilities.
Having access to a real Bitmap class and C++ STL for things like vector/map make my life a lot easier.
I was going back to the original question about implementing an interface with the propeller to the WinCE arm device.···Now that I have some experience writing device drivers under WinCE, I would think an 8 bit bus that drives an interrupt line on the Arm would be useful.· We would connect to the propeller using CreateFile("Prop1:"). Reading/Writing is done with ReadFile/WriteFile.· The same thing could be rewritten into a linux kernel driver.
I am leaning towards choosing a standardized bus like LPC (low pin count): http://en.wikipedia.org/wiki/Low_Pin_Count
Implementation on the propeller probably wouldn't be feasible as it runs at 33mhz like PCI.· Both SPI and I2C ports are supported under the WinCE and Linux platforms of the FriendlyArm and I think that would be an easy solution to write a fast SPI or I2C slave driver for the propeller (maybe one exists?).
I've been using the FT245R with the propeller on another project and it works well but adds cost and takes a lot of pins.
Anyway, life is good having full I/O access, touchscreen LCD and advanced compiler support in a small·$80 package.·
Just need to marry the Propeller with a faster bus than RS232.
Super easy, just copy the 3 files to \Windows\
FTDI supplies a nice example in C# that you can verify works right away.
I hooked up the propeller and am able to transmit around 1MB/sec just like the PC. Impressive and solves all my problems with communicating with WinCE machines. D2xx compiles on both the PC and WinCE platform so no code changes needed.
I loaded the drivers by pasting the FTDI info from the .reg and copying it into my project.reg and edited the project.bib file to copy over the FTDI drivers at bootup during my WinCE platform builder compile.
These SoC ARM chips are amazing. The OMAP and Samsung S3C2440 are very cheap. I saw somewhere the Samsung chip is around $8. This includes a real SDRAM driver, USB phy, LCD controller, touch screen controller and more all on a chip.
Now the basic unit has 128M NAND 64M RAM, options for 256M NAND and 1G NAND. I think it tops out at about $125 for the 1Gig version. 7" 800x480 LCD and TP systems are about $185. All are 405MHz with 100 MHz RAM bus. Aside from the Linux and CE6 BSP, they also come with uC-OS/II for hard real-time and there is a GREAT book for that OS. I'm using a mini2440 with 3.5 as a hub for data collection from a bunch of ARM7 based Coridium boards that fit the Arduino Pro shield boards from Sparkfun for $29 each. That's 60MHz of 32 bit ARM7 for $29! I must be getting old because that impresses the hell out of me.
Someone brought up doing the same with the Propeller products and it looks very attractive. [noparse][[/noparse]BTW, for those who don't know, ARM7 is Princetion Architecture - instructions and data share memory, and ARM9 is Harvard -- separate memory like a DSP and most are SOC with memory manager and a major leap in complexity over ARM7.]
My app is a complicated ballistics test setup, but the Propeller possibility is a massive data collection net of temperature and humidity for a researcher who wants to run a dozen strings of devices up the jungle canopy with sensors about a foot apart. We can find the ideal layer for Tarzan's tree house.
Note: There are eBay "cut&paste" sellers who have somehow laid their hands on quantities of Mini2440. A lot have a spec that says 64M NAND and some have a software spec that lists three GNU C compilers for generating the systems and Linux pre 2.6.29. These are Specs from a year ago. What they actually have is anybodies guess. The manufacturer no longer makes the 64M NAND version and any that say the LCD is NEC are using specs from last July. Since then they have had LCDs from Toppoly.
Anyway, you can't beat the price/performance for anything with a display unless you hack NintendoDS (ARM7 and ARM9 + two displays and touch pad - but not as fast). Which reminds me, I have a device and tools for doing just that and want to sell them.
The ARMmite doesn't seem to be anything special however. On the cheap you can get a Silabs Toolstick 8051CF340 runing at 48mhz for $10 with integrated USB assembled. For more processing power/ease of use, I would go with the Propeller or XMOS for the multicore capabilities.
I'll admit I was intrigued by the ARMmite Pro and bought one. The compiled BASIC hooked me. I'm generally not a BASIC fan unless it is compiled instead of interpreted -- I use RealBASIC on a Mac to make apps that compile for Mac, Windows, and Linux simultaneously --, but also not crazy about C on little micros (though the compilers today do a great job). The BASIC is a breeze and on a 60 MHz ARM does better than 10 million lines of code a second. It couldn't be easier, and made the communication end of the data collection a trivial problem. It includes the usual C compiler as well.
I'll look at the Silabs, oops. 8051. Sorry, I'm allergic