Hi! Firstly, you've got to read the core comms spec doc, it explains a lot of this. Ditto the app note for the serial monitor/boot loader, it explains all aspects of that. In reading our core comms doc, if there are weaknesses, please bug me about them. That way the docs can get improved as we go. If I just answer questions here that are answered in that document, it doesn't benefit future implementers. That said, let me respond to your post.
eezo20v wrote:Source code will definately be open source to anyone who wants to have input, compiling may be on certain machines. Installation of the app will be available to everyone, which will be more than 90% of users.
Excellent! :-)
1. What is the purpose of the async comms?
Fred wrote:Flexibility, reliability and speed.
Please correct any misconceptions I may have.
I'll give it a shot :-)
1. If all comms is initiated by the PC then async is not viable.
The comms is full duplex. The PC (or other device) can send a request in the middle of the stream and the stream will be interrupted in order to respond. Async is totally viable :-) In fact, due to the escaping and start/stop scheme, it's possible to use purely simple devices and apps to record the available streams, and/or request simple things, and decode and interpret them later with specific applications. This takes the burden away from any logging and recording devices and apps and places it at a less time critical point in the process.
2. The periodic async comms from the ECU is what information exactly?
Datalog streams (various), error packets, warning packets, debug information, status information. Anything that the ecu wants to tell the world about (as opposed to being asked for information), and anything that benefits from being fast.
3. Its slightly concerning if you have the ECU connected to any multi drop bus and you are sending unsolicited messages. This all depends on what data is being sent periodically. If its a broadcast its fine ( ie CAN, ISO9141 etc ), if its a simple log of data that is not an automotive protocol then its an issue. If we are only ever going to use master/slave then forget this point altogether.
UART is designed for point to point use, however there is nothing to stop multiple devices listening in. It would potentially be problematic to both apps if both were sending requests. If set up well, the two apps could actually coexist and only listen for packets with specific key ids, but there could still be collisions if that was being done, so I don't recommend it. As such it's not a problem to stream async stuff or send sporadic async messages of various kinds.
You guys may need to be a bit short/direct with me ( to keep me in line )on this point as I come from an environment where everything is compliance based, and sending unsolicated data is a big no no ( unless its an official automotive protocol broadcast ).
I'm sure I can manage to do this for you! :-)
My apologies I had a brain freeze. I meant 16 bit CRC. I have C source code to handle if needed.
Eventually, I'll probably migrate. It's just not a priority right now, and will sort the good coders from the bad when swapped to. I've got a few tricks up my sleeve to keep the speed up.
I understand that full bandwidth streaming is not possible. I may be naive in my point ( by not fully understanding the reasons behind whats being sent asynchronously ).
When it comes to logging, not too many things are important. Accuracy, consistency, matching data, configurability, and last, but NOT least, SPEED! :-)
Is it only logging data that is being sent without a request? Everything else is a challenge/response format?
No, see above, right now, yes, but in future, no, all sorts of things will get sent.
Also, out of curiosity, what is the fastest rate you get?
1000 samples per second for a single 8 channel one byte port logger. IIRC about 40 per second of the full length default/basic log. A single channel analogue scope logger should deliver about 800 samples per second or there abouts. The shorter the log, the greater the benefit of the packetised scheme in async streaming mode.
Also, if someone has some time, could you please point out the header block and decipher it. I want to make sure I have it correct.
The data payload is just three structs from the header files in the firmware source. The general rule for tuning app authors is:
1) Read any header
2) Do not read any source code
This way you will write your code to the interface description and specification, and not write to any quirks of the current implementation (which could change at any time).
For now, focus on decoding the packets properly, and decoding the header properly. Do it purely using the documentation. If docs are wrong, or even unclear, complain loudly here and we'll try to clarify or correct them ASAP. If you need some assistance with the raw packet decoding scheme, there is some default source code that I can point you at, however I'd do it very differently in an OO language. For now, have a crack at it without assistance. If you run into trouble and need help, let me know here.
Once you have that done, it would pay to make the break down of the actual datalog packets configurable such that they can be changed and improved over time without code changes to your app and an associated recompile that users (and me!) can't do.
2. Can someone please explain or post a link to how I update the firmware. I need to know what application/version to use to flash a s19 file.
Fred wrote:We've done the best we can there. I'll let Sean know that you're waiting for him too.
OK
He's been putting some good work into it today, hooray. Hopefully we can get some good testing in in the next few days.
I will write a windows only bootloader. I may need some guidance as to how ( as in which ECU commands to use ) to delete the firmware and get the bootloader running.
Also I may need some help in translating the AN2548 doco if its very hardware specific. I don't do hardware very well.
Read the app note, it explains how the SM works. Simply, you flick a hw switch, and on reset the sm reads the port and if its one state holds control, and if another hands over control to the "user code" aka firmware. Reset can be done over the serial line from either SM or firmware. See the core comms docs for details on that when the firmware is running and the ./lib/test.packets/serial.monitor.dir/*.bin files for when the SM is running. (there is a reset packet there)
I do want to get myself a BDM programmer. Can you please suggest one that will work with this processor.
There are a number of choices. There is on that Tech Arts sells for 50usd that is all open source, I'd get that if I were getting one, but I already have another.
Good luck! Don't forget to:
A) use git (github is nice), not svn, svn is not appropriate for distributed open source development IMO.
B) post test binaries for people to play with as often as you can be bothered (I have an XP VM for example)
C) post screen shots of progress
D) post on the forum about progress (you're doing great so far!)
Fred.