Woe is me. It started raining really hard around here [noparse]:([/noparse]
Just now I have been bringing up my new TriBlade with a nice new PropPlug. I can program the RAM and EPROM just fine. Then I can talk to my emulator through it just fine. But eventually BST pops up a dialog box announcing that something bad has happened to the serial port. Can't remember the exact message but I'm sure you know it. On clicking "OK" BST commits suicide.
Meanwhile a whole bunch off messages splatter all over my KDE desk top which turn out to be Linux kernel messages like so:
heater said...
Woe is me. It started raining really hard around here [noparse]:([/noparse]
Just now I have been bringing up my new TriBlade with a nice new PropPlug. I can program the RAM and EPROM just fine. Then I can talk to my emulator through it just fine. But eventually BST pops up a dialog box announcing that something bad has happened to the serial port. Can't remember the exact message but I'm sure you know it. On clicking "OK" BST commits suicide.
Cute. bst has detected the port has gone away (are there any usb remove messages prior to the crash? dmesg | less will allow you to read it pretty clearly).
When bst has tried to close the port and clean up after itself the kernel has paniced. That is a kernel bug in the tty layer and probably caused by the port going away uncleanly.
Can you give me more context from the kernel log? bst should not be crashing if the port goes away from under it like that, but given your kernel oopsed who knows what it fed bst before it tried to close the port.
<edit>
Further to that, yes if bst tries to close the port in the terminal and the port has thrown an exception it will crash (this should *never*) happen. Even then, it *should* pop up a general exception box though and allow you to continue. I can't reproduce this one as I need the kernel to commit suicide to try and see what is going on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
@BradC, I do not know if this is a bug, or what is going on. I just wired up a prop on the breadboard, using the prop plug, tested it with the Propeller
IDE, on a windows system, and every thing works fine, found the prop. Then I used the breadboard on one of my linux setups, and it cannot find
the prop. Using the prop plug, and attaching a Propeller Proto board, it finds that OK, same thing with the demo board. So, the problem I am having
is, BST cannot find the prop on my breadboard setup, but it finds it on everything else; the breadboard setup works because the Propeller IDE finds
the prop. I made sure that the prop plug was upside down on the breadboard setup, that would be the only obvious mistake that I can think of.
Rsadeika said...
@BradC, I do not know if this is a bug, or what is going on. I just wired up a prop on the breadboard, using the prop plug, tested it with the Propeller
IDE, on a windows system, and every thing works fine, found the prop. Then I used the breadboard on one of my linux setups, and it cannot find
the prop. Using the prop plug, and attaching a Propeller Proto board, it finds that OK, same thing with the demo board. So, the problem I am having
is, BST cannot find the prop on my breadboard setup, but it finds it on everything else; the breadboard setup works because the Propeller IDE finds
the prop. I made sure that the prop plug was upside down on the breadboard setup, that would be the only obvious mistake that I can think of.
Can I be a pain as ask you to try 0.16 or earlier?
Somewhere around 0.17-0.18 I made a significant change to the reset timing to match what I was seeing from Propeller Tool with a Scope.
If it works with the earlier version, I'll stretch the reset pulse a bit in the next release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
It is starting to look like a hardware problem, and not software. I ran linux BST 16 - 18.xx, on my known good Linux box, and everything worked.
It is my other box that seems to be giving me some problems. After installing win XP, and the propeller IDE, now the IDE cannot find a prop. A
VCP has been installed, but, the IDE cannot deal with it. Back too the drawing board ...
Brad, I have always had problems with BST detecting the Propeller as sometimes it's happy and other times it can't find the Prop.
Now this happens on different hardware etc but interestingly the Prop tool always detects it. The prop is always being reset so that's not a problem.
Putting aside timing I do notice that the Prop tool does an extra reset after the whole detection process though plus I also wonder if the PC's FIFO is being flushed in BST.
Peter Jakacki said...
Brad, I have always had problems with BST detecting the Propeller as sometimes it's happy and other times it can't find the Prop.
Now this happens on different hardware etc but interestingly the Prop tool always detects it. The prop is always being reset so that's not a problem.
Putting aside timing I do notice that the Prop tool does an extra reset after the whole detection process though plus I also wonder if the PC's FIFO is being flushed in BST.
It really does have me baffled. I've just done a test run of 3440 Propeller binaries with a 0 load/detect errors.
I get around 0.1% Errors on MacOS (I have scheduling issues) but with Linux it's just rock solid here.
I've put my pulses against those from the Propeller Tool on the CRO and they are as close as I can get to reproducing them.
I'm not giving up, but yeesh.. I have tried ~5k loads on every machine I have at my disposal... I've tried with USB proto boards, proto boards with prop plugs and demo boards..
I'm really running out of ideas..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I can demonstrate this (Peter's detection problem)·fairly consistently on my machine.· If you're interested, we can work out a way for you to use mine for debugging.·
I can demonstrate this (Peter's detection problem) fairly consistently on my machine. If you're interested, we can work out a way for you to use mine for debugging.
Greg
Sure, can you send me an email (proptools at fnarfbargle.com) or a pm with the following details ?
uname -a
cat /proc/cpuinfo
lspci
lsusb
cat /proc/timer_list <- this may not exist on your machine.
zcat /proc/config.gz | grep HZ <- this may not exist on your machine either.
What Parallax device do you have on the end of the cable? (Demo board, Prop Plug, USB Proto Board?)
This will help me narrow down what I might be dealing with for starters.
It'd be easier if one of you guys was in Perth [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
"Whatever port is in the port name box at the bottom is the one that is supposed to stick when you close the box"
Not sure if I'm understanding the problem here but the above just caught my eye. I have recently had a problem with this dialog that sounds similar.
I would have to play around with this some to try and reproduce it but the situation went something like this:
1) For a long time I was using a common or garden USB serial adapter running into the usual transistor circuit built on my home made Demo Board style board. This always came up as /dev/ttyUSB0 and worked very reliably.
2) I recently acquired a Prop Plug. This little bugger always comes up as a different number port /dev/ttyUSBx. Very annoying but liveable with. It programs just fine.
3) When I first tried to use the Prop Plug with BST I absolutely could not get my selection of it to stick when exiting the "Propeller Port Configuration" dialog box.
4) This was cured by editing the .bst.ini file and setting OverrideDevice. (Actually I may just have deleted that line, can't remember now).
5) Removing the Prop demo board from the old USB serial adapter and/or unplugging it from the PC may have helped. Again can't remember quite what I did with it.
Anyway since then the Prop Plug and that dialog have been fine. I see a lot of that dialog now as the port number keeps changing. Coupled with that is that the Prop Plug keeps getting lost by BST and it tells me bad things have happened. Perhaps also crashing, a lot kernel messages coming as well.
Ah...I cannot play with this to reproduce the problem as I pulled the Prop from the old board for use in TriBlade and binned the board. I would have to build another transistor programming circuit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
This may be overly simplistic, but I just got done trying to figure out why my uploads from the Parallax Propeller tool were inconsistent today. Turns out it was the cable. This particular one came with some cheap-o device, and it's very small gauge wire. Replaced with a larger one, and it works every single time.
Also, it sure seems to me like somebody could leave a setup running, make an SSH tunnel, and go from there.
potatohead said...
This may be overly simplistic, but I just got done trying to figure out why my uploads from the Parallax Propeller tool were inconsistent today. Turns out it was the cable. This particular one came with some cheap-o device, and it's very small gauge wire. Replaced with a larger one, and it works every single time.
I spent hours and hours trying to track down a communications bug which turned out to be the little retractable cable that came with my prop plugs. All three were seriously dodgy. Since I changed to different cables I've not had a problem.
potatohead said...
Also, it sure seems to me like somebody could leave a setup running, make an SSH tunnel, and go from there.
For remote debugging I need a shell and a way to upload small binaries. scp and ssh are my preferred methods. I have a world exposed machine with an openvpn server, so I can work with ssh, reverse ssh with a port mapped high my end to 22 your end, or an openvpn tunnel from your machine to mine. I can supply the openvpn certificate and client configuration if required. I can also supply a ssh public key to save you assigning a password.
vnc and rdesktop is unfortunately pretty useless as I need to be able to shunt binaries around and trace them as they work. I'd also prefer to have access to vim, strace and less but I'm not that picky [noparse]:)[/noparse]
Peter sent me some interesting CRO traces that showed some timing disparity I have vs the Propeller Tool (I'm, up to 10ms faster than the Prop Tool in talking to the Prop), but it's not preventing the Prop from replying. I'm just not seeing the reply or seeing something I'm not supposed to see. We'll get there in the end I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Brad: Ineresting. I found that my FPGA would not work with my camera cable but was fine with the cable supplied. I presumed there was something different with the pinout.
My camera cable works fine with the TriBlade. Never thought about it perhaps being a cheap cable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I believe there is a significant voltage drop with cheap cables.
Frequently, I make use of large USB disks. The power requirements on these are right at, or pushing the limit of USB 2.0. Long cables, or cheap cables with small gauge wire, fail consistently with these devices. With those, it's clearly power related as the disk fails to spin up. Might be crosstalk in the case of the prop. Don't know.
Another bug - I don't know if it has been reported before...
byte $0.$0
crashes the compiler
byte 0.0
does not
I found it accidentally when I was trying to figure out why the compiler started crashing, and it turned out I used a dot instead of a comma to separate two hex values!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95 www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Bill Henning said...
Another bug - I don't know if it has been reported before...
byte $0.$0
crashes the compiler
Thanks Bill. No it hasn't been reported previously. Nice find in fact!
I've been working with Greg Norton to solve his propeller detection problems, so I have my head in the code today and I'm working to get a pre-release out with the last 8 weeks or so of bug fixes rolled up. I'll make sure it's fixed before I do that.
Ta [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Bill Henning said...
Another bug - I don't know if it has been reported before...
byte $0.$0
crashes the compiler
Thanks Bill. No it hasn't been reported previously. Nice find in fact!
I've been working with Greg Norton to solve his propeller detection problems, so I have my head in the code today and I'm working to get a pre-release out with the last 8 weeks or so of bug fixes rolled up. I'll make sure it's fixed before I do that.
Ta [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95 www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I've uploaded some new snapshots of the ide and the compiler. I'm pretty sure I've snagged *all* the bugs, but I've made some fairly intrusive changes to the serial code to work around bugs spotted by Cluso99 and Greg Norton, so I'd like to see some wider testing before I get an official release out.
I'm pretty sure I've covered all the bug and missing bits requested since the last release. Ale I've added a *.* filter for you in the file list window. Sorry it's taken so long.
No changes to the serial terminal yet. I've completely re-written the base code to clean it up and I've completed the VT100 parser. I just have not started to test/debug it yet so it's a way off. I'd like to get it out before the next release but we'll see how that goes.
Big thanks to Peter Jakacki for many scope captures of load errors and Greg Norton for making a shell available to me to allow me to debug his most weird DTR related problem.
As for new features, the compiler now generates information messages for unused spin local variables.
It has been tested heavily on Linux, moderately on OSX 10.4(PPC) and 10.6(Intel) and not at all on Windows. I am getting a lot of windows downloads now, so I guess I'll hear screams if I broke something.
Really interested in feedback on prop load errors and serial glitches. I've made some fairly intrusive timing changes.
Users of slow Mac's might want to avoid the double baudrate downloads. I did 10,000 load tests on my 400Mhz PPC for each baud rate and found that double speed was just a little unreliable for large binaries. The OS was starving the bit packing code with scheduling latency and causing timeouts about 1.5% of the time. When moving back to standard speed downloads the failure rate dropped below 0.5%. Users of faster Macs have no need to use the slower speeds.
Jazzed, the 0.15.4-pre1 command line compiler hopefully fixes the problem you were seeing in the list file with the Result variable.
If you don't explicitly define a result variable you should get "Result", otherwise you should get the variable you declared.
Lots of little niggly bugs fixed in both codebases, but I'll drop a changelog when I get the real releases out.
I checked the download stats for the last releases and we are generally seeing between 150-200 Mac users, ~120 Linux users and ~50-70 windows users.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Great stuff. Working fine here with all my reported issues repaired.
Where do all the MAC users hang out? Must be in some parallel universe to mine. I only know one and he is a linguistics professor not much into engineering.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
heater said...
Great stuff. Working fine here with all my reported issues repaired.
Where do all the MAC users hang out? Must be in some parallel universe to mine. I only know one and he is a linguistics professor not much into engineering.
I have a couple of Macs myself, but unless I'm regression testing bst they all boot Linux.
There are a few Mac users around though, I even copped a link from one of their sites for a project they'd done with the Propeller. Ken also told me there was a Mac user inside Parallax. I have her E-mail address and she gave me some useful feedback that found its way into the 0.18 release.
Given I released bst around my mothers birthday last year (when I was home in Aus on holidays), it's around a year old now.
The bug reports have settled down a lot since 0.18, so I just base my usage estimations on how many downloads I get a month. If I want an updated count I can always release a new version [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Brad, just to let you know that BST (0.18.4) has been performing flawlessly in regards to the boot-loading and serial terminal when running in SimplyMEPIS 8. PuppyLinux works fine too but it's a bit of a cut-down version for me.
I have been using Ubuntu 9.04 and also 9.10 and even clean versions have a serial port timing bug. Maybe after 9.10 is released it will be fixed as there are other "funnies" with the serial port. I believe earlier Ubuntu versions work though. I will run those timing tests for you on both platforms and get back to you with the results.
Peter Jakacki said...
Brad, just to let you know that BST (0.18.4) has been performing flawlessly in regards to the boot-loading and serial terminal when running in SimplyMEPIS 8. PuppyLinux works fine too but it's a bit of a cut-down version for me.
I have been using Ubuntu 9.04 and also 9.10 and even clean versions have a serial port timing bug. Maybe after 9.10 is released it will be fixed as there are other "funnies" with the serial port. I believe earlier Ubuntu versions work though. I will run those timing tests for you on both platforms and get back to you with the results.
I'm just installing 9.10 into a spare partition here to try and test this, but I'd love an strace -x of a failing detection session with bstl if you have an opportunity.
If you scope the latest release you will find it resets the propeller twice in the first 20ms, then waits the requisite 100ms before it loads the Prop. This is to work around a very odd bug on Greg Norton's machine where the kernel appears to lose track of where the DTR is so requires an initial toggle to get things into a known state. I've done about 40,000 propeller detect/load cycles on OSX PPC/Intel and Linux to check that this has no impact on any other operation, but it no longer looks like the Propeller tool from a pure timing stand point.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Further to the Ubuntu 9.10 issue. The kernel Ubuntu is using (2.6.31) has a badly broken ftdi driver. There is a patch for it that I run on my vanilla kernels, but even at 2.6.31.4 it's still not in the stable kernel. The bug prevents anything that opens the port more than once after the device is inserted from receiving any data at all. So that explains it not working on Ubuntu 9.10. I'd still like to see a failed strace from one of your kernels that was unreliable as I'm running out of ideas, but I'd like to see what the problem actually is.
I would have thought Ubuntu would have added the patch for the ftdi drivers to their own kernels, but I guess no Ubuntu devs use ftdi based serial converters [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Brad, last night I did the latest update to Ubuntu 9.10 and the serial port is behaving now. There is the occasional glitch but it seems to work most of the time. Bearing in mind that 9.10 is an beta version then I am not surprised if there are some hiccups, I am using (not testing) a beta live in a production environment
Peter Jakacki said...
Brad, last night I did the latest update to Ubuntu 9.10 and the serial port is behaving now. There is the occasional glitch but it seems to work most of the time. Bearing in mind that 9.10 is an beta version then I am not surprised if there are some hiccups, I am using (not testing) a beta live in a production environment
That's really strange. I installed Ubuntu 9.10 from scratch yesterday and had it fail repeatedly. Perhaps my local (WA based) mirror is a couple of days behind.
In any case, I'm still disturbed by the "occasional glitch". I know it sounds picky, but unless I'm using my slow Mac here I get 100% reliability when detecting and downloading on all my other machines. I'll update my 9.10 install from the US repos today and see if I can reproduce the glitches.
Are you using the latest -pre1 code (which has some reset timing changes) ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Peter Jakacki said...
Brad, last night I did the latest update to Ubuntu 9.10 and the serial port is behaving now. There is the occasional glitch but it seems to work most of the time. Bearing in mind that 9.10 is an beta version then I am not surprised if there are some hiccups, I am using (not testing) a beta live in a production environment
I'm baffled. I'm running the absolute latest ubuntu 9.10 kernel and it's still terminally broken here with the ftdi device. Are you using an ftdi serial device? This is driving be batty!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Well I'm scratching my head too because it was working, I triple checked it, and then later on it was back to broken. But it was working, it certainly is puzzling.
Well I'm scratching my head too because it was working, I triple checked it, and then later on it was back to broken. But it was working, it certainly is puzzling.
With this kernel bug, it will work perfectly the first time you load the prop after the device is plugged in.
After the device is closed the first time it stops receiving data. So it will only detect/load the first time..
I must say I'm amazed that Ubuntu have let this bug hang about.. but then it is beta I guess. If the fix is not in 2.6.31.5 there'll be a lot of screaming..
The fix was sent to GregKH before 2.6.31.3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Comments
Just now I have been bringing up my new TriBlade with a nice new PropPlug. I can program the RAM and EPROM just fine. Then I can talk to my emulator through it just fine. But eventually BST pops up a dialog box announcing that something bad has happened to the serial port. Can't remember the exact message but I'm sure you know it. On clicking "OK" BST commits suicide.
Meanwhile a whole bunch off messages splatter all over my KDE desk top which turn out to be Linux kernel messages like so:
All this on Debian Lenny.
I'll try and get some more info on this as it happens.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Cute. bst has detected the port has gone away (are there any usb remove messages prior to the crash? dmesg | less will allow you to read it pretty clearly).
When bst has tried to close the port and clean up after itself the kernel has paniced. That is a kernel bug in the tty layer and probably caused by the port going away uncleanly.
Can you give me more context from the kernel log? bst should not be crashing if the port goes away from under it like that, but given your kernel oopsed who knows what it fed bst before it tried to close the port.
<edit>
Further to that, yes if bst tries to close the port in the terminal and the port has thrown an exception it will crash (this should *never*) happen. Even then, it *should* pop up a general exception box though and allow you to continue. I can't reproduce this one as I need the kernel to commit suicide to try and see what is going on.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Post Edited (BradC) : 9/22/2009 12:06:14 PM GMT
Some nice null pointer action in the kernel somewhere.
Never did see this with my old USB/serial adapter and home made transistor programming circuit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
IDE, on a windows system, and every thing works fine, found the prop. Then I used the breadboard on one of my linux setups, and it cannot find
the prop. Using the prop plug, and attaching a Propeller Proto board, it finds that OK, same thing with the demo board. So, the problem I am having
is, BST cannot find the prop on my breadboard setup, but it finds it on everything else; the breadboard setup works because the Propeller IDE finds
the prop. I made sure that the prop plug was upside down on the breadboard setup, that would be the only obvious mistake that I can think of.
Can I be a pain as ask you to try 0.16 or earlier?
Somewhere around 0.17-0.18 I made a significant change to the reset timing to match what I was seeing from Propeller Tool with a Scope.
If it works with the earlier version, I'll stretch the reset pulse a bit in the next release.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
It is my other box that seems to be giving me some problems. After installing win XP, and the propeller IDE, now the IDE cannot find a prop. A
VCP has been installed, but, the IDE cannot deal with it. Back too the drawing board ...
Now this happens on different hardware etc but interestingly the Prop tool always detects it. The prop is always being reset so that's not a problem.
Putting aside timing I do notice that the Prop tool does an extra reset after the whole detection process though plus I also wonder if the PC's FIFO is being flushed in BST.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
It really does have me baffled. I've just done a test run of 3440 Propeller binaries with a 0 load/detect errors.
I get around 0.1% Errors on MacOS (I have scheduling issues) but with Linux it's just rock solid here.
I've put my pulses against those from the Propeller Tool on the CRO and they are as close as I can get to reproducing them.
I'm not giving up, but yeesh.. I have tried ~5k loads on every machine I have at my disposal... I've tried with USB proto boards, proto boards with prop plugs and demo boards..
I'm really running out of ideas..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I can demonstrate this (Peter's detection problem)·fairly consistently on my machine.· If you're interested, we can work out a way for you to use mine for debugging.·
Greg
Sure, can you send me an email (proptools at fnarfbargle.com) or a pm with the following details ?
uname -a
cat /proc/cpuinfo
lspci
lsusb
cat /proc/timer_list <- this may not exist on your machine.
zcat /proc/config.gz | grep HZ <- this may not exist on your machine either.
What Parallax device do you have on the end of the cable? (Demo board, Prop Plug, USB Proto Board?)
This will help me narrow down what I might be dealing with for starters.
It'd be easier if one of you guys was in Perth [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Not sure if I'm understanding the problem here but the above just caught my eye. I have recently had a problem with this dialog that sounds similar.
I would have to play around with this some to try and reproduce it but the situation went something like this:
1) For a long time I was using a common or garden USB serial adapter running into the usual transistor circuit built on my home made Demo Board style board. This always came up as /dev/ttyUSB0 and worked very reliably.
2) I recently acquired a Prop Plug. This little bugger always comes up as a different number port /dev/ttyUSBx. Very annoying but liveable with. It programs just fine.
3) When I first tried to use the Prop Plug with BST I absolutely could not get my selection of it to stick when exiting the "Propeller Port Configuration" dialog box.
4) This was cured by editing the .bst.ini file and setting OverrideDevice. (Actually I may just have deleted that line, can't remember now).
5) Removing the Prop demo board from the old USB serial adapter and/or unplugging it from the PC may have helped. Again can't remember quite what I did with it.
Anyway since then the Prop Plug and that dialog have been fine. I see a lot of that dialog now as the port number keeps changing. Coupled with that is that the Prop Plug keeps getting lost by BST and it tells me bad things have happened. Perhaps also crashing, a lot kernel messages coming as well.
Ah...I cannot play with this to reproduce the problem as I pulled the Prop from the old board for use in TriBlade and binned the board. I would have to build another transistor programming circuit.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Also, it sure seems to me like somebody could leave a setup running, make an SSH tunnel, and go from there.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I spent hours and hours trying to track down a communications bug which turned out to be the little retractable cable that came with my prop plugs. All three were seriously dodgy. Since I changed to different cables I've not had a problem.
For remote debugging I need a shell and a way to upload small binaries. scp and ssh are my preferred methods. I have a world exposed machine with an openvpn server, so I can work with ssh, reverse ssh with a port mapped high my end to 22 your end, or an openvpn tunnel from your machine to mine. I can supply the openvpn certificate and client configuration if required. I can also supply a ssh public key to save you assigning a password.
vnc and rdesktop is unfortunately pretty useless as I need to be able to shunt binaries around and trace them as they work. I'd also prefer to have access to vim, strace and less but I'm not that picky [noparse]:)[/noparse]
Peter sent me some interesting CRO traces that showed some timing disparity I have vs the Propeller Tool (I'm, up to 10ms faster than the Prop Tool in talking to the Prop), but it's not preventing the Prop from replying. I'm just not seeing the reply or seeing something I'm not supposed to see. We'll get there in the end I guess.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
My camera cable works fine with the TriBlade. Never thought about it perhaps being a cheap cable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Frequently, I make use of large USB disks. The power requirements on these are right at, or pushing the limit of USB 2.0. Long cables, or cheap cables with small gauge wire, fail consistently with these devices. With those, it's clearly power related as the disk fails to spin up. Might be crosstalk in the case of the prop. Don't know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
byte $0.$0
crashes the compiler
byte 0.0
does not
I found it accidentally when I was trying to figure out why the compiler started crashing, and it turned out I used a dot instead of a comma to separate two hex values!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Thanks Bill. No it hasn't been reported previously. Nice find in fact!
I've been working with Greg Norton to solve his propeller detection problems, so I have my head in the code today and I'm working to get a pre-release out with the last 8 weeks or so of bug fixes rolled up. I'll make sure it's fixed before I do that.
Ta [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
I've uploaded some new snapshots of the ide and the compiler. I'm pretty sure I've snagged *all* the bugs, but I've made some fairly intrusive changes to the serial code to work around bugs spotted by Cluso99 and Greg Norton, so I'd like to see some wider testing before I get an official release out.
I'm pretty sure I've covered all the bug and missing bits requested since the last release. Ale I've added a *.* filter for you in the file list window. Sorry it's taken so long.
No changes to the serial terminal yet. I've completely re-written the base code to clean it up and I've completed the VT100 parser. I just have not started to test/debug it yet so it's a way off. I'd like to get it out before the next release but we'll see how that goes.
Big thanks to Peter Jakacki for many scope captures of load errors and Greg Norton for making a shell available to me to allow me to debug his most weird DTR related problem.
As for new features, the compiler now generates information messages for unused spin local variables.
It has been tested heavily on Linux, moderately on OSX 10.4(PPC) and 10.6(Intel) and not at all on Windows. I am getting a lot of windows downloads now, so I guess I'll hear screams if I broke something.
Really interested in feedback on prop load errors and serial glitches. I've made some fairly intrusive timing changes.
Users of slow Mac's might want to avoid the double baudrate downloads. I did 10,000 load tests on my 400Mhz PPC for each baud rate and found that double speed was just a little unreliable for large binaries. The OS was starving the bit packing code with scheduling latency and causing timeouts about 1.5% of the time. When moving back to standard speed downloads the failure rate dropped below 0.5%. Users of faster Macs have no need to use the slower speeds.
Jazzed, the 0.15.4-pre1 command line compiler hopefully fixes the problem you were seeing in the list file with the Result variable.
If you don't explicitly define a result variable you should get "Result", otherwise you should get the variable you declared.
Lots of little niggly bugs fixed in both codebases, but I'll drop a changelog when I get the real releases out.
I checked the download stats for the last releases and we are generally seeing between 150-200 Mac users, ~120 Linux users and ~50-70 windows users.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Where do all the MAC users hang out? Must be in some parallel universe to mine. I only know one and he is a linguistics professor not much into engineering.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have a couple of Macs myself, but unless I'm regression testing bst they all boot Linux.
There are a few Mac users around though, I even copped a link from one of their sites for a project they'd done with the Propeller. Ken also told me there was a Mac user inside Parallax. I have her E-mail address and she gave me some useful feedback that found its way into the 0.18 release.
Given I released bst around my mothers birthday last year (when I was home in Aus on holidays), it's around a year old now.
The bug reports have settled down a lot since 0.18, so I just base my usage estimations on how many downloads I get a month. If I want an updated count I can always release a new version [noparse];)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I have been using Ubuntu 9.04 and also 9.10 and even clean versions have a serial port timing bug. Maybe after 9.10 is released it will be fixed as there are other "funnies" with the serial port. I believe earlier Ubuntu versions work though. I will run those timing tests for you on both platforms and get back to you with the results.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
I'm just installing 9.10 into a spare partition here to try and test this, but I'd love an strace -x of a failing detection session with bstl if you have an opportunity.
If you scope the latest release you will find it resets the propeller twice in the first 20ms, then waits the requisite 100ms before it loads the Prop. This is to work around a very odd bug on Greg Norton's machine where the kernel appears to lose track of where the DTR is so requires an initial toggle to get things into a known state. I've done about 40,000 propeller detect/load cycles on OSX PPC/Intel and Linux to check that this has no impact on any other operation, but it no longer looks like the Propeller tool from a pure timing stand point.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I would have thought Ubuntu would have added the patch for the ftdi drivers to their own kernels, but I guess no Ubuntu devs use ftdi based serial converters [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
That's really strange. I installed Ubuntu 9.10 from scratch yesterday and had it fail repeatedly. Perhaps my local (WA based) mirror is a couple of days behind.
In any case, I'm still disturbed by the "occasional glitch". I know it sounds picky, but unless I'm using my slow Mac here I get 100% reliability when detecting and downloading on all my other machines. I'll update my 9.10 install from the US repos today and see if I can reproduce the glitches.
Are you using the latest -pre1 code (which has some reset timing changes) ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
I'm baffled. I'm running the absolute latest ubuntu 9.10 kernel and it's still terminally broken here with the ftdi device. Are you using an ftdi serial device? This is driving be batty!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Well I'm scratching my head too because it was working, I triple checked it, and then later on it was back to broken. But it was working, it certainly is puzzling.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
*Peter*
With this kernel bug, it will work perfectly the first time you load the prop after the device is plugged in.
After the device is closed the first time it stops receiving data. So it will only detect/load the first time..
I must say I'm amazed that Ubuntu have let this bug hang about.. but then it is beta I guess. If the fix is not in 2.6.31.5 there'll be a lot of screaming..
The fix was sent to GregKH before 2.6.31.3.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?