C3/P4 open hardware/software project?

[jdarg]

Hello everyone, I've been lurking for a while but this is probably my first post.


Is anyone interested in PCBs and/or kits for arduino-based tuning hardware? I have a bench setup that allows me to dump PROMs, edit BINs on Android with an Android BIN editor I've been developing for about six months now, flash BINs back into the ECM, and do datalogging for 160 baud C3 ECMs, specifically the 8746 at this time. This would support communications over both USB and Bluetooth, on Windows and Android.


I've been thinking about maybe doing a Kickstarter project to raise funds to take this to the next level - essentially to procedure additional C3 and P4 ECMs, and develop a custom PCB layout that would shrink this small enough to fit into the ECM instead of hanging off a ribbon cable. Contributions would be rewarded with blank PCBs, DIY board/parts kits, or fully assembled boards depending on the donation amount. The hardware design, PCB layout files, and Windows/Android software source code would remain free and open.


This has a lot of other possibilities too...the same board could drive relays to activate aux lighting, air lockers on 4x4 vehicles, perform VSS pulse correction upstream from the ECM and dash to adjust for tire/gearing differences, add digital or analog inputs to the ALDL stream, GPS, fan controller, etc.


Is this something folks around here might be interested in? The hardware will be really inexpensive with enough support. The custom PCBs are probably the costliest part - the Atmel microcontroller and other ancillary parts that drive the whole thing are actually really inexpensive these days. I probably have about $40 invested in my current hardware and this can be driven down by ordering in quantity.

Thoughts?

[EagleMark]

