Parallax Forums

Parallax Forums > Public Forums > Propeller Chip > Mac/Linux/Windows IDE - Ver 0.18.4 - The "Who'll stop the rain?" release

Forum Quick Jump

1111 posts in this thread.
Viewing Page :

[ << Previous Thread | Next Thread >> ] | Show Newest Post First ]

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/17/2009 9:12 PM (GMT -8)

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 :)

lt's not particularly silly, is it?

Peter Jakacki
thinker tinker

Date Joined Sep 2006
Total Posts : 1020

Posted 10/18/2009 2:58 PM (GMT -8)

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*

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/18/2009 5:16 PM (GMT -8)

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?

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/19/2009 5:35 AM (GMT -8)

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?

Peter Jakacki
thinker tinker

Date Joined Sep 2006
Total Posts : 1020

Posted 10/19/2009 5:39 AM (GMT -8)

So it should

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*

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/19/2009 5:55 AM (GMT -8)

Peter Jakacki said...
So it should

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?

CounterRotatingProps
FFT bells ring, Props a glistening ...

Date Joined Jul 2008
Total Posts : 1096

Posted 10/20/2009 7:43 AM (GMT -8)

Hi Brad,

knowning that you want to keep BST as OS neutral as possible, are the chances slim to none for you to consider adding a simple OLE automation interface to the Win side?

thanks for your time
- Howard

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/20/2009 4:05 PM (GMT -8)

CounterRotatingProps said...
Hi Brad,

knowning that you want to keep BST as OS neutral as possible, are the chances slim to none for you to consider adding a simple OLE automation interface to the Win side?

thanks for your time
- Howard

There may well be a platform neutral way of doing whatever it is you want however. What are you actually trying to achieve?

lt's not particularly silly, is it?

CounterRotatingProps
FFT bells ring, Props a glistening ...

Date Joined Jul 2008
Total Posts : 1096

Posted 10/21/2009 6:41 AM (GMT -8)

Brad - to keep from running parallel threads here, I'll respond over in the other editor thread. thx - H

Peter Jakacki
thinker tinker

Date Joined Sep 2006
Total Posts : 1020

Posted 10/21/2009 4:00 PM (GMT -8)

Brad,

Something that has been bothering me about this whole Ubuntu serial port thing. It seems if I open the BST terminal that it doesn't work. Sure, if I say reset I can see that the target has been reset so the port is connected ok but I do not receive any serial traffic from my menu system on the target. Now if I open GtkTERM I can communicate with it fine and I can also toggle the DTR and reset the Prop etc. So Ubuntu seems to be behaving fine, but not with BST. BST seems to behave fine with SimplyMEPIS and other platforms, but BST and Ubuntu don't seem to like each other.

*Peter*

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/21/2009 4:12 PM (GMT -8)

Peter Jakacki said...
but BST and Ubuntu don't seem to like each other.

Which is very odd as that is the operating system I develop it under.

Thanks for the tip of GTKTerm. I'll trace it and find out what its doing differently with the port.

I've just had a look at the Ubuntu patches for the serial port and they do not have the fix for the ftdi bug in the kernel. I'm unsure as to why GTKTerm works, and I'll investigate that, but I maintain the current Ubuntu beta kernels have a broken ftdi driver. I can verify that here on my own system, and I can verify it at the source level.

lt's not particularly silly, is it?

jazzed
Registered Member

Date Joined Jan 2008
Total Posts : 2348

Posted 10/21/2009 4:37 PM (GMT -8)

I've used BST with Hardy Heron (8.04) no problem.

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/24/2009 12:11 AM (GMT -8)

Peter Jakacki said...
Brad,

Something that has been bothering me about this whole Ubuntu serial port thing. It seems if I open the BST terminal that it doesn't work. Sure, if I say reset I can see that the target has been reset so the port is connected ok but I do not receive any serial traffic from my menu system on the target. Now if I open GtkTERM I can communicate with it fine and I can also toggle the DTR and reset the Prop etc. So Ubuntu seems to be behaving fine, but not with BST. BST seems to behave fine with SimplyMEPIS and other platforms, but BST and Ubuntu don't seem to like each other.

Ok, here's the deal. I've just spent about 4 hours working on this bug and I now know precisely what the issues are. As a side effect, I also found the bug heater was seeing with the kernel oops.

Peter, your bug is with the Ubuntu kernel. It was broken in the very early .31-rc process (months ago) and the fix only went into 2.6.31.5 on the 17th of Oct. The last Ubuntu kernel update was on the 16th, so the bug is still in the Ubuntu kernels. The bug does not manifest itself if you open the serial port with the O_NONBLOCK flag set (which is what minicom and gtkterm do). I, on the other hand, open the port without that flag. Ordinarily you can open the port without the O_NONBLOCK flag and then fcntl() the port to set the O_NONBLOCK flag afterwards. In this particular instance, this does not work around the bug. I found I could work around it by changing the serial code to open the port O_NONBLOCK, but that then has the knock on effect of me having to completely re-work some of the serial timing handling. I'd much rather just wait for the new kernels to flow upstream. The current broken behaviour is not consistent and occasionally it will let data though, which might explain why you occasionally saw it work.

