hotwolf / hsw12 Goto Github PK

I mentioned encountering difficulty getting a device working under Linux in #5:

I haven't gotten the board working with HSW12 on Linux yet, but I don't think it's an issue with HSW12 specifically. It looks as if it's immediately echoing back any prompts from D-Bug12 and gets stuck in a "Bad Command" loop, but the same happens when using cat < /dev/ttyUSB0. minicom works, though.

I have since found that once I used minicom with the device, other programs such as HSW12 and cat worked as expected. This was due to the terminal line settings being updated by minicom and persisting in other programs, as stty -F /dev/ttyUSB0 will output many changes in the settings compared to the default Linux settings or stty -F /dev/ttyUSB0 sane (neither of which were usable due to echoing, hardware flow control, etc.).

The default settings for stty in hsw12_pod.pm indeed make the device usable, but at the moment stty is not called until the baud is manually configured (which I had not been doing). But if the device is already be sending data to the computer, then it immediately gets stuck in an echo loop, sometimes hanging HSW12, and not allow the baud to be changed (and stty to turn off echoing).

So should HSW12 either be executing stty when connecting to the port, or should it also be setting the baud (in turn executing stty)? If the stty command needs to include setting the baud, maybe either a default baud is specified (e.g. 9600), or the existing baud is read using stty -F $device speed before executing stty again.

The terminal window appears to be adding the xscrollbar and removing it, preventing anything else from refreshing. I'll see if I can post a video of it.
Right now I'd think this is not an HSW12-specific bug: it might be a bug in the "'real' need to scroll" logic (the 'o' prefix used in the -scrollbars option in Perl/Tk's Scrolled constructor, so a potential workaround is to not use the 'o' prefix: cf. hsw12_gui:1512), but I need to confirm this on Linux to see if it isn't specific to XQuartz.

I downloaded your utility to program an MC9S12C32 for my microprocessor-based design course and was unable to upload the code over serial. I ran the program as root in Ubuntu 12.04LTS, can open my code and set the port up. I set the serial port to 9600 baud on ttyUSB0 (because that's where it likes to trend to when nothing else is connected). If I press the reset button when the micro-controller is set to LOAD the serial interface gets the 0xFC from it each and every time, but whenever I try to transmit to the micro-controller the Rx light of the programmer flashes once, but there is no response in the terminal. I looked in your documentation html file and how to use the serial is not explained and any commands are not documented as far as I can tell. If you could let me know how to transmit to the micro-controller or where the documentation is I would be most appreciative.

As I dig further into Perl programming advice, one consensus is that

use warnings;
use strict;

should always be present.

Since these are commented out in most of the files, I'm guessing HSW12 had tried using these at one point. But after attempting to enable these again I quickly found why they were probably left disabled.

Of the hundreds of 'errors' that appear if I try enabling them:

• Most are regarding the typeglobs used as constants, e.g.:

Variable "$parse_display_regs" is not imported at .\hsw12_pod.pm line 804.
...
Global symbol "$parse_display_regs" requires explicit package name (did you forget to declare "my $parse_display_regs"?) at .\hsw12_pod.pm line 804.

I think Readonly (which is readily available from package managers) should work, whereas use constant has known limitations.

• Similar errors regarding variables that aren't declared as my or are being declared twice; some of these I already committed fixes for. Some of these are typos/mispellings; these are understandable, and often there is correct spelling in use as well. But for hsw12_asm.pm (which I haven't spent as much time looking through before), I'm wondering if there's an issue where fixing those spelling issues might change the functionality.

Just writing this to document what I'm up to. I'm not stuck yet, but would be curious if this is something that's been looked into before or had encountered issues with.

Using OS X 10.9.5 "Mavericks". Downloaded HSW12-master folder, the HSW12.app launches (Gatekeeper does prompt on first launch), icon appears in Dock and Menu appears briefly--but no windows open and the app closes immediately.
Running HSW12.app/Contents/MacOS/HSW12 in terminal does not output anything.

I can still run the program using hsw12.pl, after having installed XQuartz and perl5 + p5-tk from macports.

I haven't used HSW12 much lately, but I did come across how there are ways to have improved look-and-feel for Tk (I believe it is the Tcl/Tk "Tile" feature specifically). I imagine that this would probably be worthwhile supporting e.g. for macOS so that a native look-and-feel is used and maybe even XQuartz is not needed--I'll upload a screenshot once I have my Mac running again if this is the case.

It seems the easiest way might be to try Tcl::pTk. With little effort I was able to use the "hijack" approach (i.e. launch using perl -MTcl::pTk::TkHijack hsw12.pl). I can at least get the GUI to appear after addressing a couple of minor issues:

