Jump to content
IGNORED

The Compact Computer 40 (CC40)


Recommended Posts

So I reflashed my arduino with the latest HEXTIr.hex using avrdude, and now I am unable to open files nor save, although I can still OLD files on the SD card.

I reverted back to my original file but the problem persisted. I checked the connection points on the shield and everything seems to be OK, but I'm suspecting my shield is acting up here.

Any pointers on debugging?

Link to comment
Share on other sites

I don't have many that are easy to try.  There's debug statements in the code, but you'd need to recompile. A logic analyzer might help as well, but most folks don't have one.  You might try grabbing older versions of the code and seeing if that does anything (if it's the shield, it won't, but it might not be the shield).

 

I'm trying to free up some time to get this back on the bench and debug (I was planning to debug the set device command initially), but it might be a week or so, as there's lot in my list to get done first.

Link to comment
Share on other sites

Just a quick update. I poked around the SD shield again testing the continuity of connections as well as logic signals and could not find any issues. So I put the drive back together again and it worked fine this time around, except for the SE DEV command which gives an IO ERROR 1, meaning that the command was not recognized as valid. This is using the latest HEXTIr.hex build. 

All other commands seem to work as they should (MD, DEL, CD etc...), so I think the SE DEV command is either buggy or there an implementation error somewhere.

If anyone here can double check this it would be great to make sure the issue is not on my end. Just run the following command:

OPEN #255,"20.SE DEV=21". If you do not get an error then try CLOSE #255 and you should get an expected error there since device 20 is now 21.

Link to comment
Share on other sites

I don't think open #255,"se dev=21" will work.  THere's no device number in the open statement.  Checking my manual, open needs to be :  open #<channel>, "<device_number>.<open parms>"

 

So, I think it's open #255,"20.se dev=21"

 

And then the close will fail, because device 20 is gone, but you need to do it to clean up the BASIC pointers.

 

Then, try to open #255,"20.b=9600" should succeed.

 

If the se dev=21 works, then the next step really should be to do open #255,"21.st", which is supposed to permanently store the new device number.

 

 

Link to comment
Share on other sites

So I started looking at the HEXOPS.cpp file and found the following definitions:

static const action_t cmds[] MEM_CLASS = {
                                        {EXEC_CMD_DEV,"de"},
                                        {EXEC_CMD_DEV,"dev"},
                                        {EXEC_CMD_STORE,"st"},
                                        {EXEC_CMD_STORE,"store"},
                                        {EXEC_CMD_NONE,""}
                                       };

So DE and DEV are equivalent.

 

Now looking at the code for the DEV command below, shouldn't the default to the first switch statement use the parse_cmd function instead of the parse_equate function to extract the requested command? I'm not really familiar with the C syntax, but it seems that the former function is used for the STORE command, which actually works, but not for the DEV command which does not...

cmd = (execcmd_t)parse_cmd(cmds, &buf, &len);
  // if a cmd, i will point to location after cmd
  // and cmd will equal type requested
  if(cmd != EXEC_CMD_NONE) {
    //skip spaces
    trim (&buf, &len);
  }
  switch (cmd) {
  case EXEC_CMD_STORE:
    ee_set_config();
    break;
  default:
    cmd = (execcmd_t)parse_equate(cmds, &buf, &len);
    switch(cmd) {
    case EXEC_CMD_DEV:
      if(dev != NULL) {
        rc = HEXSTAT_DATA_ERR; // value too large or not a number
        if(!parse_number(&buf, &len, 3, &value)) {
          if(value <= DEV_MAX) {
            rc = HEXSTAT_DATA_INVALID; // no such device
            for(i = 0; i < registry.num_devices; i++) {
              if(
                  (registry.entry[i].dev_low <= (uint8_t)value)
                  && (registry.entry[i].dev_high >= (uint8_t)value)
                ) {
                registry.entry[i].dev_cur = (uint8_t)value;
                *dev = (uint8_t)value;
                rc = HEXSTAT_SUCCESS;
                break;
              }
            }
          }
        }
      } else {
        rc = HEXSTAT_DATA_INVALID;
      }
      break;
    default:
      // error
      rc = HEXSTAT_OPTION_ERR;
      break;
    }
    break;
  }
  return rc;
}

 

