UART / console redirection - page 2 - General Discussion and Assistance - CHDK Forum

UART / console redirection

  • 37 Replies
  • 23749 Views
*

Offline reyalp

  • ******
  • 14080
Re: UART / console redirection
« Reply #10 on: 21 / December / 2013, 03:08:36 »
Advertisements
DryOS, continued.

As written previously, the "event shell" communicates directly with the UART driver. However, the various event procedures seem to use stdin/stdout. I have verified this by starting "drysh" via a script: I was able to talk to it and get its output.
I would be interested to see code for this, even if it's very rough.
Quote
Next step: remote console over PTP.
One approach would be to make lua functions that let you read from / write to the console.
Don't forget what the H stands for.

*

Offline ahull

  • *****
  • 634
Re: UART / console redirection
« Reply #11 on: 21 / December / 2013, 03:18:45 »
DryOS, continued.

As written previously, the "event shell" communicates directly with the UART driver. However, the various event procedures seem to use stdin/stdout. I have verified this by starting "drysh" via a script: I was able to talk to it and get its output.
I would be interested to see code for this, even if it's very rough.
.. so would I.
Quote
Quote

 Next step: remote console over PTP.
One approach would be to make lua functions that let you read from / write to the console.

Functions to allow configuration of the UART (baud rate,parity,stop bits etc)  would also be useful, for anyone willing to break out the soldering iron and dremmel.

*

Offline srsa_4c

  • ******
  • 4451
Re: UART / console redirection
« Reply #12 on: 21 / December / 2013, 16:57:35 »
I would be interested to see code for this, even if it's very rough.
Attached as svn diff. The code in question is in platform/generic/wrappers.c. I have experimented on the a470 102c, the addresses in its stubs_* files should give usable pointers. I suspect that this camera uart console related code doesn't change much. This WIP code checks for the presence of A/stdout.txt, as the original code did.
replaced_tyRead() contains the characters to be written to the console, replaced_tyWrite() writes to a buffer which needs to be flushed with tywbufflush(). The redirected output is written into stdout.txt.

Strings like "termDriverInit" (and others around it) give hints about the driver/device related routines. A RAM dump from the first ~3MB is useful when browsing that part of firmware.

The VxWorks part of the code is roughly unchanged.

Quote
One approach would be to make lua functions that let you read from / write to the console.
If you can make it work, I'd be interested to see it.

BTW, since the fw routines in question are driver and device related, it might be possible (one day) to create custom drivers/devices with them (not too many, there's only room for 2 additional drivers on the a470). This low level code uses low (kernel?) level synchronization functions - on both VxWorks and DryOS.

*

Offline reyalp

  • ******
  • 14080
Re: UART / console redirection
« Reply #13 on: 22 / December / 2013, 03:19:07 »
Thanks. Here's a patch that adds the entry points for d10 and elph130, along with the stdout.txt from each.

elph130 has
Code: [Select]
=== Dry-shell start ===
Dry> ?
[Debug]
 task  sem  event  mq  mutex  cond  timer  mkobjsize  extask  kill  suspend
 resume  release  delete  prio  mkcfg  meminfo  xd  xm  memmap  objinfo
[Misc]
 vers  exit  dminfo
[Network]
 arp  mbufs  ping  route  ifconfig  netstat  pngl  netrace
[TMN]
 tm  rt  wps  ibss
[WiFi]
 wprd  wtst
The last 3 sections are interesting ;)
I've seen these before of course, but haven't had any way to send input to them.

I've been think I have a good idea how to add script support, but haven't started to code it yet. One complication is that some of the eventprocs I want to call are interactive (prompt for some value, wait for input, prompt, etc), so would probably need to be called from a different task than the one that was feeding it input and reading output. If you don't need to read the output, it might be enough to just buffer all the inputs before calling.
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4451
Re: UART / console redirection
« Reply #14 on: 22 / December / 2013, 11:05:33 »
elph130 has
Code: [Select]
[Network]
 arp  mbufs  ping  route  ifconfig  netstat  pngl  netrace
[TMN]
 tm  rt  wps  ibss
[WiFi]
 wprd  wtst
The last 3 sections are interesting ;)
Yeah. I thought these utilities were standalone, looks like they are not.
Quote
One complication is that some of the eventprocs I want to call are interactive (prompt for some value, wait for input, prompt, etc), so would probably need to be called from a different task than the one that was feeding it input and reading output.
I was wondering why the script I started drysh with got stuck, until I noticed that PhySw became the host task for that shell.
However, I succeeded with the PTP remote console approach where I added two PTP commands to read from and write to the remote console - all I have to do is exit the utility I started (drysh) to unblock PhySw. I also understand that you may need to do things differently (for the networking stuff) due to PTP possibly influencing it.

@ahull
I'll try to make the Vx part similar to the DryOS code and post that version. About porting the UART setup to DryOS: it may not be so easy, the ioctl handler will have to be researched; that doesn't seem to exist on DryOS...


I have found something that's worrying:
D10
NAME            ID   STATE PRI         WAIT(ID)      STACK  %        SP
PTPSession 01fd0044    WAIT  25  RCVMQ(01fa004c)  0fa8/1000 97  002fe240

