SX-Key IDE Bug...
dkemppai
Posts: 315
Hi,
Keep getting this error, if I click on a Nop to place a break point...
See attached image...
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Keep getting this error, if I click on a Nop to place a break point...
See attached image...
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
581 x 242 - 22K
Comments
Like if you are single stepping ALL NOPs will be skipped.
If you have 10 NOPs in a row a single step in the IDE will skip all of them.
It has something to do with how the debugger in the SX works.
Bean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.iElectronicDesigns.com
·
BTW, you also can't set a breakpoint on the very last instruction line, like in
; some instructions
jmp Loop
END
a breakpoint on jmp Loop would not work. As a work-around, simply follow the last instruction with one more dummy instruction (but don't use a NOP), like
; some instructions
jmp Loop
mov w, #0
END
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
They're not?! Oh man, did I have it all wrong!
Just kidding.
I'll look into this issue and see what is going on. Just curious, what version of the IDE are you using?
Thanks,
PeterM
-Dan
P.S. This got me thinking, How is it I spend so much time debugging my software, and none bugging it?· [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Dark Energy! [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Shawn Lowe
Maybe I should have waited to do that......
Actually, you are "bugging" your software. Where do you think those bugs came from in the first place?
Thanks,
PeterM
I ran into an issue where my PC's hardware com port was popping SX keys, so I ended up switching to a USB comm port (FTDI Chipset, with Very good fast Sipex TTL to RS323 level converters)...·· ...long story.
Anyway, on the USB comm port,·I run into an issue when I'm·running a·program and·mash down on the "poll" button a bunch of times the Key software·stops. The display says "running" but it's evident that debugging has frozen. The only fix is to hit·the Reset button (the software one). Then start the program again. It's pretty reliable bug too...
I've never had this issue with the real serial port.
I'm running WinXP Pro SP2·all the updates, and FTDI's latest WHQL cert'd drivers.
Any Ideas?
Thanks!
Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
You get into the tricky zone with USB serial adapters. I say this only because the IDE simply uses Win32 API calls for talking to the serial port. In other words, it's not like the IDe has some magic up its sleeve where it knows it's talking to a USB serial port. It just does what it has always done and talks to the serial port via the API.
If you had no problems like this with a "real" serial port, then it's some issue related to the USB serial port. One solution that has often helped folks with serial problems is to make the character buffers smaller. On the USB ports, there tend to be more options to adjust.
I would try experimenting (one option at a time) and see if you have any positive change. When you do the experiments, be bold. If you have sliders, move one of them to the far extreme and try running the IDE. Make sure that you apply the change and possibly restart the IDE to make sure the change is recognized. If it's not better (or it's worse), move it to the other end. Lather, rinse, repeat on each parameter until you (presumably) get a more stable setup. If you get something that works, post it here to share the knowledge.
I wish I could help more, but with having you're exact setup here, it's impossible to now what will work.
Thanks,
PeterM
Since Parallax is developing a USB key, why don't you guys use the Direct drivers avaliable with the FTDI drivers. I know it would be a lot of work, but I'd think debugging throughput could be incresed dramatically. (With the direct drivers, you could access FTDI stack directly, and not have to go through all of the USB to serial gobbly gook...··· ...with a parallel USB chip, I've measured 750KBytes/Sec transfers sustained. (The other plus, would be the USB Key could pop up as a "Parallax USB SX-Key" when indows detects the hardware....
Plus, did you know that the direct drivers have function calls that mimic the win32 fucntion calls for dealing with the comm ports???· It would require a little reflashing of the 232R chip on the USB Key, but it's still early in the USB SX-Key game...
Anyway, now that I sort of have your attention. There are two things about the IDE gui (the SX-Key editor windows) that get me into trouble. If you could look at addressing these on the next version, it would be wonderful!
1) whenever I select text, and right click on the selected text, there is no popup for copy/paste. I have to first·move my cursor·on white·space next to the seleced text to get the popup. (This one bugs me quite often, as my laptop has a small keyboard, and I prefer to use the·external mouse·and associated movements·when possible)· The action is counterintutive compared to most windows programs...
2) when·using the find and replace function, mashing down on the find will locate an item being searched for. Presing the replace will replace that item. However, after a replace, the replace button will keep adding items to the end of the text being replaced if pressed again.·(Try it, do a find, then push replace several times)
That one would simply require a flag set by the find function, and checked/cleared by the replace function...
Thanks for your time!
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
some words on the USB key:
the bottleneck that limits debugging speed is the way how the SX20 on the SX-Key and the target SX communicate during a debugging session, and not the serial communication between the IDE and the SX-Key. The intra-SX communications can't simply made faster because the debugging process may not steal away too many clock cycles from the target SX, or the target's clock timing would be completely messed up. You may notice that even now, with the current timing between the target and the SX-Key, some jitter is caused while the device is debugged.
Therefore, switching to the FTDI direct drivers would not mean a speed increase. On the other hand, many users might have already installed the VCP driver for their SX-Blitz USB, or a Parallax USB/RS232 adapter, so the same driver can also be used for the SX-Key USB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I have experimental data that suggests that the USB to serial converter does slow things down significantly. Try run the debugger in full speed walk, with the SX-Key on a real serial port, then on a USB serial port. I've seen significant decreases in the responsiveness. Cranking the USB settings up a little helps, but it's never as fast as a real serial port. Maybe the new "R" version of the USB chip hardware fixes some of that, but you're still going through the windows USB gobbly gook, then the ftdi drivers, then the USB to serial driver.
If the USB to Serial isn't the bottle neck, why do I have so much trouble with the 'poll' button when using the usb to serial converter and not on the real hardware port?
As far as the drivers are concerned,·I·believe·the latest version of the VCP drivers include the Direct drivers.·A firmware setting on the FTDI chip sets the (The RS232RL, as I see the USB Key has), will·determine which drivers are loaded when windows enumerates the device.
Just imagine how many users wouldn't have to try to figure out which com port the Key is on? The SX-Key software could scan for USB hardware when it starts...
Dan
P.S. Don't get me wrong here, I'm not trying to badmouth the effort. It's just that I think things could be done better, with very·little effort spent in the process.··
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
thank you for sharing your experiences regarding the speed comparison between a real serial port and the USB to serial converter - this is interesting information.
From the SX-Key USB POV, the on-board SX20 is set for serial communication at 57.6 kBaud, so it actually does not "care" what device is on the other end as long as the baud rate is met. So, wether using a virtual or a direct serial driver must be handled by the IDE at first place. I know that the communication part in the IDE is a "tricky" one, so it is up to Peter. I'm sure, he can make an estimate on how to implement direct drivers in the IDE much better than I could.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G