Link to comment
Share on other sites

I used my comment as well, but I think my comment is wrong.

 

Since st works, try just doing open #255,"20.de=21"

 

I checked the source and there is no "set" or "se" in the entire source, so I must have decided to punt and just make the parms verbs themselves.  My apologies.  If your test works, I'll update the code.

 

For anyone who cares:

(main.cpp) The main parser reads the hex data, and determines the operation is open, and to the serial device.  It checks the registry that every specific soft peripheral registers with (registry.cpp) to find an entry to device 20.  It finds the serial.cpp library, so jumps to that.

IN serial.cpp, there is ser_open(), which does the open.  To ensure compatibility with HEXTIr's way to handling configuration when using the drive peripheral, where an open of some text would normally try to open a file with that name, the code (line 342) checks for channel 255.  If found, it immediately starts parsing config, but otherwise, it drops down and tries to do an actual open of a serial part, but it also handles configs there as well.  Both branches call ser_exec_cmds().

ser_exec_cmds() (line 279) tries to break apart the string into pieces, and then it sends each piece to ser_exec_cmd() (line 87)

ser_exec_cmd tries to match the first few letters of the command to one of two lists, shown in lines 61-85.  A cc40 list (b, .ba, d, .da, etc.) and a ti list of additional items (.tw,.nu, etc.).

if the command is not in the first set, then it drops into the default case (line 251) and checks the second set.  if that list doesn't work, it then calls hex_exec_cmd() in line 273

hexops.cpp contains the default config helper function, hex_exec_cmd() line 306.  Just like in serial.cpp, there is a list of commands about the function, as @Vorticon shows.  de and dev are both mapped to command DEV, while st, store are both mapped to STORE.  When the command is parsed into EXEC_CMD_DEV or EXEC_CMD_STORE, the switch statement in lines 327-342 kicks in.  If CMD_ST is found, do it. Otherwise, the code assumes its a "cmd=value" pair, and so tries to parse it.  ONce parsed, it checks if the cmd was DEV, and if so, it updates the registry with the new device ID.

 

 

  • Like 1
Link to comment
Share on other sites

Dang, I forgot about that.  You are most correct, apologies for that as well.

 

Do you have a way to recompile the code?  If so, you can alter the dev in the code for now, while I work on the issue.  Eitehr st is failing silently, and the code never gets called, or the parse_equate is broken.

 

Jim

Link to comment
Share on other sites

5 hours ago, brain said:

Dang, I forgot about that.  You are most correct, apologies for that as well.

 

Do you have a way to recompile the code?  If so, you can alter the dev in the code for now, while I work on the issue.  Eitehr st is failing silently, and the code never gets called, or the parse_equate is broken.

 

Jim

Sorry I don't have the tools to compile CPP. Hopefully it's a minor bug.

Out of curiosity, why was device 20 chosen for the on board RS232 since it was expected to conflict with the external device? I'm assuming it was to maintain compatibility with existing applications that use the RS232 and expect it to be device 20. I wonder how many users here have had a need for that.

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...
  • 2 weeks later...
24 minutes ago, dhe said:

Does the hex-ti-r emulate an rs232?

 

Next to a waffer tape, needed for storage, the rs232 for i/o with the outside is the second most needed peripheral. 

It does and is assigned device #20 which is the same as the hexbus rs232 peripheral. 

  • Like 1
Link to comment
Share on other sites

38 minutes ago, Vorticon said:

It does and is assigned device #20 which is the same as the hexbus rs232 peripheral. 

 

 So why did you go with a hexbus rs232, instead of running it through the hex-ti-r?   Was it just ease of cabling?

Link to comment
Share on other sites

1 hour ago, dhe said:

 

 So why did you go with a hexbus rs232, instead of running it through the hex-ti-r?   Was it just ease of cabling?

Pretty much :) I did not have the needed adapter and I have currently no other use for the RS232 peripheral so may as well put it to good use. It also has a parallel port so I may at some point print out data to a printer as well.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...