Yay, congrats :jfj:
Printable View
Yay, congrats :jfj:
Yes, a shared serial "network" functions a lot like a RC network. There's a certain amount of time after the transmitter "releases" the line before the signal level rises back to a logic 1.
Glad you got it working finally! I'm enjoying a Maker's Mark on a chunk of ice to celebrate.
If there's anything I can do to help just say the word.
So you want to bitbang 8192 baud serial but you aren't wanting to use timers? I salute your ambition.
I was able to get a basic state machine working on my logger project in my down cycles today.
Lots of decisions to make but happy to see the experiment working. Should I buy a RTC so filenames can be based on the date, should I add wifi so it will upload the logs to my edge gateway box, etc.?Code:10 59 00 49 02 00 4C
40 57 FF FF 6B
10 59 00 49 02 00 4C
40 57 FF FF 6B
41 67 02 F5 00 49 49 01 00 DD 55 79 E3 00 3D FF FF 00 FF FF 07
F0 56 F1 C9
21948[F1 56 08 B1]
F1 56 08 B1
21960[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 65 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22059[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22156[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 65 65 66 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22254[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22351[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F4 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22450[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22547[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 65 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
22645[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6E F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6A
22743[F4 57 01 00 B4]
F4 92 01 00 00 00 00 00 00 00 00 7C BE 00 00 00 40 00 02 00 FF FF 00 FF 02 49 1B 49 28 23 F5 19 00 6D F5 66 66 65 65 00 80 80 80 80 00 00 00 00 00 00 00 81 14 00 00 00 00 00 00 00 00 00 00 6B
F1 56 00 B9
10 59 00 49 02 00 4C
faced with the same decisions on my first black box datalogger project, i figured i was better off just getting a raspberry pi. i like the low level stuff, but having usb/ethernet/hdmi, and being able to attach gigabytes of flash memory to it with proper filesystems for a few dollars seemed like a no brainer, not to mention being able to SSH into the thing from my living room, and having threads and a scheduler to code with sped things up a lot when i wanted it to do more stuff.Quote:
Lots of decisions to make but happy to see the experiment working. Should I buy a RTC so filenames can be based on the date, should I add wifi so it will upload the logs to my edge gateway box, etc.?
we're all wins here, i got my eeprom block write to work (it does erase a byte if it differs, even if they only set bits low, that's the next step, but the code fits in one ALDL message which is just great)
routine:Code:0.000: flashhack Version 1.2
1.168: COMM::Sent message: F1580370CA7A
1.184: COMM::Recieved reply: F15703FEB7
1.184: CCM Software unlock: NO
1.260: COMM::Sent message: F15803644B05
1.276: COMM::Recieved reply: F157032293
1.277: CCM Hardware unlock: YES
1.277: Entering programming mode on CCM
1.354: COMM::Sent message: F15605B4
1.368: COMM::Recieved reply: F15705AA09
1.368: DEBUG::Executing prepared program CCM_WRITE_NEW on CCM
1.449: COMM::Sent message: F1B906624018CEF49DC601CEFFB0AD0039CE61E6F661E35A2BEBF761E33AA600FE61E43A8D0220E9C60337335A372706A100270220023339C6168D0A81FF2704C6028D0220E5F7103BA700CA01F7103B3CCE0D060926FD38C655F7103AC6AAF7103A7F103B39D4
1.582: COMM::Recieved reply: F15706AA08
1.584: DEBUG::Executed CCM_WRITE_NEW on CCM
1.584: DEBUG::PROGRAMMINGB600[5A]
1.650: COMM::Sent message: F1B80661E07E624C5AB600012BFF8DFFFFFFFF00000000000000000000012BFF8DFFFFFFFF00000000000000000000012BFF8DFFFFFFFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000050000B3
1.786: COMM::Recieved reply: F15706AA08
1.788: DEBUG::PROGRAMMINGB65A[5A]
1.854: COMM::Sent message: F1B80661E07E624C5AB65A000000000000000000000000000000000000000131FFD6FFFFFFFFFFFFFFFFFFFFFFFFFFFF4A9F44DC02D637482D5B34C70467361E1791494631011DA1482E405E391835AF1213040B0000400101010101010101010101010101ED
1.989: COMM::Recieved reply: F15706AA08
1.991: DEBUG::PROGRAMMINGB6B4[5A]
2.057: COMM::Sent message: F1B80661E07E624C5AB6B40101010101010101010101010101010101FF3A020000FE400010000000800020000801804020100804028000080402010000000020000800FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4A
2.192: COMM::Recieved reply: F15706AA08
2.194: DEBUG::PROGRAMMINGB70E[5A]
2.260: COMM::Sent message: F1B80661E07E624C5AB70EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1F
2.588: COMM::Recieved reply: F15706AA08
2.591: DEBUG::PROGRAMMINGB768[5A]
2.667: COMM::Sent message: F1B80661E07E624C5AB768FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC5
2.802: COMM::Recieved reply: F15706AA08
2.805: DEBUG::PROGRAMMINGB7C2[3E]
2.875: COMM::Sent message: F19C0661E07E624C3EB7C2FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF314731595932325038533531313838373767
2.975: COMM::Recieved reply: F15706AA08
2.977: EEPROM write complete.
2.997: Resetting CCM...
Code:COMMAND RUN THE PROGRAM:
7E $program_routine_address [BLK_SIZE] [OFFSET_16] [DATA...]
; ALDL_REPLY(START)
18 CE F4 9D ; LDY 0xF49D
C6 01 ; LDAB 0x01
ce ff b0 ; LDX loc_FFB0
ad 00 ; JSR,x+00
39 ; RTS
; ALDL_REPLY(END)
; PROGRAM_BLOCK(START)
; INPUT MUST GO AT 61E3 OR MUST REALIGN ALL 61E VALUES.
; INPUT: [BLK_SIZE] [OFFSET_16] [DATA....]
CE 61E6 ; LDX address of data
F6 61E3 ; LDAB block size
5A ; DECB block size--
2B EB ; BMI if b<0 goto ALDL_REPLY (operation finsihed)
F7 61E3 ; STAB block size
3A ; ABX - add blk size to address of data
A6 00 ; LDAA,x - A = data at address of data
FE 61E4 ; LDX write offset
3A ; ABX - add blk size to write offset
8D 02 ; BSR PROGRAM_BYTE
20 E9 ; BRA PROGRAM_BLOCK (loop)
; PROGRAM_BLOCK(END)
; SUBROUTINE PROGRAM_BYTE(START) - A=VALUE X=ADDRESS
; CONFIGURE:
C6 03 ; LDAB 03
37 ; PSHB - push max retry count onto stack
; RETRY LIMIT:
33 ; PULB - pull retry counter
5A ; DEC B (B--) - decrement counter
37 ; PSHB - push retry counter
27 06 ; BEQ COMPLETE
; VERIFY:
A1 00 ; CMPA,X - compare target value with existing value
27 02 ; BEQ COMPLETE - if value is already correct.
20 02 ; BRA ERASE - if value not yet programmed
; COMPLETE:
33 ; PULB - remove retry counter from stack
39 ; RTS
; ERASE:
C6 16 ; LDAB 0x16 - program mode ELAT/BYTE/ERASE
8D 0A ; BSR EEPROM_PROG - call program subroutine
; SKIP 0xFF:
81 FF ; CMPA 0xFF - see if A = 0xFF
27 04 ; BEQ VERIFY - skip programming if FF
; PROGRAM:
C6 02 ; LDAB 0x02 - program mode ELAT
8D 02 ; BSR EEPROM_PROG - call program subroutine
20 E5 ; BRA VERIFY - loop back to verify
; PROGRAM_BYTE(END)
; SUBROUTINE EEPROM_PROG(START) - ACCUMULATOR B = PROGRAMMING MODE.
; LATCH AND SET BYTE
F7 103B ; STAB 0x103B - set eeprom control register from B
A7 00 ; STAA,x - store A (value) at X (location) (write byte)
; SET EPGM (PROGRAM VOLTAGE)
CA 01 ; ORA 0x01 - set EPGM (bit 1) in B
F7 103B ; STAB 0x103B - set eeprom control register from B
; DELAY
3C ; PSHX - save X register
CE 0D06 ; LDX 0xD06 - loop total exec time approx 10ms @ 2mhz clock (6 cycles in loop)
09 ; DEX - x--
26 FD ; BNE REL-3 IF > 0
38 ; PULX - restore X register
; RESET COP (for every 10ms delay)
C6 55 ; LDAB 0x55 ; ARM COP.
F7 103A ; STAB 0x103A (COPRST)
C6 AA ; LDAB 0xAA ; RESET COP
F7 103A ; STAB 0x103A (COPRST)
; COMPLETE
7F 103B ; CLR eeprom control register
39 ; RTS return
; EEPROM_PROG (END)
works.... i think! (the output is correct at least) total overkill for the CCM but definitely will be good with EE and friends.
increased block size to 122 bytes too and seems to work well.
i think the EEPROM writes as well as the flash in EE now. would like to generate a failure code if the verify fails, but it's probably better to just checksum the whole thing afterwards as i'm trying to keep it to minimal ram use, it's 104 bytes right now complete.
Code:; DIFF:
; SEE IF ANY BITS ARE ACTUALLY GOING TO BE SET HIGH.
; IF NOT, WE DO NOT HAVE TO ERASE (AVOID 10MS DELAY)
36 ; PSHA
43 ; COMA - NOT A
A4 00 ; ANDA - AND A WITH MEMORY AT X
32 ; PULA
26 04 ; BNE SKIP FF (SKIP ERASE)
Phenomenal work!! That you're still able to iterate and get the flash routines more and more efficient is amazing. It's why I just chuckle when people try to talk up Hypertech and TunerCats and say Flashhack isn't worth it. They were perfectly acceptable (well, not Hypertech) two decades ago, but there've been huge strides since their heyday. Way to go!
This!! Especially with the Pi Zero 2 W. I'm actually gonna try to pick one up at my local Micro Center tomorrow, they seem to be a phenomenal piece of kit. $15 for a Pi with a 64-bit 1GHz quad-core and N wireless? Yes please!!
Bwahaha, thanks, but nah. I'm not trying to reinvent the wheel as far as the actual serial receive/transmit part goes. I'm simply going to try addressing the hardware serial registers directly to disable the transmit interrupts and set the port low when receiving and then disable receive interrupts and return the transmit port to normal when it's transmit time. In theory it should work just as well as the diode solution. I did test it before, but it could very well have been affected by the delay issue, so I don't know if it actually worked as intended or not. I'll find out tomorrow.
it doesn't take much to be worth $0. whoever says that can stay the hell out of my userbase.Quote:
and say Flashhack isn't worth it
and i love winflash but that thing simply does not completely rewrite the CCM's EEPROM in 3 seconds like flashhack does.
Code:67.860: DEBUG::Executing prepared program CCM_WRITE_NEW on CCM
67.940: COMM::Sent message: F1C006624018CEF49DC601CEFFB0AD0039CE61C6F661C35A2BEBF761C33AA600FE61C43A8D0220E9C60337335A372706A1002702200233393643A400322604C6168D0A81FF2704C6028D0220DEF7103BA700CA01F7103B3CCE0D060926FD38C655F7103AC6AAF7103A7F103B39DB
68.083: COMM::Recieved reply: F15706AA08
68.086: DEBUG::Executed CCM_WRITE_NEW on CCM
68.086: DEBUG::PROGRAMMINGB600[7A]
68.234: COMM::Sent message: F1D80661C07E624C7AB600001E7DFFFFFFFFFF00000000000000000000001E7DFFFFFFFFFF00000000000000000000001E7DFFFFFFFFFF00000000000000000000000000000000000000000000000000000000000000000000000000000000000000220000000000000000000000000000000000000000000727FFFFFFFFFFFFFF31FFFFFF7B
68.603: COMM::Recieved reply: F15706AA08
68.606: DEBUG::PROGRAMMINGB67A[7A]
68.756: COMM::Sent message: F1D80661C07E624C7AB67AFFFFFFFFFF10BF46CF2FEA146646C224442749211424314D9C3A1D201A0DD34BDF37DA233E0C247B09AA550101010101010101010101010101010101010101010101010101010101010101FF3A020000FE000010000000800000000001804020100804028000080002010000000000000000FFFFFFFFFFFFFFFF4A
69.835: COMM::Recieved reply: F15706AA08
69.838: DEBUG::PROGRAMMINGB6F4[7A]
69.991: COMM::Sent message: F1D80661C07E624C7AB6F4FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3A
70.562: COMM::Recieved reply: F15706AA08
70.565: DEBUG::PROGRAMMINGB76E[7A]
70.709: COMM::Sent message: F1D80661C07E624C7AB76EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBF
70.810: COMM::Recieved reply: F15706AA08
70.813: DEBUG::PROGRAMMINGB7E8[18]
70.885: COMM::Sent message: F1760661C07E624C18B7E8FFFFFFFFFFFFFF3147315959323250375335313034303032A1
71.034: COMM::Recieved reply: F15706AA08
71.035: EEPROM write complete.
3 whole seconds! We really need to work on that... ;-)
I've always considered going to some kind of full fledged os for logging, but the downside is it would be slow to boot and use too much power to keep up all the time.
Another tangent to this is I would also like to log the ignition controller at startup. With a microcontroller I can power it from IGN and the code will be doing it's job in about 3 ms.
Edit: also, the CCM woke up immediately it when the micro impersonated it with a 0x10 broadcast.
So I've discovered that the CCM doesn't seem to appreciate foreign devices impersonating it. Wakes up and starts fouling up the bus straight-away.
After some experimentation I think I have a semi-workable logging methodology that grabs about 16 frames before yielding the bus to the CCM (for a whopping 5 frames in the same time space).
The aldl based gauges in the digital dash do! update so I'm hoping everything works ok in a real-world scenario but I'm anticipating some issues with the fuel consumption calculations.
steveo I might want to pick your brains on the .eedata layout. Think I have a handle on about 85% of the data and I have no problem reading the source but I might beg you to save me some time spent reading!
Speaking of blackbox logging and passive dumps of mode1 msg0 message, I just got that brilliant idea to use the built in mode7 schedule of dumping data on the bus. There are 16 slots that can dump the same message or different messages in a preconfigured time interrupt.
So we can configure the pcm to dump needed data without requesting it.
I have some doubts how it will work on ccm configured bus, but some volunteers can give it a try.
I return with more success! I managed to successfully delete the breadboard entirely and maintain the same communication using only the raw RX/TX pins. My first experiment used two hardware serial connections, and that worked, so I moved on to seeing if I could get it down to just one (so that you don't need a Mega to do it). And yep, that works too!
Attachment 17237
Look ma, no external circuitry!
It really was just that 2ms delay in the way the whole time. Magical.
Anyway, here's the new code in case people want to mess around with it. I added as much documentation as I could to it so hopefully it makes sense.
Gonna enjoy myself a nice glass of Dubliner honeycomb whiskey liqueur. Cheers! :thumbsup:Code:/* CCM Interaction Test Sketch for Arduino Mega 2560
This sketch pretends to be the PCM for a 1994 to 1995 Chevrolet Corvette.
It listens for the CCM poll request bytes (40 57 XX XX Checksum),
then sends the appropriate diagnostic string upon receipt.
The diagnostic string is idle values except for coolant temp,
which is either static (236F) or variable (based on ADC0 input).
This sketch works on the 1994 to 1995 Corvette. It may work for 1996.
1990-1991 Corvettes use shorter polls (40 55 6B) and have shorter responses.
To use for a 1990-1991 Corvette, change the sliding window to 3 bytes
and just use the following match code without checksum ifs:
((window[0] == 0x40) && (window[1] == 0x55) && (window[2] == 0x6B))
Then comment out the top lines with output[21] and use the ones
with output[15]. If using dynamic CTS, change output[20] in the
last line of code to output[14].
The 1992-1993 Corvettes use the same poll as the 94-96, but their response
is shorter. To use for a 92-93 Corvette, just comment out the top
lines with output[21] and use the ones with output[18]. If using
dynamic CTS, change output[20] in the last line of code to output[17].
This sketch only works on the Arduino Mega 2560 family.
This is because we're using Serial1, UCSR1B, RXEN1, RXCIE1.
If you want to try it on a different board, change these accordingly.
*/
#include <avr/io.h>
#include <wiring_private.h>
#include <FastLED.h>
byte window[5]; //define the 5-byte-wide sliding window
//byte output[21]= {0x41, 0x67, 0x02, 0xF5, 0x00, 0xCD, 0x87, 0x01, 0x00, 0x00, 0x00, 0x00, 0x88, 0x00, 0x48, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x40}; //define the static CTS message
byte output[21]= {0x41, 0x67, 0x02, 0xF5, 0x00, 0x87, 0x87, 0x01, 0x00, 0x00, 0x00, 0x00, 0x88, 0x00, 0x48, 0xFF, 0xFF, 0x00, 0xFF, 0xFF, 0x86}; //define the dynamic CTS message
//byte output[18]= {0x41 0x64 0x01 0xF3 0x00 0xCD 0x60 0x01 0x00 0x6F 0x0F 0xD6 0x83 0x00 0x51 0xFF 0xFF 0x13}; //define 1992-1993 Corvette static CTS message
//byte output[18]= {0x41 0x64 0x01 0xF3 0x00 0x5A 0x60 0x01 0x00 0x6F 0x0F 0xD6 0x83 0x00 0x51 0xFF 0xFF 0x86}; //define 1992-1993 Corvette dynamic CTS message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0xCD, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x45); //define 1990-1991 Corvette static CTS message
//byte output[15]= (0x41, 0x61, 0x00, 0xEC, 0x00, 0x39, 0x39, 0x01, 0x00, 0x00, 0x00, 0xB4, 0x00, 0x39, 0x12); //define 1990-1991 Corvette dynamic CTS message
void setup() {
analogReference(DEFAULT); //Switch to default reference explicitly
pinMode(A0, INPUT); //Make sure A0 is an input explicitly
bitSet (DIDR0, ADC0D); //Disable digital buffer on A0
bitSet (DIDR0, ADC1D); //Disable digital buffer on A1
bitSet (DIDR0, ADC2D); //Disable digital buffer on A2
bitSet (DIDR0, ADC3D); //Disable digital buffer on A3
bitSet (DIDR0, ADC4D); //Disable digital buffer on A4
bitSet (DIDR0, ADC5D); //Disable digital buffer on A5
bitSet (DIDR0, ADC6D); //Disable digital buffer on A6
bitSet (DIDR0, ADC7D); //Disable digital buffer on A7
bitSet (DIDR1, AIN0D); //Disable digital buffer on AIN0
bitSet (DIDR1, AIN1D); //Disable digital buffer on AIN1
bitSet (DIDR2, ADC8D); //Disable digital buffer on A8
bitSet (DIDR2, ADC9D); //Disable digital buffer on A9
bitSet (DIDR2, ADC10D); //Disable digital buffer on A10
bitSet (DIDR2, ADC11D); //Disable digital buffer on A11
bitSet (DIDR2, ADC12D); //Disable digital buffer on A12
bitSet (DIDR2, ADC13D); //Disable digital buffer on A13
bitSet (DIDR2, ADC14D); //Disable digital buffer on A14
bitSet (DIDR2, ADC15D); //Disable digital buffer on A15
analogRead(0); //Burn an analog reading on A0
Serial1.begin(8192); //Open UART1 at 8192 baud
UBRR1H = (uint8_t)(121>>8); //Switch to 8192 baud at 1x
UBRR1L = (uint8_t)121; //Switch to 8192 baud at 1x
cbi(UCSR1A, U2X0); //disable 2x mode
cbi(UCSR1A, MPCM0); //disable multi-processor mode
cbi(UCSR1B, TXEN1); //disable transmitter for now
cbi(UCSR1B, TXCIE1); //disable transmit interrupts for now
FastPin<18>::setInput(); //tri-state TX1
}
void loop() {
if (Serial1.available()) {
// Slide the 5-byte window
for (uint8_t i = 0; i < 4; i++) {
window[i] = window[i + 1];
}
// Add new bytes as they come in
window[4] = Serial1.read();
// Check the first two bytes for a match
if ((window[0] == 0x40) && (window[1] == 0x57)) {
// Calculate the checksum byte
byte cs = 0;
for (uint8_t i = 0; i < 4; i++) {
cs += window[i];
}
cs = 0xFF - cs;
cs += 0x01;
// If checksum byte matches, send diagnostic data
if (cs == window[4]) {
cbi(UCSR1B, RXEN1); //disable receiver
cbi(UCSR1B, RXCIE1); //disable receive interrupts
window[0] = 0x00; //poison the sliding window
delay(2); //delay to allow ALDL line to settle
FastPin<18>::setOutput(); //reenable TX1 as Output
sbi(UCSR1B, TXEN1); //enable transmitter
sbi(UCSR1B, TXCIE1); //enable transmit interrupts
Serial1.write(output, sizeof(output)); //write the PCM diagnostic message
Serial1.flush(); //wait until transmit completes
cbi(UCSR1B, TXEN1); //disable transmitter
cbi(UCSR1B, TXCIE1); //disable transmit interrupts
FastPin<18>::setInput(); //tri-state TX1
sbi(UCSR1B, RXEN1); //reenable receiver
sbi(UCSR1B, RXCIE1); //reenable receive interrupts
}
}
}
//Read A0 to check status of potentiometer, save to cts byte
output[5] = analogRead(0)>>2;
//Calculate new checksum and save to checksum byte
byte checksum = 0;
for (uint8_t i = 0; i < 20; i++) {
checksum += output[i];
}
checksum = 0xFF - checksum;
checksum += 0x01;
output[20] = checksum;
}
I doubt that will be an improvement, it seems like the aldl protocol is a highly transactional mechanism where the bus master has to largely control the conversation. I was hoping to be able to jam up the bus for one or two more "cycles" with PCM requests after sending a F1 00 command (resume communications) as well as sending F1 08 commands after the broadcast session with no luck whatsoever. It seems like the magic is all in the uveprom of the CCM, and I'm not going to that level of trouble on this stuff. I think what I have will work for the intended purpose without unforgivable compromises.
I'm highly intrigued, will have to investigate further. Cool stuff, keep plugging away at it!
i could experiment with that a bit, but i agree it might not be a really big improvement. the overhead of requesting an aldl message is really low, but i guess we might get a few more extra bytes per message out of it. i'm all for breaking my test bench ECM though.
i've relocated all the symbols in the eeprom block write code to work with EE and i'm testing it right now.
we'd better start thinking of some cool stuff we can relocate to about 450 bytes on the t-side. it's a big chunk of memory.
it will read the bin file for the values so you could just tune with a modified XDF, and will program them seamlessly with no erasing (if the rest of the bin has not changed) and programming will be with no risk (even if it screws a byte up, no way for it to brick it.)
the programming speed is 100% variable, since the block write is doing a per-byte analysis it takes, it's nearly instant if a byte hasn't changed, 10ms if it changes to FF, 10ms if it only sets bits LOW, and 20ms if it sets bits high. so if you're doing normal tuning to a large table where you only change a few values at a time it'll be really really fast.
the other side benefit is that the vin and calibration ID etc will program from the bin now - so those can just be changed in tunerpro as well and they'll always match.
im thinking the onboard eeprom is disabled on the e-side, i haven't pulled the config register to verify that yet.
task complete, this assembly code has now infected EE
you all have a fully permanent tuning area on the TSIDE that we can program quickly and safely, and all you have to do is relocate whatever the hell you want
cheap tequila for me, thanks
spfautch please evaluate contents of write block @ 0xE80 , and thank you so much for showing me programming that eeprom was so easy and 'by the book'
it was really fun to write this code without any assembler or compiler helping, i learned a lot. my only tool other than a hex editor was loading my finished assembly into IDA to make sure all my hand-counted jump points were correct.
Code:171.451: DEBUG::Executing prepared program ONBOARD_EEPROM on TSIDE
171.530: COMM::Sent message: F4C10602003C30CC06AAED00C6029D143839CE0306F603035A2BEAF703033AA600FE03043A8D0220E9C60337335A372706A1002702200233393643A400322604C6168D0A81FF2704C6028D0220DEF7103BA700CA01F7103B3CCE0D060926FD38C655F7103AC6AAF7103A7F103B39D2
171.673: COMM::Recieved reply: F45706AA05
171.676: DEBUG::Executed ONBOARD_EEPROM on TSIDE
171.676: DEBUG::PROGRAMMINGE00[80]
171.823: COMM::Sent message: F4DE0603007E020D800E005362AC9D38363230314B31344A4237343237384A030100FFFFFFFFFFFFFFFFFF00F758973147315959323250385335313138383737FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD4
172.122: COMM::Recieved reply: F45706AA05
172.125: DEBUG::PROGRAMMINGE80[80]
172.276: COMM::Sent message: F4DE0603007E020D800E80FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF4D5920444F47204953204D5920434849454620544543484E4F4C4F4759204F4646494345522EFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDB
172.626: COMM::Recieved reply: F45706AA05
172.628: DEBUG::PROGRAMMINGF00[80]
172.776: COMM::Sent message: F4DE0603007E020D800F00FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF89
172.883: COMM::Recieved reply: F45706AA05
172.886: DEBUG::PROGRAMMINGF80[80]
173.026: COMM::Sent message: F4DE0603007E020D800F80FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF09
173.133: COMM::Recieved reply: F45706AA05
173.136: Onboard EEPROM write complete.
Unbelievable. At this rate, all the work on getting the CCM to play nice with aftermarket computers will be for naught. I mean, with realtime tuning available on $EE, why bother swapping? LOL.
Seriously though, amazing work. Looking forward to interface software catching up to all the progress made on the hardware side. Maybe something spiffy like doing realtime feedback using a wideband O2 in map trace mode?