• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Introducing (and interest check) AirTalk: Wireless plug-and-play LocalTalk dongles

ronan

Well-known member
Would people be interested if I posted the software work I'm doing towards this and why, so people can see what goes into the sausage and have opinions about it? I'm just keeping a to do list at the moment but I'm happy to be more communicative about things if it wouldn't bore people solid :)
Yes would be interested !

You could also post the hardware if you're ok with this :)
 

cheesestraws

Well-known member
You could also post the hardware if you're ok with this :)

I will do! Most of the stuff I'm doing at the moment is software, which is why I asked about that. I'll post a sort of "where we are" post later then and what I'm planning to do next :).
 

MacKilRoy

Well-known member
I will do! Most of the stuff I'm doing at the moment is software, which is why I asked about that. I'll post a sort of "where we are" post later then and what I'm planning to do next :).

The development of these sorts of things intrigued me so post away!
 

cheesestraws

Well-known member
Hardware talk first, because this is quick:
  • The current through-hole design uses the Texas Instruments SN65HVD08 RS-485 transceiver chip, because it's the one that @tashtari had confirmed worked well. That confirmation was absolutely what I needed for the prototype, but that chip is overspecced for this application, which makes it expensive. It also doesn't seem to be available for automated assembly in the places I've looked, and in fact stock of the SMD variants seem to be a bit low in general. So I've ordered some slightly mystery brand transceivers on carrier boards to try them in my current known-working prototype, to see if I can get a chip that's available, has a lower specced bitrate, works, and is cheaper. The datasheets for the ones I've ordered look promising. Let's see.

  • I've nearly finished designing a first attempt at an SMD version of the board suitable for automated assembly. I expect it won't work, but it will hopefully not work for an interesting reason rather than a boring reason. Obviously, I'm not going to get any of these made until I know what RS-485 chp I'm going to be using. I'll ask for some feedback, input and opinions on the board when I have something that basically works: I'm not going to waste people's time asking them to critique a design that's fundamentally broken. I've never done this before, so the odds are not in my favour: 75% likely I've done something stupid.

  • Trying to work out what to do about programming the PIC; given the degree of interest above, I do not wish to spend the remainder of my existence pressing the button on my pickit and waiting, then repeating. If I've done the calculations right, Microchip's low-volume programming service is probably economically viable.

  • The mini-din connectors I have here are cheap and cheerful and adequate, but aren't what one would call properly nice. Since one is probably going to be plugging and unplugging this a reasonable amount, I suspect it will be a good idea to get better mini-din connectors: it'll only add about a pound to the cost of the end device and breaking the mini-din connector would be extremely annoying.
I will wait with interest to see how the general shortage of everything (except shortages) intersects with these grand plans, and whether I will be brought to a screeching halt by an absence of some critical part...
 

CC_333

Well-known member
...the general shortage of everything (except shortages)...
There's definitely no shortage of shortages!

I was going to post more, but decided it would be more appropriate for it to be in it's own thread because it distracts too much from the subject at hand. Therefore, if you would like to read my full reply with some thoughts on the current state of affairs w/re: increasingly unreasonable prices on almost everything, including older PC/Mac parts, please follow this link.

Otherwise, carry on. There's nothing to see here... :whistle:🎶

c
 

ronan

Well-known member
  • Trying to work out what to do about programming the PIC; given the degree of interest above, I do not wish to spend the remainder of my existence pressing the button on my pickit and waiting, then repeating. If I've done the calculations right, Microchip's low-volume programming service is probably economically viable.

Two naive questions here :

  • Do you really need the PIC there ? I know a lot of code and work has been put in developing a transceiver for that chip but how much would it cost to port that code to the esp ? (Maybe that's too much)
  • I have a really old experience with PIC, and back in the days you needed a 12V power rail to flash them. Is it still the case with the PIC you are using ? Do they have a bootloader ? If it's the case flashing them from the esp would be a cool option (but I think I'm being too optimistic here).
 

cheesestraws

