dimented24x7

iTrader: (2)

Ive been tinkering with making a high speed ALDL so I can actually get some useful info out of the ALDL. Started out with trying to use the actual ALDL output but I have no idea how to set it up right so I gave up. Long story short I tried again with using one of the empty outputs meant to drive the A/C compressor and had more success. Basically I just have a resister and some wires hooked up to a com port and when the output is off, the voltage goes high. On, the voltage is pulled down, simulating a RS232 signal. Kinda hard to get it to work w/o a scope. Had to look at the output in ascii and use the binary representation of the output to get some idea of what I was putting out. In the end I got it to work at 19,200 8-N-1. Kinda long when all the instructions are added up so I dont know how Im going to get it to fit in place of the present ALDL so I can send one bite rather then one bit. Guess Ill have to clear out some stuff in the spark and fuel loops to make some extra room time wise.

dimented24x7

iTrader: (2)

Heres the code...

The code is in one of the RTS routines. If I can get it in place of the ALDL stuff Ill be able to send a full 20 bytes 8 times a second or get 8 fps. Whats interesting is that Id thought I would have needed more delay then I did. How long does one instruction take to complete timewise?

oh, the 'u' character was one of the characters I put out to test it. That and some of the No OPerations will be replaced with working code to cycle the output bytes in the end.

RBob

iTrader: (1)

One clock cycle is about 945 nsec. Need to get the cycle count per instruction from the pink book or the as11 assembler.