[QUOTE=jdarg;33724

Is this something folks around here might be interested in?

Thoughts?[/QUOTE]You've found the most likely bunch, I'm sure a lot would be interested and even jump in to help since it's open source.

The only issue I see about looking for donations to get you going is... well... you've never participated in anything here so we have no idea who you are or if the project is legit... or scam?

Post some pictures, code, etc.. see if anyone is interested. ALDL Droid sure took off here.

[RobertISaar]

certainly interested, i was looking into doing something very similar a while ago, just never had the time to get into it.

so, the purpose of that kickstarter would be to collect ECMs to see what kind of dimensions you could get away with for the custom arduino board? or did i miss something?

[jdarg]

Thanks for the feedback guys, keep it coming, please.

Kickstarter strongly recommends putting a video together, so that's probably what I'd do, but I didn't want to invest the time in that if there was basically no interest on the few forums that are still active with GM OBDI.

If I made a video today, I could show my Nexus 7 read a PROM wirelessly, modify it, flash it back in over Bluetooth, then datalog over Bluetooth (using Tunerpro, since I haven't even started implementing ADX support in my Android app yet.) If I did it next week, there would be more capability. I probably invest about 8-12 hrs. a week into this at this point.

The kickstarter campaign would be used to fund custom PCBs that will (hopefully) fit inside the ECM. Let's say for cost or layout reasons, it had to hang off the ECM on a ribbon cable like an Ostrich - would that be a deal killer for anyone? With the funds I raise, I have to meet the reward obligation before anything else, so I'd have to figure out how many PCBs I need to "sell" to offer them for $20 shipped, and then set my Kickstarter goal at that price. Anything extra would allow to offset the costs associated with continued development, specifically obtaining more ECMs so we can support them. I think most of the C3 ECMs would pretty much work as-is with whatever my final product for the 8746 is. The P4 stuff is a different story though and will need a little more effort.

I realize I'm not too active here, more so on Thirdgen.org, although I don't post there much either. Any kickstarter campaign is a risk so that's not unique to this project. There's never a guarantee you will get your rewards from anything you donate to. If you can't stand to lose $1-$20 then don't contribute. My goal is to get enough supporters to where I can do a run of bare boards for $20 including US shipping and at least break even. If I can't get enough support to make Kickstarter feasible, not sure what I'd do, maybe sell small quantities of plug and play modified ECMs on ebay.

Does anyone reading this thread have the time and skills to contribute any of the following? If so please let me know.

Coding - Windows, ios, Android, Linux, or 68xx assembly
Graphic arts/user interface design
Electrical engineering/digital logic design
Basic electronics - soldering components to PCBs, for example
Communications - technical writing, marketing
Web design/LAMP

[RobertISaar]

6811 assembly is relatively simple for me....
layout/prototyping, less so, but i have some experience with it.
soldering? soldering is life. well, so long as i can do it with an iron, i need to get into hot air stuff still.

[andcvi]

Hello jdarg,

I run a 1227747 ecm on my Toyota Hilux 22R which I modified to use a 28c64 eeprom and I certainly would be interested in your product.

I especially like the other possibilities

"
This has a lot of other possibilities too...the same board could drive relays to activate aux lighting, air lockers on 4x4 vehicles, perform VSS pulse correction upstream from the ECM and dash to adjust for tire/gearing differences, add digital or analog inputs to the ALDL stream, GPS, fan controller, etc."

As EagleMark said, I would like to see some pictures or video of your project before I would consider donating.

regards andcvi

[steveo]

i'll help if i can, i've been playing with a similar project for a while now

i built an obd-i datastream swiss army knife kinda thing in linux with c, mine is more oriented towards a real pc like a raspberry pi that can double as a car pc as well. it's working 100%, just needs modules written and people to write datastream definitions for other ECMs. i dont care about supporting 160 baud ecms either.

things like aldldroid are cool for display/logging and all, but having a full fledged kind of 'daughterboard' that can function as a controller for whatever you want is what is far more useful.

i wanted a device like the raspberry pi as my target just because you have many more prepherial options; you can datalog constantly to a giant flash drive without having to cart a seperate laptop around, and since there are so many usb to gpio boards, you literally will never run out of versatile i/o pins if ya need them

i would buy one of yours just to have one, though; and might be able to contribute some code or ideas?

[Six_Shooter]

Seems to be an interesting idea, especially being in school for EET (Electronics Engineering Technology).

[ruhled]

6811 assembly is relatively simple for me....
layout/prototyping, less so, but i have some experience with it.
soldering? soldering is life. well, so long as i can do it with an iron, i need to get into hot air stuff still.

Do you run any vehicles with a C3 ECM? I could use an "impartial tester" in the near future.

[ruhled]

i'll help if i can, i've been playing with a similar project for a while now

i built an obd-i datastream swiss army knife kinda thing in linux with c, mine is more oriented towards a real pc like a raspberry pi that can double as a car pc as well. it's working 100%, just needs modules written and people to write datastream definitions for other ECMs. i dont care about supporting 160 baud ecms either.

things like aldldroid are cool for display/logging and all, but having a full fledged kind of 'daughterboard' that can function as a controller for whatever you want is what is far more useful.

i wanted a device like the raspberry pi as my target just because you have many more prepherial options; you can datalog constantly to a giant flash drive without having to cart a seperate laptop around, and since there are so many usb to gpio boards, you literally will never run out of versatile i/o pins if ya need them

i would buy one of yours just to have one, though; and might be able to contribute some code or ideas?

That sounds like it has a lot of potential. The reason I didn't go the pi route is the physical size and cost. My goal was to build something that costs less than an ALDL cable but is much more flexible. Two years from now pi's will probably cost $10 though. You might want to consider just adapting your code to use the relatively standard ADX definition files. You'll have a much easier time doing that than getting people to adopt a new format, IMHO.

[ruhled]

So I'm going to outfit my 8746 with a proper 24-pin DIP socket and ribbon cables to the arduino breadboard and then I'll work on making a short video. Right now its just a bunch of 24 gauge wire wrapped around the existing PROM carrier pins so it looks really ugly right now. My goal is to complete a video in two weeks.

I finally finished up a rough Windows-based flash utility this morning. I can flash a 4K BIN into the flash chip using a series of ECHO commands in a DOS/Windows batch file - no external dll/exe files needed. It doesn't get any easier. This means it will be very simple to control it from any programming language that can execute a shell command - pretty much anything.

The arduino essentially acts like a modem. Upon power/reset, it just forwards the ALDL stream out of the serial port. Otherwise I can send it a sequence that places it into "command mode", where I can then switch the serial out to a parsed ALDL stream (i.e. text that says "Battery Voltage: 12.3v", "MALF 12", etc.) or give it a range of other commands to erase a bank, write a byte, write a byte packet, read a byte, dump the bank, or resume normal ALDL streaming mode. ALDL streaming mode is fully compatible w/ TunerPro RT. It accounts for the TTL/RS232 stuff and inversion within the Arduino when redirecting from ALDL pin E to USB serial out, so TunerPro RT v5 understands it correctly. The arduino basically does what a MAX232 or 2-transistor cable would do.

Does anyone successfully use a 1-transistor cable in conjunction with a 160 baud ECM w/ TunerPro RT v5? From my testing, I don't think its supported by TunerPro v5, but a confirmation from someone else would be nice.

[RobertISaar]

Do you run any vehicles with a C3 ECM? I could use an "impartial tester" in the near future.

P4 and P66 only for me.

[ruhled]

P4 and P66 only for me.

Darn. If anyone else out there still uses a C3 and would like to be a tester, please shoot me your PM.

[Six_Shooter]

I have an ECM test bench that I have C3 adapter harnesses for, along with P4.

[steveo]

That sounds like it has a lot of potential. The reason I didn't go the pi route is the physical size and cost. My goal was to build something that costs less than an ALDL cable but is much more flexible. Two years from now pi's will probably cost $10 though. You might want to consider just adapting your code to use the relatively standard ADX definition files. You'll have a much easier time doing that than getting people to adopt a new format, IMHO.

i considered using ADX, but i wanted it to be as lean as possible with barely any dependancies, i didn't even want to link to an XML handler.

the other consideration was that i wanted to require some different things in my definitions that the ADX format spec doesn't have. i wanted to optimize it specifically for 8192 baud GM ECMS, which leaves a lot of useless crap in the adx spec that i dont need, since those datastreams and the method by which they are queried is somewhat uniform. in my eyes, either you support an up to date and complete version of a format spec, or you dont support it at all... and i didn't want the reverse (have my users put extra crap in their ADX that wouldn't port back to tunerpro later).. so i just bit the bullet and said if you want to use it, you'll have to convert.

my config file parser is probably 20 actual lines of code, it just parses parameters based on an equals sign, and terminates based on whitespace unless it encounters a quoted string (anything to the left is a parameter name, anything to the right is data), and it has very strong fallback defaults... so you can create defaulty configs with common options much more quickly. it's a bit ugly, but you can, if you want to, create beautiful config files with it, since anything not adjacent to an equals sign is not parsed (comments are just anything without an equals sign, etc..), and there's no weird nesting or inheratance.

i'll only support and test nast1 and EE out of the box in my case

to work around the limitation of adopting ECMs that i dont have time to write definitions for, i do plan to build a rudimentary ADX converter that'll at least kick start building my proprietary format from an existing adf, at least for all the data definitions themselves.

[steveo]

my plan is around $100 with a small color TFT VGA screen (using chinese made back-up camera screens which are designed for dash mount), a switch-mode power supply, and 32gb of storage, and a usb wireless adaptor.

that doesn't include an FTDI based aldl cable (the recommended solution, since all it has available are usb ports, and the ftdi userspace driver is perfect.

that puts it in a configuration which has enough balls to do car-pc duty as well as full-time datalog continuously, and connect to your home network automatically from your driveway so you can download logs or upload music, whatever, but barely has enough power to run a keyboard afterwards, so it's time for a powered usb if you want to expand its capabilities. i plan to run a bigass SSD full of music which can store logs too.

it'll definitely spiral out of control price-wise at that point.

since it's linux-based, a lot of necessary functions are built-in, such as using logrotate to auto-compress your old log files, and chuck them automatically as you run out of room.

one of the biggest limitations of the pi is the lack of a realtime clock.

now, yours will be way more optimal for power consumption, space, and price.

i have lots of utility ideas for this type of device i'm willing to help write into your project; once i develop them properly..

the type of instruments this kind of device can drive are great.

i have a really fun concept i'm writing designed to be a shift synchronizer gauge, that displays the closest gear to your current RPM, and how far off you are from synchronized with that gear (with a centering needle sweep kinda thing). you just feed it ratios and run a calibration routine through each gear for setup to get it 'just right'.

it'll help you nail the perfect double clutch every time under any condition, or help you recover from a long neutral coast down a hill and nail it back into gear perfectly at whatever speed with no effort. i discovered it has the cool side effect of inherently measuring clutch slippage at the same time, giving you some advance notice when your clutch is about to fry itself. so far it's working very well.

[buddrow]

Darn. If anyone else out there still uses a C3 and would like to be a tester, please shoot me your PM.

I am using a c3 '7747 in my current project and would enjoy participating in the project.

[ruhled]

to work around the limitation of adopting ECMs that i dont have time to write definitions for, i do plan to build a rudimentary ADX converter that'll at least kick start building my proprietary format from an existing adf, at least for all the data definitions themselves.

Good idea - a converter will help a lot. When I had to implement the XML parsing for the v1.5 XDF files, I didn't end up using any XML libraries on Android. The format is so flat it just isn't really necessary and even basic parsing with string functions was quite a bit faster from some real rudimentary testing I performed.

[ruhled]

I am using a c3 '7747 in my current project and would enjoy participating in the project.

Thanks I'll keep you posted. I'm going to need a couple of testers at some point.

Do you know if the 7747 always sends ALDL data at key-on, or do you have to kickstart the stream w/ a 10K resistor? I don't have the 10K kickstart code/wiring yet, but that should be really simple to implement.

[Six_Shooter]

'7747 is always transmitting data, and is part of what makes it different than the 8192 baud ECMs, since the logger (laptop, tech 1/2, etc) need to sync up to the datastream.

The only ECM that needs the 10k ohm resistor is the 1227165 in the F and Y-bodies using $8D, and only for certain data.

[jdarg]

BTT

Bluetooth is now functional in the hardware and has really good range on the bench. I'm able to reach it from the opposite corner of my home from where the ECM is sitting. I need to put it in the ECM now, w/ the cover on, and see how it does. I suspect the access cover would need to be modified or left off for it to work reasonable well from even a few feet away but maybe I'll get lucky.

I also received some new 24-pin low profile dip sockets yesterday so I can start cleaning up the wiring. I'm going to focus on that and getting the read/flash code working in my Android BIN editor over the next week for a video.

If anyone has a cheap 7747 or 7730 they can part with, drop me a PM and give me your best price to 53158. Looking to spend closer to $10-15 than $50. The $10 ones seem to come and go on eBay and right now they aren't around.

I should have more updates next week hopefully.

Thanks

[EagleMark]

I have a 7747 to donate to the project!! PM me an address.

For the bluetooth signal antena would it be possible, if needed, to be the only thing mounted outside ECM?

[ruhled]

I have a 7747 to donate to the project!! PM me an address.

For the bluetooth signal antena would it be possible, if needed, to be the only thing mounted outside ECM?

Its do-able and not that much more expensive, <$10 for sure. Probably have to drill a 1/4" hole in the access cover for the antenna to mount to.

Thanks for your generous offer - I'll PM my info.

[EagleMark]

Drill it out the case and mount it. Leave the access cover alone for chip access.

[jdarg]

EagleMark, that's an idea, but there really won't be a need to play with PROMs once this is installed anyways. It will have 31-127 banks of flash, depending on the size of the flash chip I end up using. Right now I'm using 2mbit chips which gives me 63 banks. I plan to use one bank to hold configuration data about the other banks like names, dates, comments, etc. as well as some global settings. These can then be displayed by a device when switching banks, for example, so you don't have to mentally keep track of what's in each bank and what changed between two tunes.

I've also done an extremely rough test of using an "auto learn" fuel feature. The idea is at every key-off, the BLMs would be updated into a new BIN, a new checksum calculated, and then it would auto-flash into the next bank #. That bank would then become the default. All without any external connectivity, SD cards, etc. Looks very promising.

[EagleMark]

That sir sounds very cool! :jfj:

[Six_Shooter]

You had my interest until you said you were adding an auto learn feature. I will NEVER use an auto learn feature, speadsheet or otherwise, not even to get into a ball park, because it's almost always the wrong ball park.

[jdarg]

Six_Shooter, this would be an option you could toggle on and off - not something you have to use, nor something I would ever enable by default.

There really doesn't seem to be a lot of interest for this so I'd really appreciate some honest opinions - is everyone content with spending $120 for an ALDL cable/chip burner even though this has almost top-tier features (i.e. flash, bluetooth) for less money than a retail ALDL cable costs? Do people not want DIY kit type of stuff?

[jdarg]

BTW still need a beer-money priced 8192 baud P4 ECM that is relatively common like a 7730, 7727, and so on. I can pay around $20 shipped to 53158. If anyone has one just collecting dust please drop me a PM.

[jdarg]

BTT

I finally scored a 4 cylinder 8192 P4 ECM that I can find an XDF for off ebay last week for ~ 10$ shipped. Otherwise life has been getting in the way so I haven't done anything in the past two weeks but should have some time again after this weekend to work on a video.

[EagleMark]

I have a 7747 to donate to the project!! PM me an address.

For the bluetooth signal antena would it be possible, if needed, to be the only thing mounted outside ECM?Did you ever email me an address? Cause that box is still sitting here and I don't know why? You still need it?

[jdarg]

Did you ever email me an address? Cause that box is still sitting here and I don't know why? You still need it?

Yes I did a couple of weeks ago but I didn't want to bug you about it. Check your forum PM, I don't know your private email address.

[jdarg]

Just another quick update...

I've been taking care of some integration issues having the flash memory hooked to two data/address busses at the same time and I should have everything resolved once I get some more ICs from Mouser. To keep things at bare minimum HW for now, it will only be able to flash on key-off. The arduino can detect if the ECM is running or not so at least the software will be able to detect when it is safe or not. If I add two more glue chips I'm 99% sure I can also flash on key-on when the ECU is powered-up and executing (it will throw a PROM code though, and run off the memcal for a second or two) but first I want to make sure key-off works since I don't have to manage the address bus when the ECU is in that state.

At this point I don't think the whole project is going to fit inside the ECM unless I switch to surface mount components, which I am not willing to do because it makes the hardware too difficult to assemble/modify. It's going to have to hang off the ECU via a ribbon cable in a very small box of its own. This also solves the bluetooth signal issue without having to add the cost/implementation details of an antenna.

Did some tests with a 4K dual-ported SRAM in a DIP package over the weekend. It works, and saves me one glue logic chip for data bus management, but the lack of higher density SRAMs in through-hole is kind of a killer for me, although it would be fine for a C3 ecu I guess.

[1project2many]

If I add two more glue chips I'm 99% sure I can also flash on key-on when the ECU is powered-up and executing (it will throw a PROM code though, and run off the memcal for a second or two)

The way around this is to set the Mask ID $AA before the flash. The ecm will skip checksum recalc (or disregard wrong results) with the "Engineering Calibration" byte set.

[jdarg]

I'd prefer the user make the choice to disable the built-in checksum routine. It is what it is and other products will behave in a similar manner if you tune with the key on or while driving.

Incidentally setting the mask to $AA doesn't fix this particular situation anyways, although disabling the prom malf flag might but I haven't tried it yet.

[1project2many]

Why does setting to $AA not solve this? The prom code is set when the checksum calc fails.

The product I use (Xtronics Romulator) does not set a prom code when real time tuning. And it does not appear to run on the memcal during calibration updates. Although I haven't used it to tune a C3 in many years so maybe there's a difference between ecm families? Maybe I'm comparing the wrong product to what you're working with?

[Six_Shooter]

Why does setting to $AA not solve this? The prom code is set when the checksum calc fails.

The product I use (Xtronics Romulator) does not set a prom code when real time tuning. And it does not appear to run on the memcal during calibration updates. Although I haven't used it to tune a C3 in many years so maybe there's a difference between ecm families? Maybe I'm comparing the wrong product to what you're working with?

I'm as confused as you are about this. By the description of the problem disabling checksum should solve a few issues.

FWIW, I have used an Ostrich 2.0 on C3 ECMs and they act exactly like their P4 counterpart.

[RobertISaar]

sounds like the processor is getting thrown into LHM temporarily due to the RAM/ROM the program being on being removed from the processor's address/data bus.

EDIT: or perhaps reset being held active during the upload, which would still cause the same issue, processor can't execute code, so watchdog timer runs out, LHM chip signals make it to the FMD, etc.

[jdarg]

sounds like the processor is getting thrown into LHM temporarily due to the RAM/ROM the program being on being removed from the processor's address/data bus.

EDIT: or perhaps reset being held active during the upload, which would still cause the same issue, processor can't execute code, so watchdog timer runs out, LHM chip signals make it to the FMD, etc.

exactly - the first one.

i'm not bothering to control the reset line because there simply isn't a need (or advantage) that i can see vs. isolating the buses. I'm already "in the socket" whereas reset control will require another tap somewhere - edge connector, etc. The ECU self-recovers within milliseconds anyways, once I give it its PROM back.

For those who can't envision why the $AA trick doesn't work, consider that my bins both before and after the flash write operation contain proper checksums. So its not a checksum issue at all - the checksum stored vs. calculated is always correct. I have to disconnect buses for a flash read operation too - yet nothing is actually changing - and it will toss a code. Hope that helps explain it.

I have some interesting developments on SRAM-less emulation. For the DIY crowd. Stay tuned.

[Six_Shooter]

So you're not going to bother to correct for a "bumpless" upload?

I'll stick with proven products that do have seamless uploads, to protect the engine it is running.

[jdarg]

So you're not going to bother to correct for a "bumpless" upload?

I'll stick with proven products that do have seamless uploads, to protect the engine it is running.

I'm not trying to sell everyone a new tuning product. I'm not trying to create the "best" emulator/flash add-on. I'm trying to develop a "starting point" for something that the community could help shape into that. I'm just shooting for a certain baseline of functionality before I release the hardware design and software source code.

Do you know why the "bump" doesn't bother me? Because EBL bumps the ECU on flash too - I know because I have one in my Jeep. It's just not an issue for most folks. I would never advocate tuning while driving but yes I've done it. Would I do it during a WOT pull - no - but it's fine at idle while the motor is running. Its no worse than a "work in progress" tune for your motor really.

Given the choice between having to buy an ALDL cable and burn obsolete chips -or- build a semi-capable flash unit that does ALDL and bluetooth for 50% the cost of 5 chips and a burner, which would you pick? This is the gap I'm trying to fill.

I don't think I'm going to do the kickstarter any more - it seems to create some negative perceptions for some reason, maybe because there is some stuff on there that ultimately never materializes, or people think I'm somehow going to make 500,000$ off of this, which any reasonable persons knows is not true of 99.9% of kickstarter projects. Someone else can finance a run of PCBs if they are so inclined. I'm actually close to getting this down to fitting on a proto shield anyways, so maybe PCBs aren't really needed.

I'm really confused by your attitude in this thread and felt I needed to try to put this in perspective. Perhaps I haven't explained what the goal is too well, and if so I apologize. I know I don't always communicate too clearly. But you seem to be trolling for some sort of response from me instead of encouraging a community project. If I'm in the wrong place please just let me know and I'll take it elsewhere.

[Six_Shooter]

Not the wrong place, just wrong approach, for your target market. The market your are marketing in has a strong following of Moates products and many of us own many of his products (I personally own own 3 Ostrich 2.0s, an AutoProm, an ALDL XTreme, BURN2 and a few other devices), so it will take something pretty amazing to get us to get involved with something else that by description seems to have less ability, even if it costs less. It seems like you may not have had a clear goal when you started this, which happens, things change. It almost sounds like this should be marketed as a flash chip, that will only upload during engine off times, basically a flash chip that doesn't require any physical chip switching. An "emulator" suggests (to most people) that uploads can be done at any time without the target device "seeing" that upload.

There are many of us that have dealt with emulators that are not "bumpless" and have replaced them BECAUSE of that bump when uploading. This is a bigger deal to some than others, especially when some of us have engines that either A) will not run off LHM, or B) will cause other issues when an engine stumbles (I.E. overfueling and washing down cylinders, which can happen with frequent stumbles due to overfueling). It doesn't have to do with a drivability issue per se, although that is also a great concern, for those of us that do make changes while the vehicle is in motion (I.E. one person driving, one person making changes), personally I tune this way frequently.

As for your question, I would pay more and get something that IS bumpless, if chipless tuning was desired.

At the beginning of this thread you said you wanted to include self tuning, that will NEED a bumpless upload to work smoothly, unless you are going with the spread sheet "auto tuning" that then gets manually uploaded at a later time, either with manual triggering from the user or at some pre-defined point, such as key-off or key-on, vehicle speed <1 MPH, etc.

I have found that even if checksum is correct before and after an upload, that without disabling checksum in some ECMs it will throw an error, I don't believe the C3 ECMs have this issue, but the P4 in my experience has. For anyone that understands this, it is pretty easy to change within Tuner Pro though, either through the tuning windows or the hex editor directly.

You haven't explained what you wanted to do this well enough. Your last post makes it more clear that you just want something that IMO kinda works, more as a design exercise, than a viable product. There is one part that I'm interested in this, and that is the ALDL Bluetooth, but without having bumpless uploading, the flash side is not.

I was not aware that the EBL bumps when uploading, I'm quite surprised by that actually, I didn't think RBob would release something that works that way.

[RobertISaar]

As for your question, I would pay more and get something that IS bumpless, if chipless tuning was desired.

X2.... NVRAM that updates over ALDL is the only cheaper(than emulator) option that i've seen that allows real-time changes and not cause a LHM situation. depending on the implimentation though..... either need to change a lot of algorithm(the way montecarslow did) to store only necessary stuff on a smaller module or change a little bit for the full-size modules that the australian guys do and add in some new ALDL modes to deal with data handling and have the software on the pc-side to deal with either.

the only real downside to this route(to me) is that datalogging is obviously interrupted until the upload is finished. if one were to write some very intelligent software on the PC side.... only a couple of bytes at a time would need to be sent for every change, assuming you only touch a few cells of a table at a time, so you might lose about one sample worth of data at a time. but, then you have to deal with handing the COM port between tunerpro and your upload program.... or write a tunerpro plugin that will allow you to do it all within tunerpro.

kind of sucks that i can get 75% of that done, but i can't do PC side stuff at all.

[EagleMark]

kind of sucks that i can get 75% of that done, but i can't do PC side stuff at all.Sounds like jdarg is the guy for that? Would be a cool project when complete!

[jdarg]

Sounds like jdarg is the guy for that? Would be a cool project when complete!

I think I have enough on my plate right now but I 'm sure I could help. But the hardware has to be easy to put together or it probably won't catch on.

I've been doing Windows dev for years now and wrote a bin editor for Android that uses standard XDF files. I haven't released it because I wanted to release this hardware first so it would be the first complete open-source tuning solution, from end-to-end. :happy:

I can do dual ported SRAM along w/ the flash stuff and get around the reset. I had it working the bench already a couple of weeks ago. But the physical size gets prohibitive for anything w/ PROMs bigger than 4-8K unless I go surface mount, which then makes it really hard for most DIYers. I just want to get v1.0 out the door right now so other people can start playing with it and do something useful with it (it still beats the hell out of burning chips - and it will burn chips too - that's part of my v1.0 feature list) then I can start messing with SRAMs and all that.

[3400tZ]

This sounded like an interesting project. Any updates jdarg ? :)