Heater, your bug was present until about the 2.6.30 kernel and involves a bad refcount on the port. If the ftdi hardware goes away while it's still open, the kernel can oops. Prior to the latest -Pre of bst, if the port actually went away in that fashion (due to a kernel oops) bst would try and close the non-existent port and would crash. I've fixed it in bst, but if you are still using an older kernel and you have a flaky usb cable you might still see the odd kernel oops.

lt's not particularly silly, is it?

Andrey Demenev
Registered Member

Date Joined Oct 2009
Total Posts : 45

Posted 10/27/2009 3:18 AM (GMT -8)

Brad, thanks for this excellent tool! I use it under Debian 5 - works just fine. Actually, I am mostly interested in command-line tool, since I use VIM for all my code editing. I setup a makefile for project, and just call make from VIM. But there is a small problem that makes this style of work annoying - VIM cannot interpret the messages bstc writes to stdout. Even if the compilation is successfull, VIM interprets the messages as errors, resulting in opening a blank file. For example, seeing this:

Compiled for i386 Linux at 09:14:50 on 2009/05/08

VIM thinks there is an error in file named "Compiled for i386 Linux" :)

Is it possible to make bstc to output nothing on successfull compilation, and report warnings and errors in same format as GCC does? By default, this mode would be off, and turned on with a command-line switch.

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/27/2009 6:12 AM (GMT -8)

Andrey Demenev said...
Brad, thanks for this excellent tool! I use it under Debian 5 - works just fine. Actually, I am mostly interested in command-line tool, since I use VIM for all my code editing. I setup a makefile for project, and just call make from VIM. But there is a small problem that makes this style of work annoying - VIM cannot interpret the messages bstc writes to stdout. Even if the compilation is successfull, VIM interprets the messages as errors, resulting in opening a blank file. For example, seeing this:

Compiled for i386 Linux at 09:14:50 on 2009/05/08

VIM thinks there is an error in file named "Compiled for i386 Linux" :)

I use and love vim, but I'm a firm believer in "the right tool for the right job" and apparently vim is just too inflexible to interpret a sane output. I can't believe it relies on stdout to determine an error status. That's what result codes were made for. Maybe you should switch to Emacs ;)

If you send me a good example of precisely the format gcc outputs that vim is going to sanely interpret I'll try to get something working for you.

Even better, in addition to that, send me a test project with all the vim automation I can test with locally here and I'll make sure it works properly too :)

I use Ubuntu 8.04 on my desktop and laptop, and whatever the current Debian stable is on my servers. I do test all the tools on i386 and x86_64 Debian before I release them.
I used Debian exclusively on my desktops until Ubuntu 6.06 was released (I used to just use Windowmaker and heaps of automation) but after trying Ubuntu and having Gnome pretty much just work for me, I've kinda stuck with that on my daily drivers. My TV box still uses Debian and WindowMaker, but it PXE boots with an NFS root. Nice to keep it small and fast.

lt's not particularly silly, is it?

Andrey Demenev
Registered Member

Date Joined Oct 2009
Total Posts : 45

Posted 10/27/2009 9:12 AM (GMT -8)

BradC said...
apparently vim is just too inflexible to interpret a sane output

I would say vim is just way too flexible. I can modify options to handle pretty any output - but I am too lazy :)

this is what I think would be the error line that "out-of-the-box" vim would recognize:

somefile.spin:1234:11: Warning : JMP/DJNZ without #
^ ^ ^ ^
filename line col message

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/27/2009 7:17 PM (GMT -8)

Andrey Demenev said...

BradC said...
apparently vim is just too inflexible to interpret a sane output

I would say vim is just way too flexible. I can modify options to handle pretty any output - but I am too lazy :)

*boggle*.

Andrey Demenev said...

this is what I think would be the error line that "out-of-the-box" vim would recognize:

somefile.spin:1234:11: Warning : JMP/DJNZ without #
^ ^ ^ ^
filename line col message

I'll add it to my todo list.

lt's not particularly silly, is it?

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 10/30/2009 11:56 PM (GMT -8)

Just an update. Ubuntu 9.10 has been released and despite a bug being raised on this issue, the kernel still contains the buggy code.

Has anyone other than Peter seen this issue with Ubuntu? If not, I strongly recommend that those using bst on Ubuntu avoid upgrading to 9.10 until the bug has been resolved, or use a self-compiled kernel based on vanilla mainline.

If you always do what you always did, you always get what you always got.lt's not particularly silly, is it?

Bob Anderson
Registered Member

Date Joined Dec 2007
Total Posts : 103

Posted 11/1/2009 10:04 PM (GMT -8)

Brad:

On another thread, someone was trying out the AAC preprocesser (Augmented Assembly Code) and said that he would love to see it somehow useable from bst (and generate LMM code).

I responded that AAC is young yet (beta testing for only 2 days) and its value to the community is yet to be established.

I also said that it uses .Net Framework 2.0 which was not a happy thing for you.