A470
NAME            ID   STATE PRI         WAIT(ID)      STACK  %        SP
PTPSession 01c60041    WAIT  25  RCVMQ(01c30041)  0e74/1000 90  0028b908

Looks like a high chance for stack overflow...

*

Offline reyalp

  • ******
  • 14080
Re: UART / console redirection
« Reply #15 on: 22 / December / 2013, 16:56:38 »
I have found something that's worrying:
D10
NAME            ID   STATE PRI         WAIT(ID)      STACK  %        SP
PTPSession 01fd0044    WAIT  25  RCVMQ(01fa004c)  0fa8/1000 97  002fe240

A470
NAME            ID   STATE PRI         WAIT(ID)      STACK  %        SP
PTPSession 01c60041    WAIT  25  RCVMQ(01c30041)  0e74/1000 90  0028b908

Looks like a high chance for stack overflow...
Ouch. Good catch, we should probably look into hooking the create to increase this, or at least minimize the use of stack variables.

This would be another reason to move the script initialization call out of the PTP code too.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: UART / console redirection
« Reply #16 on: 22 / December / 2013, 16:58:58 »
Here's the patch that makes the camera console available over ptp.
There are several issues with it:
- CAM_CONSOLE_LOG_ENABLED is not the best description
- the PTP part should be made optional as it relies on optionally available functions
- not tested for long time stability
- buffering code in wrappers.c is probably flawed, it may at least need some protection against concurrent access

The CHDKPTP part:
I have implemented the remote console at the lowest level (in C), this should probably be fixed.
I have only used it in text mode.
The new command is
Code: [Select]
camcon [eventproc]Where [eventproc] is an event procedure that gets executed right before connecting to the camera console. It's mandatory on DryOS, otherwise there's no console access.
Since I'm only using stdio, you'll probably need to press Enter twice instead of once.
The started event procedure (typically drysh on DryOS) will block the keyboard task, it's up to the user to exit from the started utility (the command is 'exit' for drysh). The console can be left with the '%' character (+enter) - I simply had no idea what this special char should be.

This whole thing is meant to be a debug feature btw.

*

Offline reyalp

  • ******
  • 14080
Re: UART / console redirection
« Reply #17 on: 24 / December / 2013, 00:03:58 »
Here's a version that makes the camera console available from lua. It adds the following functions

nsent=cam_con_puts(string)
sends string to tyRead, returns number of chars actually written. If nothing is reading it will send one.

string=cam_con_gets()
returns text from tywrite, or false if there is none. Since get_tywbuf_data may require more than one call, should call repeatedly until it returns false (assuming the camera isn't streaming output...)

call_event_proc_task(eventproc,...)
calls the named eventproc in a separate task. This is necessary to interact with dryshell or similar from Lua. Note there can currently only be one such task, and it exits when the eventproc exits.

result=get_task_result()
returns the return value from the above, or false if it is running and hasn't returned yet.

Note this is all very rough, not intended to be final!

example from chdkptp:
Code: [Select]
$ chdkptp -c -i
connected: Canon PowerShot ELPH 130 IS, max packet size 512
con> =call_event_proc_task('drysh')
con 1> =return cam_con_gets()
2:return:'
=== Dry-shell start ===
Dry> '
con 2> =return cam_con_puts('?\n')
3:return:2
con 3> =return cam_con_gets()
4:return:'?
[Debug]
 task  sem  event  mq  mutex  cond  timer  mkobjsize  extask  kill  suspend
 resume  release  delete  prio  mkcfg  meminfo  xd  xm  memmap  objinfo
[Misc]
 vers  exit  dminfo
[Network]
 arp  mbufs  ping  route  ifconfig  netstat  pngl  netrace
[TMN]
 tm  rt  wps  ibss
[WiFi]
 wprd  wtst

Dry> '
con 4> =return cam_con_puts('exit\n')
5:return:5
con 5> =return cam_con_gets()
6:return:'exit
logout
==== Dry-shell end ===='
con 6> =return get_task_result()
7:return:0
This doesn't require any changes in chdkptp or the protocol. It could be made more friendly with a chdkptp sub command
Don't forget what the H stands for.


*

Offline reyalp

  • ******
  • 14080
Re: UART / console redirection
« Reply #18 on: 25 / December / 2013, 21:18:45 »
Here's a modified cli.lua for chdkptp which adds a sub command for using the lua based camera console io. This is clunkier than srsa's approach, but it doesn't require the console stuff to be in the PTP protocol. It does let you use command history / line editing in windows. It doesn't work in GUI mode.

This is strictly line oriented, and only checks camera output when a command issued. If a command doesn't produce output quickly, it may not be displayed until you issue the next command.

mcamcon enters the subcommand.

It can optionally specify an event proc to run in a task, e.g.
mcamcon drysh
In this case, mcamcon will exit when it finds out the task has ended.

If the line starts with % it is sent to the message shell script, so
%exec print('hello world')
will execute the print in lua on the camera.
% by itself checks for new output.
%quit ends the message script and the mcamcon subcommand.

If the camera continuously produces lots of output, things will probably break.
Don't forget what the H stands for.

*

Offline ahull

  • *****
  • 634
Re: UART / console redirection
« Reply #19 on: 26 / December / 2013, 01:07:51 »
This looks pretty useful. Unfortunately I wont be in a position to do much testing for the next few days as I will be travelling.

 

Related Topics