Tesla Programmer

[SiriusHardware]

I've just dug out something I had almost forgotten about, an Arduino 'Micro' which surprisingly turns out to have 2.5KB of RAM, a little bit more than the CPU used in the UNO. I'm going to experiment with downloading the whole Intel Hex file straight into a very big array without processing it at all, then working through it to see if it is a valid Intel Hex file. If that works I may use it as the basis for the controller to drive Chris's PCB with.

[SiriusHardware]

Preliminary serial transfer results on the Arduino Micro are good, there is enough RAM on the Arduino Micro to create a CHAR array 'RxBuffer=[1440]' and then I read each serial byte as it comes in and as soon as I see a ':' (First character in a legitimate Intel Hex file) I just start reading each serial byte in as soon as it becomes available and stuff it into the next available slot in RxBuffer without making any attempt to parse it at that stage. I've tested this at serial speeds of up to 230400 so far (without software handshaking) and it never loses a byte.

End-Of-File is detected simply by measuring the interval since the last serial character was received - if more than 200mS has elapsed since the last received character then the host is assumed to have finished transmitting the file. If it were not for this fifth of a second delay the transfer would seem more or less instant.

The code then works through the Intel Hex file stored in RxBuffer, checksumming it and (potentially) saving the raw bytes although I'm not doing that yet.

As a RAM saving measure I intend to put the decoded raw bytes in the first 512 bytes of RxBuffer rather than in their own 512-byte array which would be pushing things a bit. This is possible because at least two bytes (ASCII characters) have to be read from the buffer to extract one raw byte of data, so it is perfectly OK to overwrite already decoded Intel Hex bytes with the raw data which will eventually fill the first 512 bytes of the RxBuffer array.

As things stand this might also work on an Uno with its 2K of RAM, I will try that when I get a chance.

I haven't (yet) done any work on the device programming side.

[Slothie]