Still, I thought I should ask whether you have any interest in pursuing some kind of connection. Maybe I need to rewrite it as a console app. I'm open to ideas. I won't be offended if you feel it's not worth the effort (although it would be nice if you qualified the rejection with a "not yet" qualifier).

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 11/1/2009 10:57 PM (GMT -8)

Bob Anderson said...
Brad:

On another thread, someone was trying out the AAC preprocesser (Augmented Assembly Code) and said that he would love to see it somehow useable from bst (and generate LMM code).

I responded that AAC is young yet (beta testing for only 2 days) and its value to the community is yet to be established.

I also said that it uses .Net Framework 2.0 which was not a happy thing for you.

Still, I thought I should ask whether you have any interest in pursuing some kind of connection. Maybe I need to rewrite it as a console app. I'm open to ideas. I won't be offended if you feel it's not worth the effort (although it would be nice if you qualified the rejection with a "not yet" qualifier).

Really, my only proviso is the code *must* be supported across all 4 platforms (I count OSX PPC & OSX Intel as separate platforms), and it must work without touching the disk. No input/output or temporary files. So the only real option is piped stdio.

If we can manage that, and we can thrash out a usable and extensible interface that allows proper error locations and does not leave the user guessing, then I'm happy to have a go at it.

If you always do what you always did, you always get what you always got.

heater
Registered Member

Date Joined Feb 2008
Total Posts : 2308

Posted 11/9/2009 11:54 PM (GMT -8)

Someone suggested that BST could highlight matching pairs of #ifdef / #endif when the cursor is on one of them

I'd like to suggest an alternative. I'm not normally a great user of IDE's, with the major exception of Prop work, but I've been using the QT Creator IDE that comes with the QT GUI tool kit a lot recently. Of course it has syntax highlighting for #ifdef etc but it also has this great feature that the actual code that is not used because it is excluded by a false #ifdef is greyed out. Rather like commented out code is "greened out". Or which ever colour.

Makes it dead obvious which bits of code you are actually about to compile, or not, at any moment.

For me, the past is not over yet.

Image Attachment :

Screenshot-mainwindow.cpp - FITS_Tool - Qt Creator.png 96KB (image/png)

This image has been viewed 25 time(s).

Cluso99
We live onboard

Date Joined Apr 2008
Total Posts : 2966

Posted 11/10/2009 12:21 AM (GMT -8)

Would be a really nice feature for those of us using the #ifdefs. Not sure how much work is involved though.

Links to other interesting threads:

Home of the MultiBladeProps: TriBlade, RamBlade, SixBlade, website

Single Board Computer: 3 Propeller ICs and a TriBladeProp board (ZiCog Z80 Emulator)

Prop Tools under Development or Completed (Index)

Emulators: CPUs Z80 etc; Micros Altair etc; Terminals VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)

Search the Propeller forums (uses advanced Google search)

My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm

Toby Seckshund
Registered Member

Date Joined Mar 2009
Total Posts : 801

Posted 11/10/2009 12:43 AM (GMT -8)

"Someone suggested that BST could highlight matching pairs of #ifdef / #endif when the cursor is on one of them"

That would be me, wishing for a perfect world. Heaters surgestion is so much better, but more work for Brad. I just wish I was anyway close of being capable to help.

Style and grace : Nil point

BradC
Gronk

Date Joined Jul 2007
Total Posts : 1996

Posted 11/10/2009 12:49 AM (GMT -8)

Cluso99 said...
Would be a really nice feature for those of us using the #ifdefs. Not sure how much work is involved though.

My initial thought is that is a pretty onerous task to throw at the highlighter as you need to teach it to parse code.

I'll put it on the todo list and stew on it for a while. You never know, I might come up with a way to do it fairly easily.

The highlighter has grown to be a bit of an embarrassment really. It's next on the list after the terminal for a revamp.

If you always do what you always did, you always get what you always got.

Cluso99
We live onboard

Date Joined Apr 2008
Total Posts : 2966

Posted 11/10/2009 1:09 AM (GMT -8)

Brad: Let me assure you your code definately is no embarassment.

1. It works and any bugs discovered are fixed so quickly.
2. It is cross-platform... a feat on it's own
3. It has an integrated IDE, editor, compiler, loader/programmer, and terminal.
4. It has extra features required for more complex solutions.

Sure, there are some things it does not do like I would like, but until I can think of constructive ways to make it better, it's my problem, not yours.

Links to other interesting threads:

Home of the MultiBladeProps: TriBlade, RamBlade, SixBlade, website

Single Board Computer: 3 Propeller ICs and a TriBladeProp board (ZiCog Z80 Emulator)

Prop Tools under Development or Completed (Index)

Emulators: CPUs Z80 etc; Micros Altair etc; Terminals VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)

Search the Propeller forums (uses advanced Google search)

My cruising website is: www.bluemagic.biz MultiBladeProp is: www.bluemagic.biz/cluso.htm

[ << Previous Thread | Next Thread >> ]

1111 posts in this thread.
Viewing Page :

Forum Information

Currently it is Monday, February 08, 2010 6:11 PM (GMT -8)
There are a total of 415,872 posts in 57,629 threads.
In the last 3 days there were 78 new threads and 858 reply posts. View Active Threads