Shop OBEX P1 Docs P2 Docs Learn Events
I need a VB.net 2008 hero (bounty paid) — Parallax Forums

I need a VB.net 2008 hero (bounty paid)

Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
edited 2012-09-12 13:21 in General Discussion
I need a VB.net 2008 hero.

Recently, Dr_A was kind enough to share some Xmodem code (in VB.net 2008) here:
http://forums.parallax.com/showthread.php?141936-Message-for-OBC

I have spent a week+ doing battle (between running shipping for PP/GG, and doing my other job) trying to get this functioning as a stand-alone app. I simply don't have enough hours in the day to learn VB.net without spending the next few months, (it's on my list). I'd like to get this app created quicker. There are people here who speak Visual as a second language.

Here's what I need:

Turn this into a stand-alone, Windows app, with 4 buttons, baud (default 115200), and Comport adjustment box.

Button 1) Open Communication
Button 2) Close Communication
Button 3) Send file. (open file dialog allowing user to pick a file, upon clicking "OK" it starts Xmodem send
Button 4) Recieve a file (open a "Save as" file dialog asking for a name/locatin, upon clicking "OK" it starts Xmodem receive.

The program must be free to all, no strings attached. Program must work with Spin Xmodem code.

I'll send a Quickstart and "Servo & More" package to whoever can be the hero.

Thanks!
Jeff

Comments

  • blittledblittled Posts: 681
    edited 2012-08-31 12:32
    Does it need to be VB2008? I have VB2010 express. I can do it after the Labor Day weekend. I also can make it enumerate through all serial ports and create a list of only the com ports available on your computer. In fact I think I have some code already started that could be of use. I just have to convert it from C#
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-08-31 12:40
    It could probably be imported into VB2010 express without too much issue. (At least for someone who knows it. :) )

    Jeff
  • blittledblittled Posts: 681
    edited 2012-08-31 12:59
    Ok, I noticed on the thread you referred to has just code so it'll work with any version of VB.NET. It probably would be best to use as old a version as possible since using 2010 requires the .NET 4.0 CLR and some people may not or cannot update their Windows to it. I do have Visual Studio 2005 which has the 2.0 Version of CLR and will work for anyone with XP and up. I don't see any issues with adding it to VB 2005.

    Edit I forgot 2010 can create a project with any of the CLRs so I can set it for 2.0
  • blittledblittled Posts: 681
    edited 2012-09-03 07:04
    @OBC, I got some code done and ready for testing. Do you have code for the Propeller to run xmodem to test this with? I do have a mpc setup to run it if necessary. Also I looked through Dr Acula's code and noticed when you do a send file it opens a comm port sends the file and then closes the comm port. The receive file does the same. Because of this I do not think you need the Open Comm or Close Comm buttons since that is handled in the file transferring.

    Edit: I found xmodem.bin at PropellerPowered and I'll use that.
  • blittledblittled Posts: 681
    edited 2012-09-03 07:42
    Is there source code for xmodem.bin? That would greatly help in the debugging.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-09-03 09:04
    Sorry about that! Thought it was already posted in "Sources" -- It is now.

    https://www.dropbox.com/sh/qwhixzvtlrvp1u1/fmzOix84Wu/PropellerBASIC/Useful%20Binaries/sources

    Jeff
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-09-03 09:06
    The reasoning for the open/close buttons to be separated is that they have the tendency to reboot the Propeller.
    This may/may not be a good idea when someone is attempting to type the corresponding xmodem command on the BASIC side.

    Jeff
  • localrogerlocalroger Posts: 3,452
    edited 2012-09-06 07:39
    Here is a complete application with source, tested against HyperTerminal and Win 3.1 terminal. (Note that when receiving both of those start out by trying XModem CRC, before failing over to classic XModem, so it takes a few tries to start.)
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-09-06 10:12
    @blitted, localroger and I have talked off-thread about his release. We'd still like to see you cross the finish line on this.

    @localroger, Might be getting some garbage characters on the last packet. I sent the "readme.txt" file over as a test and got around 60+ of the same character on the tail I haven't identified yet.

    Jeff
  • blittledblittled Posts: 681
    edited 2012-09-06 10:34
    I will complete it. I basically took what routines I needed from Dr Acula's vb.net version and put them into a stand alone app with a little modification. It appears to run but the Xmodem.bin I used had always hung up on the SD Card test so I couldn't test it. I'll try it with the FSRW version of XModem and see what debugging I need. Hopefully I'll have something by the middle of next week.


    Edit: I am doing this in VS 2005 with the 2.0 Framework. I just found out that Mono supports VB.NET with the 2.0 framework so hopefully this can be ported to Mono for cross platform use.
  • localrogerlocalroger Posts: 3,452
    edited 2012-09-06 10:40
    If the extra characters are $1A then this is normal. XMODEM does not provide for transmitting the size of the file and so the last 128-byte packet is padded, generally with $1A which was "end of file" in CP/M and DOS text entry. On receive I strip these characters unless you uncheck the function in the File menu; this is a safe thing to do for text files but could cause a problem if a binary file legitimately ends with $1A.
  • localrogerlocalroger Posts: 3,452
    edited 2012-09-06 17:10
    Jeff, did you notice the throughput limitation and is it a problem? The standard VB timer can only be fired 17 times per second no matter what millisecond value you specify (harkens back to the original ca. 1982 IBM PC) so doing one 128-byte packet per tick limits you to about 2200 characters per second, making baud rates above 38400 a bit superfluous. I'm pretty sure there is an API call to create a timer driven by the sound card hardware for computers that have it (which is of course nearly all of them nowadays) that could improve this if it's important.

    I think it is very important for VB programs with a UI to drop out and let events settle, because DoEvents() does not actually do all the events that can be processed during a dropout. I personally get really annoyed when the controls freeze on an app. I noticed the bottleneck late in testing because I rarely use baud rates above 19200 in real work myself and did the early stuff at 9600 so I could bork the comms to test recovery.

    Anyway I could stand to figure out this fast timer thing and after a job I have to complete tomorrow I could spend a few more hours on it.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-09-06 17:27
    Yes, I did notice it last night when I was testing the new version of xmodem. 2200 cps is about max.

    My test was the transfer of a 7mb wav file to the SD card. Took about an hour. :)

    The throughput of the Xmodem really isn't an issue here as it is mostly used for moving files < 32k into the PMC project.

    Jeff
  • blittledblittled Posts: 681
    edited 2012-09-06 19:02
    Success!! I got the file read and file write working with the VB.net code. With sending the file to the PMC I also get the padded 1A characters as expected. With Local Roger's permission I want to look at his code and see how he removes this padding and do likewise. I'll then clean things up and make an install package then post both the source and install programs for review.
  • RoadsterRoadster Posts: 209
    edited 2012-09-06 19:45
    I don't know how I missed this thread, I got code somewhere for doing this that I wrote in C#, but it looks like you guys have this under control. If I remember correctly I used zmodom, where the first 2 bytes sent were the file size too stop the padding at the end of the file.
  • localrogerlocalroger Posts: 3,452
    edited 2012-09-07 05:49
    blitted, feel free to lift any parts of my code. I intended the whole thing as a demonstration project. The $1A-stripping code should transfer to .NET with little or no modification.
  • blittledblittled Posts: 681
    edited 2012-09-07 10:49
    Thanks, localroger. My mind is in overdrive on this project. I'm debating on creating a file management system with a XML based database. This will enable the user to see the last 10 file names he transmitted or received and also a window that permits a user to select from a list of favorite files. You just click on the list to initiate the transfer. Is this useful or am I making this too complicated? :)
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-09-07 14:23
    @blittled

    Love the idea personally..

    Jeff
  • blittledblittled Posts: 681
    edited 2012-09-07 20:15
    I got the most recent sent files and received files working. It will remember the last 10 files for both modes.
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-09-07 20:56
    @blittled. I've been quietly waiting for you to open an official thread on this on Propellerpowered.com :)

    Sounds like you got it!

    Jeff
  • blittledblittled Posts: 681
    edited 2012-09-08 12:43
  • Oldbitcollector (Jeff)Oldbitcollector (Jeff) Posts: 8,091
    edited 2012-09-11 13:37
    @blitted came through with both a Windows Xmodem tool and fixed an error in Xmodem.spin that caused it to lock up.

    Looking forward to those automation features I requested in the thread. <hint.. hint.. smirk> :)

    Localroger and I both agreed off thread that the bounty went to you when you crossed the finish line.

    Debt paid in full today. Look for some goodies in your mailbox on Thursday.

    Jeff


    Jeff
  • blittledblittled Posts: 681
    edited 2012-09-12 09:32
    Thank you Jeff and LocalRoger! I see the hint Jeff :). I am thinking of an idea that hopefully isn't throwing the baby out with the bathwater. I feel the XModem protocol is somewhat limiting and I have an idea of a protocol that may be much more flexible, robust and will handle automation and batch transfers . I'll pm you my idea as soon as I write something up.
  • localrogerlocalroger Posts: 3,452
    edited 2012-09-12 13:21
    blittled, if you want to try something fancier you should look up the Ymodem and Zmodem protocols, which provide for better error correction, specifying the file length, and including the file name. Keeping to an existing standard would have the advantage of working with standard terminal programs, as the Xmodem tools we made here do. For propeller work, where we're always butting our heads against 32K, Xmodem has the advantage of being implementable with a very small amount of code.
Sign In or Register to comment.