Yay, congrats
Yay, congrats
-Carl
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.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)
Last edited by steveo; 11-02-2021 at 06:22 AM.
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.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
it doesn't take much to be worth $0. whoever says that can stay the hell out of my userbase.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.
Last edited by spfautsch; 11-02-2021 at 05:27 PM.
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!
IMG_2128.jpg
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!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; }
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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.
Last edited by steveo; 11-03-2021 at 05:07 AM.
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?
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
Bookmarks