The ALDL serial hardware uses a single shot (SS) output from one of the chips. The SS PW is either long or short depending upon a 0 or 1 bit being transmitted (it isn't real ASCII async protocol).

Then another routine 'kicks' the SS every 6.25 msec (160 HZ rate).

RBob.

MonteCarSlow

I have an idea to do a "pseudo lockers" by adding one of those parallel-to-USB modules from Futurlec into the CPU's memory map and adding some code to dump the 256 bytes of ram at X times per second in place of the ALDL... consider it a $60 mask option that I was dreaming up.

Bit banging at 19.2k might not work out because it's a CPU intensive thing to do, but I'm not familar enough with the code and hw to know how tight the timing is to say for sure.

Ernst

dimented24x7

iTrader: (2)

RBob,

My 8063 has that as well. The SS bit is toggled in the vector handler every time its run and then the ALDL '1' or '0' is set by the aldl routine after the MAP lookup and error handling. Thing is I have no idea how to set up the ALDL for the proper pulsewidth and w/o a scope I have no way of knowing whats coming out of it. On top of that I think it would take more instructions as well. I did add up all the cycles but it seemed to come up short. Something like 42 cycles. At 19200 baud, id have ~52 usecs per bit if Im not mistaken, and that would equate to ~55 cycles but what I have is less then what I should have. I went though and accounted for whether the instruction was imm. or ext. and what not but still to no avail. Am I being dense and missing something

Monte,

I wouldnt transmit all the time, just transmit at 19,200 baud, not 19.2 k. Only transmit one byte when the ALDL routine is called, or so thats the idea.

dimented24x7

iTrader: (2)

opps... NVM.. found out why it was coming up short. Cant add. So its like 500 instructions almost. Really going to be a head scratcher as to where to put it. One thing I can say, its going in no matter what. I want my simple plug n' chug serial port.

RBob

iTrader: (1)

With 6.25msec between each 160Hz interrupt there is 6613 clock cycles available. Within those cycles a minor loop (fuel or spark) and a major loop (one of sixteen) need to be executed.

Some of the major loops overrun this anyway. All depends upon path taken.

To regain some time several major loops do nothing but loop through the RAM with a read/write cycle. These are not needed in our environment.

Almost forgot, the SS's are probably being programmed in 15.26 usec PW per bit. So a $11F value gives a 4.38 msec pulse. I've never checked that. . .

RBob.

dimented24x7

iTrader: (2)

Well with the old aldl stuff taken out and adding in the previous VATS stuff that I took out I freed up about 250 cycles that the ecm would normally execute along with the minor loops. Problem is that I add in an additional 240 some odd cycles with the faster transmission routine. Is there any way that I can find out whats being overrun? Like I said I dont have a scope so I dont have much way to measure stuff.

Thing that sucks is that I can have the code execute faster, say at 38,400 baud. But.... the quad drivers or whatever they are dont seem like theyll switch that fast. Dont get anything usefull. Guess it makes sense since theyre intended to drive lightbulbs, relays, and stuff like that and not do high speed switching.

dimented24x7

iTrader: (2)

I decided to live dangerously and stick it in along with the standard aldl. Option bit set causes the standard ALDL routines to be skipped and the one I wrote being run. Its only on the test bench for now. Now the second problem. How should I take the data in? I was thinking of maybe jsut using a terminal to save it as a string of plain text and then some how write something in C to decode and format it into a text file. Havnt done any C++ in years. I still ahve my copy of Borland C++ 5, which was state of the art when I bought it in high school, so at least I can try and write something. Anyone have any suggestions on how to do some simplistic datalogging?

RBob

iTrader: (1)

I just save the data as it comes in then break it down later. The data is binary so it needs to be saved to a file opened in binary mode. Also need 8N1 for the com specs.

If you have the HDS program that comes with Lockers it will do just that (save as binary). Start HDS, set teh baud rate, save setup (for next time), then use F10 to open a collection file.

RBob.

dimented24x7

iTrader: (2)

Sounds easier then using the terminal program, which works to capture the data but its kind of clumsy to use. Where can get lockers these days?

dimented24x7

iTrader: (2)

Well... It all works and I can take in raw binary and convert it over to actual data like rpms, pw etc. using some stuff I wrote in C except.... None of the friggin commands for reading in characters from a file will take in 0x0D = 13 dec = 'carriage return' in ascii. Is there anything simple that will jsut ignore the actual data and take it in? I know its more of a computer question but WTF??? The file pointer advances but it just skips it and keeps going!

RBob

iTrader: (1)

That is cool that you have it working, really is. As for the file if you are using BASIC there may not be a way around this problem. Way back it was the one area that was a thorn.

If using C/C++ then be sure to open the file in binary mode ("rb" vs. "rt").

RBob.

dimented24x7

iTrader: (2)

forgot about that... Yes. That definatly fixes the problem.

dimented24x7

iTrader: (2)

I got around to trying it in the car. Very cool. Finally the frame rate is fast enough to show whats actually happening, like seeing what events lead up to detonation on tip in rather then just seeing a knock count and one points worth of rpm and map data. I could even see the TC stall at 1800 rpms before the car began to move. Neat stuff. Wasnt real excited before but seeing actual usable data changes that. Adding a WB-O2 would finally mean that I could finally start tuning rahter then just guessing and flying by the seat of my pants. Still dont know to what extent the extra 200 or so cycles affect things. Guess ill only use it when I have to and just use the slo-mo aldl port and routine the rest of the time.

Grumpy

That's neat stuff!.

Why not find a remote *test track*, and run it?.
Maybe find some routines that aren't really needed, and maybe JMP past them?.

dimented24x7

iTrader: (2)

I have been clearing some junk out, like the slope SA, VATS, PE adder spark, VE adder, etc since I either dont use them or dont need them anymore since Ive changed stuff. Hopefully I can gain some of the time back. Even if I could get all the time back I probably wouldnt use it when I didnt need it. The standard complement of diagnostics stuff along with WinALDL is very useful for P/T tuning and diagnostics, even if its slow. The HS one has 20 bytes/frame, but it would be a waste to use them for status words and stuff when I dont really need them.

dimented24x7

iTrader: (2)

Just by pure luck I figured out why it didnt work at 38,400 baud. About to delete some of the files to clear out the clutter in my prom folder and I saw in the code for the faster routine that I mistimed it so it wasnt working. Works at the higher baud rate so that almost halves the time required to run it each pass, which equates to me now almost having some extra time again for other stuff. So, assuming there are no unseen forces that will stop it from working, it now goes at 38,400 baud/1,280 bps so I have my lockers type datalogging w/o actually having to have an edge connector.

RBob

iTrader: (1)

You should now be able to double up the number of bytes per packet. Will take the same amount of time as the 19.2Kb rate did but there will be more data. Add stuff like the delta TPS% used in the AE routine. Plus both the async & sync PW's. Then the SA, and the . . .

Just as an FYI the Lockers setup transmitts ALL 256 bytes of RAM at 17 times a second @ 57.6kb. Plus six 10-bit ADC channels within the same packet as the ECM data. Nothing quite like it.

RBob.

dimented24x7

iTrader: (2)

I knew before that your lockers could do the whole ecms memory plus extra A/D channels at almost 2x the framerate of what I have, which is a measly 20 bytes of ram + maybe a WB-O2 8 times a second, so id be talking out my *** if I said it was a good substitute. Thats the whole reason I did this was because I was becoming green with envy that you guys could xmit everything at 57 kbps while all I could do was .160 kbps though the ALDL. The 8 frames per second is better, though, and hopefully good enough for WOT datalogging. The things im xmitting now are: the entire engine run time, rpm, tps, map, int, blm, sync bpw, async bpw, knock counter, o2, and SA with one byte left over. If I knew how much time was available Id do 2 bytes per pass. As of now it pretty much takes the same ammount of time that the origional ALDL xmit routine took so at least its not changing things up too much.

Craig Moates

I have also been pursuing faster ALDL comm, but for the 1227730/749 8192 stream. It's already fairly fast, but there's so much extraneous info, and for tip-in WB tuning, it's pretty tough.

So the thought I had was this: Just reduce the size of the ALDL packet down to what is critical. Rather than dumping 63-byte packets, it'd be more like 7 or so. Can I do this just by modifying the source code to specify the message length of the Mode1 response and then redefine each databyte reference, blanking out the bytes of the superfluous variables? I mean, just bump up the 7 addresses of interest and leave the table size the same, just specify the size at the top & leave the 'fat' in there?

I've done it, but haven't tested yet.

Another option would be to get rid of the polling delays and header bytes, and just stream the data continuously. I figure you could get about a 10x speedup on this stuff pretty easily in terms of packet rate.

Any thoughts? Not trying to hijack a thread here, but thought the line of thought was pretty similar in some respects.

RBob

iTrader: (1)

The answer is: D) All of the above.

Easiest would probably to create your own packet address list in memory and add it to the chatter list. Using this method can output up to 16 packets a second w/o requests.

Just size the packets so they come one after the last and repeat the data within the packet to pad it to the right size.

RBob.

Craig Moates

Cool beans.

I was talking with Mark, and he thinks that this might be something that we can incorporate into the ECU file. So you could just go into TunerPro and essentially spec out what you want your ALDL stream to be.

It would be a little rough in terms of using the present format, such that you'd have to know what 2-byte locations go with what, but eventually it might be possible (with a fair amount of work) to get it pretty darn user-friendly...

JPrevost

I already did that. It's an ecu file hosted on your file share.
http://www.moates.net/files/3)%20Binary%20Editor%20Definitions/7747%20and%208746%20ALDL%20patch.zip

dimented24x7

iTrader: (2)

Just out of curiosity, how is the '7730/'749 ALDL stuff set up compared the 8746 or any other C3 for that matter? It uses different onboard hardware specifically for communications, no?

RBob

iTrader: (1)

Has a UART.

RBob.