• Tk::Exists has to be explicitly used as Tk::Exists rather than just Exists (please correct me if there is some other Exists besides Tk::Exists that's being used)

• There is an error when allowing autofocus;

bad option "focus": must be cget or configure at /usr/local/share/perl/5.24.1/Tcl/pTk/Widget.pm line 336.

If I comment out focusFollowsMouse it works fine, but I do not know what exactly causes the error. Personally I'm fine without the autofocus.

I'll note that it did take a few more steps to use Tcl::pTk than just regular Perl/Tk, since neither Linux distributions, macports, nor ActiveState PPM seem to provide it, although they do tend to provide the prerequisite modules prepackaged (e.g. Tix for Tcl; and Tcl, Class::ISA, and Sub::Name for Perl). I imagine whoever is still successfully using HSW12 is adventurous enough to go through these steps as well.

Also, I'd be inclined to have HSW12 use Tcl::pTk only if it is available and still work without it otherwise. Maybe some variation of the approach used here will suffice.

An idea I had is to be able create a "turbo" button macro to set a faster baud for the selected device. This should be possible by adding a [baud <bps>] macro, though I might not get a chance to implement it myself anytime soon.
Does this sound like a good feature to add?

I have also noticed that some multiple-line macros don't run correctly (at least on a Mac using an FTDI USB serial device): I'm not sure if I've described the issue comprehensively, e.g. when mixed with Macro Commands, but it seems that for the second Regular Output Text line only the first character is output, and the rest of the macro is not output. For example, the macro

mdw 1000
mdw 2000
mdw 3000

is output to the terminal as

>mdw 1000

1000  0D0A 2575 - 2025 7520 - 2575 2025 - 7520 2575    ..%u %u %u %u %u
>m

Hi Dirk,
I noticed in your recent updates that you added an opcode for CLRD. I personally find that a convenient and clever addition, since I often attempted to use a non-existent CLRD or CLD mnemonic in my assignments anyways.

I also noticed how it was implemented as a concatenation of CLRA and CLRB instructions, so it's really two instructions, but it's at least a byte of instruction memory less than the alternative of LDD #0, nor would the LDD #0 approach clear the carry bit as the CLRA and CLRB instructions do.

But the CLRA, CLRB approach appears to be non-atomic, where e.g. an interrupt occurs just between the two clear instructions, and the stacked copy of D needs to be read/updated from the ISR (no idea if this is a wise or common practice in embedded systems), but the read value is only half-initialized. While I'm not writing anything that might be affected by this, and we're probably free to leave it as-is, I'm curious what your thoughts were on implementing it this way; should hsw12-asm guarantee that any CLR opcode is atomic?

I try not to do this on purpose, but if a serial device gets unplugged for some reason while HSW12 was connected to it, e.g. /dev/ttyUSB0 disappears, the GUI will no longer respond and the perl process goes into runaway CPU usage, even if the device is plugged back in/becomes available; the program has to then be closed/killed. This happens on both OS X and Linux.
Preferably, HSW12 should warn that it can't access the device and not freeze, sort of like how minicom will say Cannot open /dev/ttyUSB0! and go back to normal operation if it's reconnected.
(HSW12 doesn't care if devices it's not connected to disappear, although the Port menu is generated when the program was launched and only shows devices that were present at the time.)

I encountered this issue while reading the HSW12ASM online manual recently. It occurs in Chrome and Safari but not in Firefox or Microsoft browsers. Disabling text-shadow seems to workaround it, so I think it is a performance issue with WebKit or the browsers rather than the CSS code, although I haven't looked for reports of an upstream issue. Disabling text-shadow also doesn't seem to affect the readability, so that may be an option.

I think it's neat how hsw12-asm can decide JSR or BSR using JOBSR, and I also like the feature for extended-indirect. Is it possible to allow combining the two, e.g. JOBSR [$ee88]? (At the moment, it just says invalid address mode for opcode "JOBSR"…)

There's a few things I notice about the Variables window:

• The list variables (i.e. which labels) is only updated automatically when loading a source file in a new/empty session or when opening another session, not when recompiling, opening another source file, or when opening a new session.
• Every label or #define is selected, rather than just those corresponding to certain pseudo-opcodes (e.g. ds, rmb, fcc), so it's a long list by default for any programs using e.g. Reg9s12.h; although I can see how it's necessary to include labels for other cases--given the nature of labels, it might be hard to tell exactly what is data (variable or array), instructions, or in cases such as self-modifying code, both.

I'm not sure how much of this is intentional; I have yet to look closely at how this is implemented in auto_select_variables(). So at a minimum this might be an undocumented feature.

Since one might edit the Variables window by hand, it's fine to leave it as it is where it doesn't reselect, but it may be useful to add a button that allows the user to invoke variable reselection.

The HSW12 GUI calls the stty program with the argument -f (lowercase). The Linux stty program requires a -F (uppercase).

Workaround:
Modify the stty-call in hsw12_gui.pm (see http://github.com/hotwolf/HSW12/blob/master/Perl/hsw12_pod.pm) line 476

I came across the Tk::IDElayout module, which shares its maintainer with the Tcl::pTk module. It lets UI panes be rearranged freely as tab frames a window, as well as undocked to become its own window. (see Screenshots.pdf)

This seems like a very interesting module since only much newer GUI widget toolkits tend to provide this feature (e.g. QDockWidget in Qt, used by IDEs such as Spyder and Octave). I would be interested in adapting hsw12_gui to use this module if available, that way a single window can be used. (That also works around the issue with the Tk 8-style menubar leaving extra space when in a window by itself.)

I'm used to writing strings in S12 assembly using

    FCC "Hello, World!"
    DB  NUL

where NUL EQU 0. However, many assemblers for other platforms have a mnemonic for NUL-terminated strings, e.g. .ASCIIZ. Is there an existing mnemonic for Motorola platforms, or what would be an appropriate mnemonic, e.g. FCZ (similar to FCC and FCS), and would this be a good thing to add to HSW12ASM?

Hi Dirk, could you help me with understanding the condition for this block added in 8d336c0?

I'm guessing $cpcode could be a misspelling of $opcode or $cpu. But psop_cpu is a subroutine, so I'm confused what the comparison is between.

I understand that the #ifcpu and #ifncpu are for including code based on whether a file contains pseudo opcode CPU for a specific processor. Though that seems tricky since the precompiler step now depends on pseudo opcodes not normally processed until the actual compile run later on. I'm guessing this block is for detecting the CPU opcode early, and assign the operand of the CPU pseudo opcode to a global variable.

Thanks

I just now noticed the project on SourceForge for HSW12ASM: https://sourceforge.net/projects/hsw12asm/

There are some outdated content and broken links that can be updated/cleaned up, would it be alright for me to be added as an admin? My SourceForge username is "chrstphrchvz".

Or should the project's presence on SourceForge be retired?