Well-known member
These aren't naive questions at all, these are things I've only found out about in the last few weeks myself! (Or, at least, if they're naive questions, I too am naive so you are in ... good (?) company). I'm pretty sure you're better at a lot of this than I am, having seen your 68net project, so...

Do you really need the PIC there ? I know a lot of code and work has been put in developing a transceiver for that chip but how much would it cost to port that code to the esp ? (Maybe that's too much)

The problem here is that LocalTalk timing is really tight. The throughput isn't much, but the timing and latency requirements are actually pretty stringent. The ESP32 is running FreeRTOS and has quite a few concurrent tasks flying about to do things like background housekeeping of the WiFi and IP stack, etc. While I haven't tried it personally, people who have tried similar things have told me that getting that kind of timing guarantee out of the ESP32 is very difficult going on impossible, because of the other stuff going on.

So what it boils down to is "The ESP isn't well-suited for the job, and people who are much better at this than I am have found the job difficult, so I'd be doomed". That, compared with how neat and easy and all-around pleasant the TashTalk is to interface with rather made that decision for me. The PIC is a reasonably low-cost part anyway.

I have a really old experience with PIC, and back in the days you needed a 12V power rail to flash them. Is it still the case with the PIC you are using ? Do they have a bootloader ? If it's the case flashing them from the esp would be a cool option (but I think I'm being too optimistic here).

You do need a special voltage to flash them, yup: and I'm pretty sure there isn't room in there for a bootloader. I'm socketing the PIC in case someone finds a major bug in the TashTalk firmware: and in that case, we will all swear and I will have to send people replacement PICs, and we will, in the euphemistic argot, have learned a valuable lesson about patching.

It'd be lovely if the ESP32 just set the PIC up and we could just drop a blank PIC in but unfortunately I think that'd add as much complexity as the entirety of the rest of the circuit.
 

ronan

Well-known member
I'm sure I'm in good company 😋

The problem here is that LocalTalk timing is really tight. The throughput isn't much, but the timing and latency requirements are actually pretty stringent. The ESP32 is running FreeRTOS and has quite a few concurrent tasks flying about to do things like background housekeeping of the WiFi and IP stack, etc. While I haven't tried it personally, people who have tried similar things have told me that getting that kind of timing guarantee out of the ESP32 is very difficult going on impossible, because of the other stuff going on.

So what it boils down to is "The ESP isn't well-suited for the job, and people who are much better at this than I am have found the job difficult, so I'd be doomed". That, compared with how neat and easy and all-around pleasant the TashTalk is to interface with rather made that decision for me. The PIC is a reasonably low-cost part anyway.

Makes sense. Too much time sensitive stuff going on would makes it hard to handle all communication going on :)

You do need a special voltage to flash them, yup: and I'm pretty sure there isn't room in there for a bootloader. I'm socketing the PIC in case someone finds a major bug in the TashTalk firmware: and in that case, we will all swear and I will have to send people replacement PICs, and we will, in the euphemistic argot, have learned a valuable lesson about patching.

It'd be lovely if the ESP32 just set the PIC up and we could just drop a blank PIC in but unfortunately I think that'd add as much complexity as the entirety of the rest of the circuit.

Makes sense also. One thing you could do (and that maybe you already thought about) is to expose the programming headers so that people who have a pickit at home don't need to receive a new pic from you in case of update 😋


Quick note for future reference

I just had a really quick look at bootloaders for the PIC12F1840 and I found some really tiny bootloaders (under 100 words) that may be suitable for the job : https://sourceforge.net/projects/tinypicbootload/files/
It is work to implement for sure, but this could be a great solution in the future to avoir shipping new PICs in case of upgrade.
 

LaPorta

Well-known member
As an outsider who knows nothing about any of this at all internally, I’m looking forward to testing it as a complete outsider, the “end user” so to speak.
 

cheesestraws

Well-known member
Here's the current state of the software:
  • There is one critical feature left to add: the ability to store which wireless access point to use. Without this, the thing is obviously of questionable use :). There is a way to get a list of the wireless networks available (as shown above), but as yet the configuration part is unwritten. This is also what's stopping the code going up on github: until this is in, my personal wifi details are hardcoded.

  • There is one major enhancement of the forwarding code left to put in: only forwarding traffic that is relevant to the LocalTalk interface out of that interface. At present, it attempts to transmit all LocalTalk packets: and while this isn't quite as bad/chatty as having one long LocalTalk segment, it still means that irrelevant CTS frames clog up our precious precious bandwidth. If, instead, we only forward frames out of the LocalTalk interface that are destined for nodes we have seen on that interface (or are broadcast), we don't even send irrelevant CTSes, and the segment is noticeably quieter. This means that essentially you end up with a kind of hub-and-spur arrangement, with chatty segments and a fast but more latent switched backbone. What this does for performance I have no idea yet, but if you have lots of machines it should make a difference.

  • There's one major bug to fix: there is buffer over/underrun protection, so that if Bad Things Happen and TashTalk and the ESP disagree how far they are through the packet and either state gets scrambled or things get wedged, the ESP returns the TashTalk to a known state. It detects this by looking for multiple attempted RTS/CTS handshakes with no data between them. This is broken in, I think, two ways: firstly, it looks currently at all handshakes on the bus, not just handshakes we ought to have answered. This means that a LocalTalk node trying to transmit to another LocalTalk node that doesn't exist will cause a small but measurable interruption in forwarding. I believe the cool kids call this a "DoS vector". Better fix it. More subtly, I think this needs to ignore all data that is not being forwarded, as well: as it stands I think it could get wedged in the other direction too with a busy LocalTalk segment on the LocalTalk end.

  • Exploratory work: I want to see if binding the UART interrupt to the other core from the IP stack makes that code kick in less often.

  • There's also loads of little cleanup to do. I mean, lots. Things like: we have a huge secondary UART RX buffer that we just don't use. Logging is all over the place. The fake NBP code passes around a totally superfluous enumerator. I don't think the retry behaviour is correct for loss of IP connectivity. There may be a race condition when the device loses IP connectivity, too, which could result in a null pointer dereference. The device passes on ENQs to UDP that it doesn't need to. Fiddly little bits, you know.