I thought about this after you mentioned it and recalled that the Arduino Micro was based on the ATMEGA32U4 - the same one as in the Leonardo - that has a built in USB interface. The extra 512 bytes of RAM is used for the USB interface if the Serial Module or any other USB function is activated, so it effectively has 2k of usable RAM (Unless you don't use the USB/Serial). So this idea would work on the UNO as you say.

I thought you'd have to re-use the buffer and as far as I can see there really isn't any reason not to.

[SiriusHardware]

I've just put a 512 byte binary file through a binary to Intel Hex conversion and the resulting Intel Hex file came out at 1,387 characters.

You might wonder about the disparity between the file size quoted above and the buffer size of 1440 I mentioned the post before last - when I counted the number of characters in an Intel Hex file representing 512 bytes I counted exactly that - the number of characters. I forgot about the invisible CR/LF characters which may or may not both - depending on which OS saved the Intel Hex file - be present on the ends of the lines of hex. The actual length of the file is 1421 characters but I have allowed a small amount of wiggle room in case the Intel Hex file sent to the Arduino was acquired by cutting and pasting it from some online source, in which case there could be a few stray characters dangling off the end of it.

[SiriusHardware]

Can I ask you which Arduino pins you're using to:-

-Drive the 9 PROM address pins
-Read the 4 data bits in
-Write the 4 data bits out
-Toggle the VCC supply volts to the chip
-Enable data output from the chip

Since all of these connections from mine to Chris's PCB will be by flying wires I am not committed to a particular connection scheme so it might make sense if I adopt roughly the same pin-> function scheme as you, especially if I switch to the UNO.

Where I'm driving address lines on a PROM or some such I tend to use the A0... to Ax... (analogue) pins as high as they go on the particular Arduino for the address lines before continuing on with pins 2,3,4.... (1 and 2 being tied up with the comms to the host).

[Slothie]

The pin definitions are:

const int addr[]={A0,A1,A2,A3,A4,A5,2,3,4};
const int data[]={8,9,10,11};
unsigned volatile char image[512]; // Store of PROM image
:
:
#define NCE 5
#define NVPPE 6
#define NVCCE 7
#define READ 12
#define STATUS_LED 13

Pulling NVCCE to LOW turns on 5v to the PROMs Vcc, Pulling both NVCCE and NVPPE low applies 10.5v to the PROMs VCC. If NVCCE is high, then no power is applied to the PROM regardless of the setting of NVPPE.

Data pins 0,1 are reserved for serial port as normal.

READ is HIGH if you are reading the PROM contents, and addressed data appears on pins held in data[0..3] when NCE is LOW.
READ is LOW if you are writing, and the corresponding data pins are pulled low for any pins data[0..3] that are set to HIGH (which should only be one at a time as per programming spec). NCE is active low chip select as normal as specified in the programming procedure used to time the programming operation.

[SiriusHardware]

const int addr[]={A0,A1,A2,A3,A4,A5,2,3,4};

Great minds, etc. ^^^^^^^^^^^^^^^^^^^

And yes of course, 0 and 1 are the pins tied up by comms.

As a matter of interest do you think that never-changing variables defined as 'const' are placed in program (code) memory rather than RAM? That would be my expectation (and the whole point of declaring them const) but something I read recently made me think maybe not. I've never pushed the Arduino RAM limit so hard before, so I'm only just having to think about it now.

Thanks for the info - I will try to follow your pin allocation scheme as far as possible but there may be circuit differences especially in the area of power control where I will have to deviate a bit to suit how things are done on Chris's PCB.

[Slothie]

I think const arrays are copied from flash to RAM when the sketch starts (like string literals) and the compiler prevents them from being changed. Const variables are usually optimised away.

If you want to save memory you can use the PROGMEM qualifier that puts the const array in program flash, but requires use of "pgm_read_xxx" access functions to get their values (see this article or similar).

If you have string literals in Serial.print() function calls, surround them in the F() psuedo-function to put them program storage e.d.

Serial.println(F("This is my program"));

The Serial.print[ln] function does the rest for you.

[SiriusHardware]

Pleased to say that the PROM programmer PCB which Chris put in the post to me early in December finally managed to flop onto the doormat just before New Year's Eve, so I should now be able to make some progress with this, as all of the more 'exotic' components which I also ordered at around the same time eventually arrived here in fits and starts.

The SOIC switch-mode regulator IC proved quite hard to find when I went to order it and I ended up ordering a small quantity from Israel - if anyone else intends to have a go at building one of Chris's PCBs I have a few of the reg ICs to spare.

[SiriusHardware]

I have the Tesla programmer PCB about 60% populated now - found a reasonably priced 8255A which I hope is similar enough to the Intel version. Of course I couldn't find any of the several that I know I have. I've decided to order the specific low-ESR capacitors and inductor from the BOM to be sure that the 10V SMPSU will work as intended.

Having started with the Arduino Micro (which I will probably keep for this project as it is 5V-friendly) I got sidetracked into trying the code on a Pi Pico because the Arduino IDE does now have proper 'board' support for the Pico.

In both cases I'm having a peculiar problem which I don't think normally happens on the UNO -

If I initialise the serial port and send an initial prompt, like this:

 
Serial.begin(115200,SERIAL_8N1);
Serial.println("Ready - waiting for Intel Hex file at 115200,8,N,1");

I don't see the "Ready" prompt, yet the serial port is working beyond that point because the next thing I do is continually read from the serial port until a whole Intel Hex file has been received and then parsed / checksummed, and that works.

Whether the code is successfully received or not, the serial port is then closed at the end of the main loop.

Back at the beginning of the main loop the first thing encountered is the Serial.begin code above, and this time it DOES display the 'ready' prompt. It's as though I have to read from the serial port first to wake it up before I can send anything to it.

I have the same problem when using the Arduino Micro and the Pi Pico - no initial prompt on first connection. Does anyone know the work-around for this?

[SiriusHardware]

This seems to have done the trick - now the 'Ready' prompt is available as soon as the terminal can see the device.

  Serial.begin(115200,SERIAL_8N1);
  while (!Serial)
   {
   // Just loop until Serial becomes available
   }
  Serial.println("Ready - waiting for Intel Hex file at 115200,8,N,1");

[SiriusHardware]

I now have the PCB assembled as far as it needs to be but my SMPSU for the 5V / 10.5V SMPSU regulator is not running (at either voltage). Instead, the voltage at D1 Cathode is 4.867 which is just the +5.00V supply being dropped across D1.

The first thing I have to suspect is that the reg ICs I've been supplied with for the IC5 position are not actually what they are supposed to be - on looking up the code printed on them they have 'S518' marked on them, which on a brief search comes up as a transient suppressor. Chris O, if you read this, I would be interested to know what the marking is on your IC5?

(Edit - Actually the marking on mine is 'S51B' which is indeed what it should be for the LM2731Y according to the Ti datasheet. Of course, mine could still be fakes.)

[SiriusHardware]

Well, just tried a second 2731Y IC in IC5 position and I now have 4.99V / 10.3V according to the logic state of the output from 8255 pin 16. I can't imagine what I did to the first chip, all static handling procedures observed etc. The only change I have made is to replace the first chip with another one.

Onwards and upwards...