Accelerate smoothly (constant Jerk) when making straight and spline moves.

Get XYZ, cosine, other data back from the FPGA through DexRun.c to DDE.

While there may be some room in the return status data, many possible return data items may be of use in the future. Use read_from_robot for #XYZ "file"? Or use #FPGA and an address number for general purpose access?

It programs ok, appears to run programs correctly, e.g. the ASCII table example, but the data that shows up in the Serial monitor window is just garbage.

When I hook my scope up to the serial pins, I see valid data. It's a SmartScope (lab-nation.com) so it has a serial data decoder built in. That seems to see valid data. But the data returned to the PC is still garbage. I ran it all the way down to 300 baud without any change. I tried using RealTerm, it also gets garbage. Removed the prototype board, no change.

It's as if the clock in the USB adapter is off, but if that were the case, it wouldn't program, right? And it does program, at 57,600 no issues.

Same PC programs the same sketch into a standard Arduino Uno and gets the correct values back.

http://forum.tinycircuits.com/index.php?topic=1901.msg3730#msg3730

Upgrade Ubuntu Kernel from 12 to 16 LTS and produce a new SD card image for user update. This may allow WiFi support and will allow a more modern version of Node.JS to be installed for local scripting.

Post ScreenShots of Dexter Gateware from Viva for prior, current, and future versions. This will help us be more open source (because we can't release Viva) and will help the rest of the team understand what is going on in the FPGA.

If we know the stepper angle (meaning the angle the stepper motor has been told to go), as well as the actually measured angle #12 and there is little to no mechanical backlash #7 then we can accurately measure the torque on each joint. This can give Dexter an accurate sense of touch, which allows sensing collisions, the location of the workspace, and other objects.

Even now, we could move to a point, zero out the error, then move to another point, and watch the error until it exceeds a threshold, indicating a contact. If the two points are fairly close together, backlash, changes in gravitational pull and other issues are unlikely to influence the feedback.

Add doc for when Eye Calibration is needed and how do do it.

Extend the read_from_robot command to allow it to spawn a bash shell and inject a command (sent as the pathfile parameter) and return the stdout (and stderr?) text. This would allow greater interaction between the development environment and the operating system on Dexter. For example, DexRun.c could be updated and compiled, then run, by DDE.

This function creates the dxf for drawing a string.
it works for 2 + lengthed strings but not for 1 char strings.
This is a useful function so let Fry know when its fixed
so I can document it.

Frequency vs Time follow in calibration (take amplitude of eyes out of the equation) for better accuracy from the encoders. Removing the magnitude from the calibration of the eyes. Sort of like Automatic Gain Control AGC for the opto.

If we have a very accurate sense of the center of mass of each link between joints #15 , and know the exact position of each joint #12 then we can compute the force due to gravity that the arm should be subjected to. Given this information, if we can sense torque on each joint #13 , then we can measure any additional weight or force being applied.

Having a way for Dexter to find "home" position automatically would be a wonderful help. This will both allow it to accurately interact with a work surface or other object via "dead reckoning" (no need to touch or be guided to a starting point). It will also removed the need to calibrate Dexter on startup because the prior calibration can be applied immediately.

Currently, the solution to this is to add a "dial" or little knob to each motor shaft. The robot is set to a perfect zero position once during manufacture (with a test stand) then the dials are installed and their correct positions marked. While powered off, the robot is move close to the home position, then each dial is turned until it lines up with the known home position.

Automated methods of solving this problem include:

• An index pulse on each joint encoder. The issue with this is the cost of an addition sensor and extra size of the disk. It may be possible to get the same effect by filling in one of the regular slots with a semi-transparent material (it looks like "Elmers Washable Clear Glue" works well) so that the slot is still there, still the same width, but doesn't "open" as far as the other slots. On power up, each joint would be "wiggled" until the index slot is detected. Redundancy is provided by the fact that each sensor should see the same effect, some fixed number of degrees apart.
• A mechanical home switch on each motor shaft. Just like the dials, the arm would be preset to near the home position, then on power up, each joint would be "wiggled" until the home switch closes.
• A "garage" or "dock" where the tool interface must be placed by the user before power up. The robot can even drive the tool interface into the edges of the dock to ensure it is well seated before setting that position as home. Or that position may be "pre-home" and home is a known number of degrees on each joint away from the pre-home position. So the robot finds pre-home, translates each joint to a new position (home) and then zeros out it's position making that home.

In order for DDE to know if an instruction can actually be executed or not, the firmware needs to return an error if the instruction isn't known. At this point, we can test some changes: In the case of read_from_robot, DDE can tell if the command is not implemented because there will be no file data returned if the firmware hasn't been updated to implement the command. The write_to_robot command can be verified via read_from_robot (checking to see if the file was written). However, In the future, other commands may not return data, so an error message is a good idea.

Refuse commands to go past limits? Or allow graceful recovery?

In order to support more complete IO via the Tinyscreen+ on the v2 Tool Interface, it would be very good to be able to send it strings of data instead of just 4 bytes at a time.

https://docs.google.com/spreadsheets/d/1uk89q76vcK4OT9NTM6qxsPpkON_QM3-OrlhfjPigGuE

Bring up todate with kickstarter and HD tabs

To make it very very easy to change modes (keep, follow, protect) add a new SetMode sub-item to set all the FPGA parameters in one shot.

It will be desirable to operate Dexters remotely via the Internet either to monitor, operate, and/or repair remote devices, or to make Dexters available for general purpose work.

Dexter supports socket connections natively, but those are typically limited to the local internet and do not pass through firewalls without additional (and often not allowed) holes being opened. WebSockets can operate freely between most networks, but despite the name, are NOT the same as native socket connections. WebSocket connections can be supported on the Dexter via a simple NodeJS proxy server, but getting out to the internet requires "chat" server accessible from the internet in general. The local Dexters NodeJS server would connect to the DexChat server, registering the robot as active and opening a WebSocket connection. Humans would log into the DexChat server via browser which would be served a web page which would then open WebSocket connections. The DexChat server would list available robots, perhaps filtering the list according to access rights.

The human could initiate a connection to the robot through the DexChat server. Messages would go to the server, which would then relay it to the open WebSocket connection to that Dexter. The NodeJS server on the Dexter would receive the message, relay it as a true socket message to the firmware on localhost, pick up the response, and relay it back to the chat server via websocket. The chat server would then relay that back to the human via the websocket connection to the browser. This is basically, like a Private Message on a standard chat server.

Latency

The major concern here is the speed of the connection. The NodeJS Proxy server takes about 1.6ms between Dexter and a Chrome web browser. Because NodeJS is known for very rapid response times and we are a JavaScript heavy house, we will try that first.

Latency compensation

But as we move out into the internet, latency of hundreds of ms are not unknown. As a result, Dexters haptic feedback system can get into oscillations or just lag, causing touch feedback to become unusable. The solution is probably to work towards predicting the next movement when sending data from the robot with the human, and predicting forces when sending data back. Obviously, the former is easier than the latter, but 3D scanning the work area and proximity detection before actual touch can help.

Forward Latency compensation

We've already experimented with predicting where the operator is moving the arm via spline curve fitting and it seems like that will work well, but we are concerned about noise in the system and it's needs more testing.

Back Latency compensation

Understanding what forces the remote arm will encounter /in the future/, which is required for latency compensation, is very difficult. Understanding the 3D environment and simulating when the arm will contact an object is one possible approach. Point cloud data is accesable via existing 3D scanners, and can be localized to the end effector to reduce data size. Having to transmit all the points back to the controller is a non-starter; it will be critical to difference the current scan and the prior scan and only transmit errors, or to convert point cloud to mesh, or some combination of that and other tactics.

The video game industry has done important work on this and we hope game developers will be interested in adding haptic feedback via the robot arm.

Each Dexter robot may have different lengths for each link between joints 2 and 3, and 3 and 4. Different versions and designs for Dexter may have different placements of the joints. Being able to accurately track and understand the joint lengths becomes important when doing precise operations like force sensing. #14

DDE has had a system in place for changing the default link lengths since version 2.3.15
but there isn't a way to get that data from the robot automatically.

Use read_from_robot to automatically get a LinkLengths.txt file from the robot (assuming it supports that function)?

The socket interface in DexRun.c is set to timeout after 30 seconds and close the interface. If a movement takes longer than 30 seconds, the return status command may not be returned because the connection may be closed.

Note: The above is a guess based on the source code. It has not been tested or seen at this time. That makes sense because few moves take that long. But if it's possible, then we should look for it.

New tool interface / end effectors add Joints 6 and 7 via Dynamixel XL-320 servos, and provide additional IO and user interface at the tool interface via a Tinyscreen+. This will support a range of End Effectors including a standard gripper as well as others which use the 7th access via a power takeoff, and the IO lines via a set of spring loaded connectors. It should be possible to auto change them.

A new tool interface with a small TFT screen for user interface, 6th and 7th axis servos and an auto change mechanism for end effectors is being developed.

Details can be found in the wiki on the End effectors in general and the future plans , for the UI screen, and for the servoes used for the additoinal axis.

When Dexters had a fixed ip address, you could just connect a CAT5 cable between the PC and Dexter and it would work. And yes, that is perfectly valid electrically... Ethernet signaling is specifically setup to work in that configuration, so that when only two devices need to be interconnected, no hub or router or anything else is really needed.

Now, there were problems if you enabled your WiFi and it went up on a different subnet, but that was fixable by changing Dexters IP. E.g. if your WiFi local addresses were 192.168.0 and Dexter was set to 192.168.1.142 then it would not work. But you could disconnect from WiFi, set your PC to a fixed 192.168.1.141 address, SSH into Dexter and change it's IP address to 192.168.0.142, then release your PC's static IP and sign back into WiFi. Your PC to the internet via WiFi, Dexter to your PC via CAT5.

When Dexter's firmware was changed to use DHCP, it was MUCH better for use on a real network, but that requires that we have a router with DHCP for Dexter and the PC to connect into. Carrying the extra router is a pain when doing demos, and it is often the case that users don't have CAT5 connections available to their local routers, relying instead of WiFi for all connections; which Dexter can't support at this time, and isn't really desirable anyway for a security on a robot.

It would be nice to have Dexter start in DHCP, and then if that isn't found, fall back to a static IP.

Need a diagram showing where the link lengths are measured from.
Currently there is only one showing L4 and L5 in DDE.

When entering Keep mode, Dexter will return to the last commanded position, which may not be the current position after movement in Follow mode. Transitioning from Follow to Keep, at the current position, without motion is an outstanding issue.

Golden code disk is oversized, and so very precise, and is used to calibrate actual disks during mfgr. This will improve the accuracy of the encoders.

Sometimes on powering Dexter up, the RED LED (right side, facing the MicroZed control board) will stay steady, and not blink. The RJ-45 connector housing LED's may blink if there is a CAT5 cable plugged in. The robot will not boot-dance, and no method of connecting to the robot works, even if it did before.

This is typically caused by a bad or missing or not fully inserted sd card.

It is very easy to not have the sdcard fully or correctly inserted. Especially after connecting to Dexter via the USB Micro A connector because the edge of the USB cable can easily press the sd card up and unseat it.

One can also have a card that is not all the way up into the slot; the card has to be pressed up until a slight click is heard, and then it can not be pulled back out. If a downward tug on the card removes it, then it wasn't in correctly.

If the card is inserted securely, it may be that the data on it is corrupt or it may be empty. See:
https://github.com/HaddingtonDynamics/Dexter/wiki/SD-Card-Image
for how to burn a good image onto an SD card.

Single Power Cut E-stop: Power cable between the robot and power brick is re-wired into an estop switch box. The negative side is directly connected, but the positive wire is broken by the switch. The power brick positive wire is connected to one side of the switch and the robot positive wire is connected to the other side of the switch. These units are pre-made and commonly available. For example:

• https://www.amazon.com/mxuteuk-MXU-DT-JH-Stainless-Waterproof-Connection/dp/B07RXP2CH2/ref=pd_sbs_3
• https://www.se.com/ww/en/product/XALK178F/control-station%2C-plastic%2C-yellow-lid%2C-1-red-mushroom-push-button-%C3%B840%2C-turn-to-release%2C-2-nc/

Group Power Cut E-stop: Power cables come from each robot to the estop switch box. A single, larger, power brick plugs into the switch box to provide power to all the Dexters. It might be worth having a network hub included so all cables run from the same point and only one network connection is required for up to 4 robots. This will allow very rapid physical emergency shutdown of all robots and will simplify connections.

Because the spacing / gap of the slots on the encoder disks was specifically optimized for certain 3D printers, they can be difficult to print well even on higher resolution printers. If the resolution of the printer / size of the extruded filament doesn't exactly match the design, the slicing can mess up by attempting to get more than one filament pass between some slots and only one between others.

It may be better to design a disk for laser cutting.

Or it may be that very high resolution (e.g. resin) printers are a good choice.

Clear queue AND stop current movement. Implement in FPGA and DexRun.c as optional extra param to "E" oplet. Maybe just pause? Or totally flush? As different param options?

Record on A, playback on B

DexRun.c casts a float into an unsigned int. This generates the warning:

DexRun.c: In function 'SetParam':
DexRun.c:3868:2: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  unsigned int *uia2 = *(unsigned int*)&fa2;
  ^
DexRun.c:3868:23: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
  unsigned int *uia2 = *(unsigned int*)&fa2;
                       ^

To correct this, memcpy can be used:

https://stackoverflow.com/questions/17789928/whats-a-proper-way-of-type-punning-a-float-to-an-int-and-vice-versa

Current code in DexRun.c is XORing the StartSpeed with 1.

mapped[START_SPEED]=1 ^ a2;

The ^ operator in C is XOR. so if a 1 is sent as the parameter, the result will be 0. And a 0 will become a 1. Larger values will simple transition to the nearest value. E.g. 5 will become 4 and 4 will be 5. 1000 will become 1001. With larger values the LSB change quickly becomes negligible.

If I understand correctly, StartSpeed can not be 0 because then the counter in the FPGA will never overflow and the joints won't move.

My expectation is that the operator used should be l the OR operator so that 1 will become 1 and 0 will become 1. Larger values will only be changed if they are even, and will always become the next higher value.

The other option is to simply check for zero and always change 0 to 1 without making any other changes.

But before any change is made, we should verify the intent of the current code. Is it just there to try to ensure the value is never zero?

In cases were Dexters are operating remotely, it will be important to get their status, and perhaps operate them over the internet. We already have a way of converting the actual socket connections used by the firmware into WebSocket connections (which are NOT socket connections at all) via the node.js server

To move this out to the internet, basically, we need a chat server: Each Dexter nodeJS server will connect to the chat server on startup, be registered as a robot in the "chat" and then when a human connects his or her browser to the chat server, they will see a list of online Dexters, and can send any of them a message. That message would go to the server, which would then relay it to the open websocket connection to that Dexter. The NodeJS server on the Dexter would receive the message, relay it as a true socket message to the firmware on localhost, pick up the response, and relay it back to the chat server via websocket. The chat server would then relay that back to the human via the websocket connection to the browser. Like a Private Message on a standard chat server.

Speed is very important for this application since moving the robot precisely requires very fast feedback.

If you have experience spinning up Node.JS servers on public facing platforms, we'd like to hear from you.

While working with Dexter, you might notice problems with it not being at the correct height when reaching down to the surface, or "drooping" or not lifting when commanded. Most of this is caused by problems with Joint 2 (the main "shoulder" joint) or Joint 3 (the "elbow"), but we've seen several things that cause this problem so we are documenting all the possible causes here:

1. The stepper motor shafts on Joints 2 and 3 can easily slip inside the 3D printed adapter from the motor shaft to the inside of the "harmonic drive". Since the motor shaft is what holds the wave generator in, when the shaft comes loose, the generator can fall out.* To fix: Carefully remove the drive or it's wave generator* and adapter and then mung (MUtilate, Nurl, Gorge) the motor shaft with small end cutters or other available tool. Apply a small amount of a high end adhesive to the inside of the adapter (the DP420 Epoxy is recommended, but the metalized JB weld, #8276 has been used) and carefully slide it back in. Take care not to push it too far in as that will cause binding. Let cure before moving.

Note: Later model (2018) Dexters have a motor with "D" shaft which has a flat on one side and is longer to avoid this issue

2. The adapter can also come loose from the wave generator. This is fairly rare, but can happen especially if there is an alignment problem. This, again, causes the joint to lose traction and/or the wave generator to fall out.* In this case, the solution is a bit of low viscosity super glue carefully applied between the adapter and inner hub of the wave generator without disassembly or after re-assembly. Be very careful to avoid getting any glue in the wave generator. Let sit.

*Be very careful re-inserting the wave generator. It is best to try slightly different positions until you find one that slips in easily. However, it can be accidentally inserted such that the teeth are not evenly divided between the two nodes of the wave generator. In that case, the joint will jam up and you won't be able to "back drive" it. To fix it, you should be able to manually spin the inner motor shaft until the teeth pop over into the correct position. At that point, the joint may start working correctly again. Or the wave generator may be damaged.

3. The harmonic drives will bind or jam if they are not perfectly aligned. Loosening, moving and tightening the mounts can help. Also manually rotating the inner shaft / adapter / wave generator can work out the "kinks"

4. Stepper motor driver weakness. In extreme heat, especially when the motor board has been modified to increase the stepper drive, the driver chip can overheat and go into thermal shutdown to prevent burn out. This shows up as a "pulsing" where the joint grips, then sags at a rate of about once per second. Blowing on the chip will temporarily stop the issue. Note that the slipping issues mentioned above can present as a weak stepper motor, where a little "help" will resolve the issue; but this is almost certainly because the joint is slipping and not due to a motor or driver problem. When the driver shuts down, it cycles on and off and is not just steadily weaker. Also, a stepper motor which is losing steps makes a distinctive vibrating noise; it is not quiet, and the slipping is usually very quiet. To fix:
   
   - Add small heatsinks to the driver chips with thermal adhesive. Take care not to short the surface mount components around the driver chips.
   
   - Add a small fan directly over the motor drivers.
   
   - Reduce the drive current back to the original spec's if the motor board was modified to increase it.

Note: Due to the fact that the Joint 2 (and 3) motors are buried inside the 3D printed housings, it is a really bad idea to get them very hot, especially if the housings were printed in PLA or other plastic which can deform when heated. Although the structure of the robot is all the stronger materials, some motor mounts, shaft adapters, etc... are plastic and a loss of rigidity can cause slipping, alignment, and binding issues.

5. Intermittent Z axis position creap. Some users have notice and reported that even a fully functional arm can occasionally drift on the Z axis. E.g. a job that was working at the correct height above a surface, will suddenly move to a slightly different height. Adjusting the job script to compensate results in many more cycles at the correct height, but then suddenly it will move to the wrong height again. We have not been able to reproduce this under test conditions and so are not sure what might cause it. If you can reliably reproduce this problem, please contact us. It is important to eliminate all of the issues mentioned previously before arriving at this diagnosis.

It may be that a divider in the FPGA causes the #2 issue. Removing it and using a different system may help.

We need skins to cover the exposed cables, electronics, bearings, encoders, etc... to protect them, and reassure customers. They could be 3D printed or Vacuum molded (over 3D printed molds) or possibly formed from foam.

Some work on this has already been done (search for "Skin") for the version 1 Dexter

https://www.dropbox.com/sh/5bdyhcyyrf3x53k/AAAagpOvq-TxkVKE1Ax-uodEa/STLs?dl=0&lst=

But it needs to be updated for recent changes (e.g. the new diff, HD lower arm)

Currently only the error between the desired angle and the actual angle is available for read-back from the FPGA. Knowing the actual angle of the joint will simplify adding several functions.

Read back from Firmware to DDE via #11 ?

The firmware should return the current (or previous) instruction id number in the status data. This will help coordinate between DDE and Dexter. Scripts need to take actions when the robot has actually completed (or is working on) a previously send instruction.

The only trick is figuring out which item in the status data to replace with the instruction id. Documenting the actual status data #17 will help to pick one to replace.

In the past, Dexter was unable to support a USB WiFi adapter for RF networking, because the driver would not load on the version 12 operating system.

A new Ubuntu 16.04 image being completed to close #25 might allow a WiFi adapter to be added and work.

There appears to be a special adapter designed for the microzed board:
http://www.zedboard.org/product/wilink-8-adaptor

However, if a USB WiFi adapter is preferred, the current placement of the fan, at the bottom of the microzed board, blocks all the USB connectors (and the sd card). Moving the fan out to the skin and ducting the air to the stepper motor drivers would give us the physical access we need the USB hub for connecting peripherals to Dexter.

Because the SD card slot on the microzed PCB is on the back side, and the stepper motor drivers on the motor board are right behind it, inserting and removing the SD card can be very difficult.

• If the fan has been mounted directly over the stepper motor drivers, it must be removed for access. A fan mounted on the inside of the skin or otherwise placed out of the way and then ducted to the motor drivers is better.

• The connector pads on the SD Card must be oriented facing the user, opposite the motor drivers.

• This SD Card Tool can be 3D printed to help hold the card in position for insertion. It rests on the edge of the terminal blocks for proper alignment. Because the model is made to the exact dimensions of the card, and 3D printer filament often spreads, you may need to scrape out the slot a little after printing. If available, a fine drill (around 0.035" diameter) can be used to drill out the base of the slot to accommodate the slightly wider base of the SD Card.
  SD_Card_Tool.zip

Could another mode be added to DexRun.c that accepted the same standard command format currently used for the network socket interface, but via the USB console connection? Upon connection, the host program (e.g. DDE) could issue commands to pkill DexRun then ./DexRun 1 4 0 (where 4 is the serial command mode) and then start communicating with DexRun. The binary return data might be an issue, but it could be translated into hex, or even ascii numbers. The limitation on socket size doesn't apply to a USB connection.

The advantage of a USB connection is that for a single computer / Dexter com link, there is no issue of IP address or mismatched subnets.

The disadvantage is that it can be difficult to recognize which USB serial port is Dexter if there are more than one serial device connected. The only information provided by a USB device is the VID (Vendor ID) and PID (Peripheral ID) and the chip used on the MicroZed board is just a standard SciLabs CP2102, which is often used in other USB/serial devices. Changing the VID/PID is possible but would cause the OS to not know what driver to load. Registering a new VID/PID with an OS vendor is a non-starter. Providing a driver that isn't registered is prohibited on later Windows versions. The best way to id the Dexter is probably to ask the user to disconnect it, look at the ports list, then reconnect it, and the port that shows up is the Dexter. Once the chip has enumerated as a serial port, the port number shouldn't change, even if the Dexter is disconnected and reconnected, so future communications should be immediate.

In some applications, it is not possible to have Dexter setup in a completely straight or vertical position. It would be good to be able to start Dexter in an offset position.

The actual use of each bit of data returned in the status needs to be documented. Understanding that will allow us to use and change that data in more useful ways. A start has been made for status data in the wiki.

Increasing the resolution of the positioning system to accommodate higher gear ratios in some harmonic drives.

DDE 2.4.3 osx 10.12.6

Team,

I was doing some pre-emptive dev work before receiving my dexter and the function:

dexter.move_to _relative does not appear to work on the sim.

When executing the following code based on the doc

new Job({name: "test_job",
do_list: [Dexter.move_all_joints(Dexter.NEUTRAL_ANGLES),
Dexter.move_to_relative([0.005, 0.01, 0]),
Dexter.move_to([0.1, 0.1, 0.1])
]})
The sim does not reflective any movement at all. All lines after the move_to_relative in the job also fail.
If you comment out the move_to_relative it all appears to work as expected.

Is this because the function needs position data from the robot and the sim does not emulate it it fully?
Other Ideas?

Thanks

The Harmonic Drives used in current Dexter versions are difficult to source, expensive and may have issues with backlash due to side loads. Cycloidal Drives hold great promise: It may even be possible to 3D print them with a high end printer like the Markforge

If you have experience with this, we want to hear from you.

https://en.wikipedia.org/wiki/Cycloidal_drive

Although the ultra precise encoder system used in each joint removes all backlash during operation, mechanical issues during calibration of the encoder disks can remain, causing slightly uneven motion and minor non-linearity in positioning.

We have assumed this is caused by the belts so perhaps we need to go back to Kevlar belts? Dual belts?

But it may be caused by the harmonic drives when they are exposed to side loads. The Cycloidal Drive ( see #6 ) may remove this issue.

Or perhaps the Motors shifting because the screws aren't exactly the right size?

Work with KitWare to provide software medical certification.

In order to support a better access to the file system on the robot via the socket interface, and avoid the need for a Samba or SFTP or other file transfer system, being able to read the directory listings from the robot is important.

We need to change the read_from_robot code in DexRun to look for a trailing / or \ in the request and if found, do an opendir / readdir instead of an fopen / fread.
https://stackoverflow.com/questions/4204666/how-to-list-files-in-a-directory-in-a-c-program

Our current setup will need some adjustment to comply
https://github.com/HaddingtonDynamics/Dexter/blob/master/Firmware/DexRun.c#L2658

Since the blocks are sent in multiple socket buffers, one after the other, and returning a block that isn't full is the signal to DDE that the transfer is complete, we have to do several things:

1. Hold a flag that the current read is of a directory, not a file. We only get the requested data on the first request, so we don't have it when the second one comes in. Not too hard, we can just have a wdp variable as type DIR and check if wfp or wdp is non-zero for the subsequent blocks.

2. Return full blocks until all the files are listed. Rather than reading all the file names in to a RAM buffer on the first request, we can pad the returned file name out to the buffer size (MAX_CONTENT_CHARS) and return each file as each block is requested. e.g. block 1 is the first file name, padded to MAX_CONTENT_CHARS, then when block 2 is requested, we send the second file name in the folder, and so on.

3. When we have returned all the files / folder names in the directory, we need to signal the end. The C code won't really know that it's sent the last name (it returns null when you try to read the next name and it's at the end) so we will end up returning an empty block when DDE requests the next file after the last file was returned. That will stop DDE and adding a null block to the return string shouldn't cause a problem.
   https://github.com/cfry/dde/blob/300634dbb73f4932e1f6352e83efb3894a913e5b/instruction.js#L3289

4. DDE will have this string with a bunch of spaces after each name so it will need to trim them for display / selection.

We could skip this and implement #20 instead, then use a script to return the directory listing.