On a related note, it's so nice to be writing C99..
 

tashtari

PIC Whisperer
I just had a really quick look at bootloaders for the PIC12F1840 and I found some really tiny bootloaders
A bootloader for the TashTalk firmware is a well-reasoned idea. The reason I haven't implemented one yet is less about code space on the PIC, and more about the serial protocol - it's very simple because it has to be. The PIC is a busy little bee with only just enough time to service its UART, and that makes it dangerous to add features to it. I actually implemented a simple bootloader for it at one point but backed it out because I was concerned about getting the firmware into a bad state that would either confuse the host or accidentally overwrite firmware. The issue that @cheesestraws mentioned about the firmware needing to be reset to a known good state is an example of that - we suspect (but have not confirmed) that it's caused by buffer overflow or underflow, made possible by the simple fact that the PIC does not have enough memory to hold an entire frame at once, so when it starts sending the payload frame, it has to keep receiving bytes from the host and doesn't have time to check if it's underflowing the queue. Fun fun.

I'm rambling. Anyway, I could see a potential solution in jumpering one of the pins as a signal to stay in the bootloader and accept a firmware download so that the normal operation serial protocol is unaffected. Maybe the UART's RX pin? That way the ESP could drive it low... something I'll have to look into. But... after the holiday.
 

ronan

Well-known member
I'm rambling. Anyway, I could see a potential solution in jumpering one of the pins as a signal to stay in the bootloader and accept a firmware download so that the normal operation serial protocol is unaffected. Maybe the UART's RX pin? That way the ESP could drive it low... something I'll have to look into. But... after the holiday.
Yes using a pin to enter the bootloader seems like a good idea :) It is for instance how it works on STM32 where the BOOT0 pin can be held low (or high, I don't remember) to enter the bootloader at reset.

This safe because when that pin is not triggered the bootloader does not affect your main firmware when its running :)
 

cheesestraws

Well-known member
The last couple of days I've been doing more on the Chooser extension. It's now in an approximately working state, allowing you to select WiFi APs from a list and put the passwords in:

Picture 8.png

and it will transmit the details to the AirTalk. At the moment the AirTalk does nothing with it, but now it can!

Screen Shot 2021-12-19 at 22.06.22.png
(ignore the weird framing, please, this was running in BII for the sake of packet capture). Note that the password is sent in plaintext to the AirTalk, but not propagated beyond that, so if you're running on an untrusted LocalTalk network:

  1. Where?! and
  2. Why?!

I've also actually got something approaching real error reporting in now; specifically, I've got a resource that contains a mapping of error numbers to messages, so they can be added/edited and perhaps translated without needing to muck about with the code at all.

Screen Shot 2021-12-20 at 23.11.27.png
Next step will be more tidying of the Chooser extension. Source for this will probably be up pretty soon.
 

sstaylor

Well-known member
Is the SSID and password information stored on the Mac, or on the AirTalk dongle itself? It would be really handy if it could be configured on a mac and then plugged into a remote LaserWriter or something.
 

LaPorta

Well-known member
Is the SSID and password information stored on the Mac, or on the AirTalk dongle itself? It would be really handy if it could be configured on a mac and then plugged into a remote LaserWriter or something.

My hope (an understanding) is that it is stored in the dongle. One use for this for me is to basically have a wireless AppleTalk ImageWriter II, and obviously this would need to work in the way you describe for that to be possble.
 

cheesestraws

Well-known member
the SSID and password information stored on the Mac, or on the AirTalk dongle itself?

My hope (an understanding) is that it is stored in the dongle

Yep, it's on the dongle. You don't need any software at all on the Mac to use the dongle, only to set the dongle up. You can also tell whether the WiFi is successfully connected and traffic is working by lights on the dongle: I'm aiming for one not to have to install any special software on the Mac at all for normal use.
 
Last edited:

LaPorta

Well-known member
This is a huge other thing that would be for when this is all up and running...but wouldn't it be awesome to have something like the AirPort Utility that could see and configure all of these on one network?
 

cheesestraws

Well-known member
That would be nifty, but also kind of a pain to build. Let me think on it.

Here's some code, if anyone wants to poke it or have a look. It's not the firmware yet, but I finally managed to get my working directory for the RDEV into a state where both git and CodeWarrior can both use it. So from now on, the canonical storage for the rdev will be on github. Hurrah.


If anyone fancies doing me some code review that would be wonderful, although as you can probably tell it isn't particularly finished...
 
Top