Bringing TBI and Multi Port Fuel Injection to a New Level.     EFI Conversions and Tuning! Seattle to Portland! E-mail Tuning Consultant!
Page 46 of 46 FirstFirst ... 36414243444546
Results 676 to 686 of 686

Thread: DIY LTCC or similar system for LT1s

  1. #676
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    965
    I am almost setup for the first test of firmware upload.

    I will try first usb serial connection and than will hook up the bluetooth more testing. A quick question is about rx and tx between board and serial cable. Should they be straight or crossed. tx=>tx rx=>rx or tx=>rx and rx=>tx.

    The bluetooth module have some state pin[PIO9] that can be repurposed as dtr. STock is set to pull pin high on connection. I change it to pull it low on connection.
    The module is HC05, cheap china crap for around $3. Will see it how it goes later.

    I am having postman coming tomorrow so it is getting exciting.

    Some voltage protection circuits will be nice addition for the later revisions if there are any. The pcm have all kind of them and Tom H can give some ideas how it is wired.

  2. #677
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    604
    Quote Originally Posted by kur4o View Post
    A quick question is about rx and tx between board and serial cable. Should they be straight or crossed. tx=>tx rx=>rx or tx=>rx and rx=>tx.
    I think they should be crossed. I.E. tx on the controller board should pin to rx on the serial module. But it's a crapshoot with only two outcomes and nothing can be permanently harmed by guessing wrong.

    Quote Originally Posted by kur4o View Post
    The bluetooth module have some state pin[PIO9] that can be repurposed as dtr. STock is set to pull pin high on connection. I change it to pull it low on connection.
    The module is HC05, cheap china crap for around $3. Will see it how it goes later.
    No wisdom to share here other than it should honor whatever the host device is telling it to do. This pin is making the AVR reset to the bootloader and then avrdude sends a pre-defined sequence (may just be holding tx low for a certain # of milliseconds) and that's what tells the bootloader to switch to serial programming mode instead of jumping to the program start vector.

    Quote Originally Posted by kur4o View Post
    I am having postman coming tomorrow so it is getting exciting.
    I'm just as excited. The reason I killed my prototype board and a D580 coil by connecting the battery clamps backwards is because something new had just arrived (I forget if it was the adjustable voltage regulator or something else) and had the "christmas morning jitters".

    I also have a DIY wideband controller arriving from Sweden in the next few days, and already have the christmas morning jitters for testing it out. But I'm going to be cautious with it because the car is running so well I would be sick if I broke it (the car) by adding something like this haphazardly.

    Quote Originally Posted by kur4o View Post
    Some voltage protection circuits will be nice addition for the later revisions if there are any.
    If you're meaning reverse polarity protection, it's just putting a large diode between the + and - inputs, backwards. The idea is if connected backwards it will conduct and blow a fuse (if there is one) before any components are damaged. It's probably worthwhile, but if I work it into the PCB design (along with an onboard fuse) it will only protect the PCB. I intended to add this when designing the schematic, but pushed it off for later and only realized it had been forgotten after the magic smoke had already been released.

    I'm sure there is extensive reverse polarity protection in the PCM. I don't have enough fingers and toes to count how many times my non-mechanical type friends have called me in a panic because they got the wrong battery at the parts store and connected the terminals backwards, and all of a sudden nothing turns on. My robotic response is always "go buy a bulk pack of AGM fuses and start replacing everything that looks even remotely stressed".

  3. #678
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    965
    A quick update.

    I got some d514a[stamped 12573190] coils with harness in great shape. No corrosion at any of the terminals. Still have to test them for proper operation.

    Also figured how to upload firmware through usb. Even did some datalog on the avr. Not sure how much time it takes to reboot but there is some considerable delay between power up and the time it starts responding to pid requests. I just hope that logging is some low priority.

    A thought about the resistors value. At what temp should I measure them and does it worth the trouble since the resistance will vary with temperature anyway.

    Next on the list is to try bluetooth and clean up the wiring and test the coils and assemble the opti for testing.

  4. #679
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    291
    The Arduino boot loader itself has a startup delay, that may be what you’re experiencing. It is what allows for quick reprogramming over serial. You can nuke the bootloader and burn the program directly to the chip (“export binary” in the Arduino IDE; it’ll save 2 HEX files into the project folder, one with bootloader and one without), but doing so means you can only reprogram the chip using an ICP header and associated ICP programmer.
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

  5. #680
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    604
    NomakeWan: his board lacks an ICP header, not that it's needed...

    Once again (the dad in me wants to add: "for the umpteenth time"), make sure the DTR line between the usb / bluetooth adapter and the controller board is disconnected when you're doing this. If not the bootloader programming delay could be invoked and that takes about 2 seconds. The only time the DTR line should be connected is for uploading to the flash. Put a switch between the controller board and the uart adapter or something.

    Edit: If I owned an airplane, and had a nickel for every time I've uploaded a new flash image, forgotten to disconnect the DTR pin and then cranked the engine over with a serial logger pulsing the DTR line only to have it flood because of the programming delay, I could kill you all by raining bags upon bags of nickels down on you. But I wouldn't do that, because I like you. :-D

    Also, don't try spamming the uart with requests while powering on - I've never tested this but it might potentially cause problems.

    This is an approximation because I don't really want to take the time to build a proper and accurate timing mechanism, but from power on to the end of the setup routine takes less than 8 ms for me. At that point you're in the main loop. If you want to see it visually, at the very end of the setup() routine put a line like:

    Code:
    Serial.println(F("ready"));
    Open a serial monitor program (i.e. [ctrl]+[shift]+[m] from the Arduino IDE) and then apply power to the board. If you can perceive a time delay with your senses alone (no instrumentation) you'd better lay off the caffeine / amphetamines / cocaine.

  6. #681
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    965
    After some very weird serial communication problems I had to bring in some serial loggers to identify the issue. It is always harder than needed.

    First I got a response each 10 pid request after that each 20 pid request. Than after some logs I found that the controller response with some extra bytes in the end. It turns out that this is for new line and carriage return.

    So unless these 2 bytes are added to the string you send an all kind of weird issue can be expected.

    I guess a small update to the read me can be added, stating that for proper communication NewLine and CarriageReturn must be enabled.


    Now everything works as expected. And it wasn`t 8ms delay perceived. It was something like 30-60+ seconds until I send 10 pid requests.
    I even try bluetooth firmware update but it didn`t work the first time[I had to revive it with usb upload]. I will give it another try when the wiring is cleaned up. Now it is a real mess.

  7. #682
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    604
    Sorry, I failed to mention that the CR and / or LF bytes are sort of assumed when dealing with ASCII over RS232.

    Did you follow my suggestion and add a Serial.println(F("ready")); at the end of setup()? That's the only real way to know when it's ready to function.

    Also, is your DTR line disconnected when you do this? There's no point trying to proceed until you answer that.

  8. #683
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    965
    Quote Originally Posted by spfautsch View Post
    Sorry, I failed to mention that the CR and / or LF bytes are sort of assumed when dealing with ASCII over RS232.

    Did you follow my suggestion and add a Serial.println(F("ready")); at the end of setup()? That's the only real way to know when it's ready to function.

    Also, is your DTR line disconnected when you do this? There's no point trying to proceed until you answer that.

    Didn`t have a chance yet.

    Yes dtr is disconnected but I tested the communication connected and works either way disconnected or connected. It could be windows drivers.

    I think the issue was the extra bytes[NL and CR] that are not send by standard comm terminals. Only arduino port monitor have that built in and I specifically get it long time ago to program my bluetooth module.

  9. #684
    Fuel Injected! spfautsch's Avatar
    Join Date
    Apr 2015
    Posts
    604
    Ok, so once again just so there's no ambiguity...

    DTR is connected to the AVR's reset pin. When it is pulled high (or low, I forget which) by the host computer it tells the AVR to jump to the start vector. When this happens with power applied (there's a brown-out detection bit internal to the AVR that will not be set) the bootloader will wait for avrdude to send some data to tell it to start the flash routine. This has approximately a 2-3 second timeout before the bootloader then jumps to the beginning of "user" program space.

    DTR is not required for serial communication, only to reset the AVR so the programming mode in the bootloader can be accessed without having to manually reset the AVR (Arduino boards have a button to do this).

    If you're able to talk to an OBDI / OBDII PCM with whatever serial device you're using, it should almost certainly work with this application. However, the bluetooth module I have can be configured to use DTR or RTS on the sixth pin by bridging a configuration pad with solder so maybe yours has something similar. Drivers shouldn't be an issue, but port configuration can be. I use the gnu utility stty to configure the port before opening it. This is the command line I have to use.

    Code:
    stty -F $port 115200 -brkint -icrnl -imaxbel -opost -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke min 0
    I would suggest the Serial.println() thing mentioned previously. This will not only tell you when the board is ready to respond to logging, but it will also show you if the AVR is being reset after power has been applied.

    Don't attempt to communicate with the board until you see it send data at the end of the setup() routine. You could be unintentionally crashing the AVR.

  10. #685
    Fuel Injected!
    Join Date
    Mar 2013
    Posts
    965
    Some indepth experiments.

    DTR connected. Power up the board with usb unplugged from PC. Status led is solid. Plug in the usb to PC status led blinks for 2-3 seconds.
    Open serial monitor the board communicates fine, compile a sketch and upload to board. The status blinks than turn off, When program is done it goes solid again.
    The board is power up all the time, Definitely windows driver makes the difference. I guess the only time it resets with dtr on is when usb is plugged to PC and than when a firmware upload is initiated. Of course disconnecting dtr is a must with running engine.

    I tried the suggested ready print but I am getting an error "n is not declared in this scope".

  11. #686
    Fuel Injected!
    Join Date
    Jul 2019
    Location
    Orange, CA
    Posts
    291
    Quote Originally Posted by kur4o View Post
    I tried the suggested ready print but I am getting an error "n is not declared in this scope".
    I just tried it. I copied the text from his post, and pasted it just before the final } in setup. It verified and compiled properly.
    Attached Images Attached Images
    1994 Corvette (Automatic)
    1995 Corvette (Manual)

Similar Threads

  1. Which TBI system is better?
    By KeyAir in forum GM EFI Systems
    Replies: 41
    Last Post: 05-13-2019, 09:39 PM
  2. Hard start 93 LT1 with LTCC Ignition Mod
    By beestoys in forum GM EFI Systems
    Replies: 0
    Last Post: 05-18-2015, 08:58 AM
  3. ABS system?
    By K1500ss4x4 in forum Gear Heads
    Replies: 3
    Last Post: 02-06-2014, 06:21 AM
  4. Vortec EGR System?
    By EagleMark in forum OBDII Tuning
    Replies: 40
    Last Post: 06-02-2013, 10:07 PM
  5. Quicker way to do Spark Hook test on the street for LT1s and others?
    By sherlock9c1 in forum Fuel Injection Writeups Articles and How to New and Old
    Replies: 15
    Last Post: 03-03-2013, 01:52 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •