ICCProp + FdSerial = I'm (no longer) lost *Solved*
Nick Mueller
Posts: 815
Hi!
Some might remember me, long time no see.
I had nothing to do for Propellers, so I just glanced in here from time to time to see whats new...
OK, the problem (and later something about my current project):
I downloaded ICCProp yesterday to see wether it will help me in my current project. It involves massive and fast serial communication (RS232) at 115kBaud. Under Spin, I modified the "FullDuplexSerial" to give me a 1024 Bytes long buffer (I **need** that). But with the ICCProp, I really don't know how to generate my own "FdSerial_Array" (the ASM-code).
What I'd like to know / have is the FullDuplexSerial.binary (I think) so I can make my modifications to it.
Any hints?
Now to the project:
I bought an other mill. A MAHO 700 C (weights above 3 tonnes
) with a broken CNC (Philips 432) for a ridiculous price. No need to repair the CNC, because it really is outdated. I'll rip it out and replace it with EMC2. Now, that mill has a lot of INs and OUTs. The time critical ones (glass scales, servos, etc.) are handled by a MESA-card. But for the rest of the many I/Os, I didn't find something suitable. So I decided to build my own extremely expandle IO. It communicates over serial with the PC. The protocol is ModBus. DriverCards for IN and OUT can be cascaded (tested so far are 4 cascaded cards per port, about 10 should work) and are optoisolated. With four ports and four cards per port and 16 bits per card, I could have 256 IOs. OK, more than I need.
There's nothing better to do the job (parallel tasks) than the Propeller. Cards are running, software is slowly working (considering I started 5 days ago with assembling the boards). Some parts are written in assembler.
Currently, I can handle commands within about 2ms, but I'd like to reduce that further.
I've attached some pictures ...
The first one is the CPU-board: One primitive serial for debugging/programming; one optoisolated serial; two PS-2-connectors, one connector for a TCP/IP module (like XPort); 4 ports for IO-cards, two config-jumpers.
The second one are four of OUT-boards cascaded. Each board has 16 OUTs for relays, works with 24V. Every connection for the relays has a status LED. This picture is a bit dark, but it shows the LEDs
Edit:
All PCBs have the same size and pattern for holes. So they can be sandwitched together. Makes a nice compact interface.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 6/25/2009 7:21:29 AM GMT
Some might remember me, long time no see.
I had nothing to do for Propellers, so I just glanced in here from time to time to see whats new...
OK, the problem (and later something about my current project):
I downloaded ICCProp yesterday to see wether it will help me in my current project. It involves massive and fast serial communication (RS232) at 115kBaud. Under Spin, I modified the "FullDuplexSerial" to give me a 1024 Bytes long buffer (I **need** that). But with the ICCProp, I really don't know how to generate my own "FdSerial_Array" (the ASM-code).
What I'd like to know / have is the FullDuplexSerial.binary (I think) so I can make my modifications to it.
Any hints?
Now to the project:
I bought an other mill. A MAHO 700 C (weights above 3 tonnes
) with a broken CNC (Philips 432) for a ridiculous price. No need to repair the CNC, because it really is outdated. I'll rip it out and replace it with EMC2. Now, that mill has a lot of INs and OUTs. The time critical ones (glass scales, servos, etc.) are handled by a MESA-card. But for the rest of the many I/Os, I didn't find something suitable. So I decided to build my own extremely expandle IO. It communicates over serial with the PC. The protocol is ModBus. DriverCards for IN and OUT can be cascaded (tested so far are 4 cascaded cards per port, about 10 should work) and are optoisolated. With four ports and four cards per port and 16 bits per card, I could have 256 IOs. OK, more than I need.There's nothing better to do the job (parallel tasks) than the Propeller. Cards are running, software is slowly working (considering I started 5 days ago with assembling the boards). Some parts are written in assembler.
Currently, I can handle commands within about 2ms, but I'd like to reduce that further.
I've attached some pictures ...
The first one is the CPU-board: One primitive serial for debugging/programming; one optoisolated serial; two PS-2-connectors, one connector for a TCP/IP module (like XPort); 4 ports for IO-cards, two config-jumpers.
The second one are four of OUT-boards cascaded. Each board has 16 OUTs for relays, works with 24V. Every connection for the relays has a status LED. This picture is a bit dark, but it shows the LEDs
Edit:
All PCBs have the same size and pattern for holes. So they can be sandwitched together. Makes a nice compact interface.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 6/25/2009 7:21:29 AM GMT
Comments
Fascinating project
Use the attached spinc.exe to convert the FullDuplexSerial.binary to an array.
Example: C:\spinc.exe FullDuplexSerial.binary > FullDuplexSerial_array.h
Comment in the example new file will say FullDuplexSerial_array.h and define
long FullDuplexSerial_array[noparse]/noparse = { ... };
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Saw that these files are from you, so I hoped for an answer by you.
What still is missing in my knowedge, is how to make that *.binary.
You'd be a great help for me, if you could point me in the right direction. Even better, if I could get that specific human-readable ASM, so that I can modify it for my needs.
I only need to make minor changes, especially changing the input- and output-buffer-size. This requires replacing a bunch of "magic numbers" with constants or registers.
Certainly all that is written somewhere, but I didn't find it. But still, a RTFM (or an example how I get from SPIN-ASM to C-ASM) is clearly welcome!
I have no problem passing the modifications back to the public or you.
TIA,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
You should have access to the Propelller Tool or the command line Propellent program. Either of these can create a binary. Use F8 for Propeller Tool and look for "Save Binary". On Propellent, use the /binary switch (use /help to get a *big* Propellent help window). You can specify a single "pre-build" command in ICCPROP that would automate all this and would be a good exercise for you. If you run into trouble, I'll help.
I recommend using Propeller Tool for writing native Propeller ASM programs. ICCPROP is fine for C, but is less attractive for writing native PASM code than the Propeller Tool ... it's a conventions thing for me - YMMV.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
<ashamed> OH! <ashamed/>
I didn't know about that. Or at least I forgot.
But now, the spinc.exe doesn't run on my PC. No it's Wintendo (XP). Says "Can't execute that program" or something like this in German. Downloaded it twice from different computers, unpacked with different programs.
:-(
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Thanks. Could you come here? With a pack of handkerchiefs?
Doesn't seem to be my day. Compiled it with open watcom to a DOS exec. But then, this only supports 8.3 names (and I don't find any switch). OK, renamed, but then spinc says "Bad spin object start in ...".
The ASM I compiled in Propeller Tool was just ASM with a PUB SomeName in front of it. Compiled well.
Tried your spinc.exe again after rebooting, but it doesn't start.
I know my problems are stupid.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I'm not sure I get your computer configuration, but you seem to have a somewhat working program.
If spinc.exe says anything, I have to assume it's running on your computer.
If you have 8.3 filename issues, perhaps you can rename your .binary to "code.bin" ...
The spinc.exe apparently found the file, and loaded the header, but the file doesn't look like a spin.binary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Might be a byte alignment / struct-packing problem? You know, *I* compiled the spinc and I don't know what settings you had, nor what compiler you used. Maybe a different size for int? C99 solved that problem.
Anyhow, I could play around if I only would know how to make a valid *.binary. How does the editable file in PropTool have to look like? Or if I could have an working complete example. I don't find any information at imagesoft. Nothing here in the forum.
Or if I would have a valid *.binary that I could x-check against my compiled version of spinc.exe.
So pleeeease make your information public.
A zipped complete set of *all* files of FdSerial would be of greatest help. And maybe you verify wether the spinc.exe you posted actually runs on your PC.
Sorry for my impatience.
TIA,
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Size of int is whatever the default architecture size is under GNU ...
I have no idea about Watcom C does, and I suppose you can say I have no plan to support that.
Somehow, I have to believe that since you use Watcom C, you have a good grasp of it. I could be wrong.
What is your PC configuration?
MS Visual C++ Express is free ... so is Cygwin GNU. You can even try Bloodshed C if you like.
I will zip you my project directory if you have MS Visual C++; otherwise, the C and H files should be sufficient.
I've told you everything I know about this. I am not hiding anything.
If you look at the datastructures in spinc.h, you will know how a valid spin binary looks.
If you post your binary, I'll look at it.
The spinc.exe I compile with MS Visual C++ works fine with a FullDuplexSerial.spin generated binary.
BTW: I don't work for ImageCraft. Any support you get from me is from the goodness of my heart.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
You mentioned above that "The ASM I compiled in Propeller Tool was just ASM with a PUB SomeName in front of it."
Can you just compile FullDuplexSerial.spin from the Propeller Tool installation and save the result from F8 as a binary?
Then try your compiled spinc.exe on the result and see if that does anything.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Well, there is no standard about the sizes as long as you don't use the length-save types derived from C99.
Anyhow, ints may be 2 or 4 bytes. In this case, they have to be 4 bytes. And then it works.
Using int32_t and such would be a much safer programming technique in C++/C99.
There's nothing tragic about my PC. Its a plain Win XP-Pro SP3 installation. But maybe your exe required something that wasn't on board. My EXE is less then 18kBytes in size.
> BTW: I don't work for ImageCraft. Any support you get from me is from the goodness of my heart.
I'm aware of that. At least that's what I suspected.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Yes, int32_t in this case would be better than int except that there is only one place in the program (clkfreq) where it is a critical factor. Everything else is short (2 bytes) and char (1 byte) in the datastructure. Good thing we don't have to worry about unicode text redifining char [noparse]:)[/noparse]
It's hard to tell from your last post if you have anything working. Please be kind enough to follow through and post back some results.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Well, that is OT.
But I need(ed) a decent compiler for DOS. And Open Watcom isn't just a 16 Bit compiler. But clearly the best C/C++-compiler alive for DOS. I tried DJGPP before and it simply was a pain. Decades ago, I used the Watcom C++ professionally and it was the one closest to the standard. And now its free.
There's still an issue with the output (as I just saw; at a first look in "printCarray" with the int-castings) but now I need to buy some SMD-parts ...
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
I think I answered that already where the problems are.
Back to the soldering iron and then to C ... I'll keep you informed.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
The last two lines of the HEXs are different.
Your FdSerial_Array.h reads:
0x00000032,
0000554
spinc compiled here makes the magic number 0 in replacement for the 554.
The extra 4 bytes 0x00000032 are missing completely. I did use the current version of FullDuplex serial.
So much to the "Get a grip, dude!"
Anyhow, it works.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
@echo /** @echo * @file %1.h - defines %1 array include file @echo * automatically generated with: "px %1 %2 %3 > %1.h" @echo * @param %1 is array[noparse][[/noparse]] name @echo * @param %2 is input file name @echo * @param %3 is beginning of file number of bytes to skip @echo */ @echo off @echo long %1[noparse][[/noparse]] = { @od -v -t x4z %2 -j %3 | sed "s/ /, 0x/g" | cut -d" " --fields 2,3,4,5,6 | sed "s/ 0x,//g" @echo }; @echo offIn any event to reduce frustration with PASM scraping, the one thing you should avoid is having a DAT section before the ORG of the cog code you wish to run.
I use a special FullDuplexSerial with spin all the time with "global dat buffers" for sharing among objects near the top of the file. This breaks any scraping technique discussed in this thread. Place your extra DAT sections at the end of your source, and things should work out fine.
Thanks for the update.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
ICCProp by ImageCraft!
In Spin, I had a decoding and handling time for every command ("Write Single Coil" in ModBus-speak to be precise) of 2ms. Then the receive buffer got saturated (I made an "send file" of the commands in RealTerm).
With ICCProp, I don't get a saturated serial-receive-buffer at all. I scoped (by toggling a LED) that the decoding time (from the last received bit to the change of the output-card) is only 280µs! Thats a factor of about 7 faster!
The time from command to command is now only 1,4ms. But only because RealTerm doesn't send commands faster. Theoretically, it would be 1,17ms.
So now, the 16 bytes serial receive buffer doesn't overflow anymore (currently with the short commands implemented so far). I didn't use my Big-Buffer-FullDuplexSerial until now (will do, no doubt; there is need). But my "OUTPortHandler" in ASM worked at the first try!
To mee it seems (currently) that it is a good idea to develop ASM-code within Propeller Tool and then switch to ICCProp. Maybe I can improve that workflow.
I'll buy the C-compiler. GOOOOOD JOB ImageCraft!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Second, THANK YOU Steve, for doing all these unpaid support work. Really appreciate it.
// richard
Not just kind words.
What I'd like to have (will make my own) is a stdint.h Especially with embedded programming, clear literal sizes (int16, uint32, etc) are better to work with. Also int_fast16_t and such would be *very* helpful.
Overall, the nearer you come to C99, the better.
A thing that I don't get working is ctrl-F9. It compiles and links, but can't upload because it searches for a *.bin, but there's only a *.binary. Didn't find the place to fix that. So I have to point and click "Make".
Initially, I was driven crazy by the handling of tabs in the editor, but then I found my favourite setting.
Disregarding these minor glitches, I'm happy that I finally get more speed, structure, robustness and control with C.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 6/25/2009 10:45:49 AM GMT
Nice to know I'm not the only one who finds the default tab behavior annoying [noparse]:)[/noparse] The other thing I truly dislike is the way SHIFT-CTRL-RightArrow tends to select way too many characters including the EOL up to the next symbol. Of course I'm a VI (gvim) user, so when I'm doing serious ASCII editing I go for that.
Nick is right about defining a stdint.h . It is far better to define one for the community than to have the hundreds of variants that are possible just pop up and cause a huge friggin' mess (the main reason I try to avoid such typedefs, but it is obviously an inevitable thing). I've always been torn about whether to use int or long for 32 bit types anyway in ICC, but they are apparently the same. I'm particularly fond of the linux typedef variety which at minimum defines the following (for a GNU on my 32 bit PC):
typedef signed char int8_t; typedef short int16_t; typedef long int32_t; typedef long long int64_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned long uint32_t; typedef unsigned long long uint64_t;
These things are so common that people tend to view the _t as superfluous, but it clearly communicates a typedef. After all FILE is a typedef (of a structure), but I didn't know that for years [noparse]:)[/noparse] I would tend to use something like FILE_ST (just my style). Speaking of FILE, I'm not at all a fan of typedef pointer variants since it is easy to lose the meaning glancing at sources. To me it is very clear that "FILE* fp" or "FILE* f" for that matter are pointers; "FILEP f" does not articulate the meaning very well.▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 6/25/2009 3:18:38 PM GMT
Yes, but what do I have a keyboard for?
Oh, one more thing: In Project -> Options -> Paths: If you browse the output-directory, the path is inserted with surrounding "". And then die dialog whines about them.
But again, nothing tragic!
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I've hit that "" problem also [noparse]:)[/noparse] There are other quirks I would like to see remedied like not being able to have two pre-build commands like "do this; do that" or running a pre-build script.
@Nick, Can you please post the source for spinc.[noparse][[/noparse]ch] that works for you back to this thread so that we can share it with others and avoid the same issues you found? Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
Propalyzer: Propeller PC Logic Analyzer
http://forums.parallax.com/showthread.php?p=788230
Post Edited (jazzed) : 6/30/2009 5:31:00 PM GMT