FreeEMS Issues - Tunix
View Issue Details
0000443TunixFreeEMS Pluginpublic2011-11-28 11:592011-12-02 09:41
Fred 
dandruczyk 
normalminorhave not tried
closedfixed 
LinuxDebianSid/Unstable
0.9.24-SNAPSHOT 
0.9.240.9.24 
0000443: Weird Issue With Unfound Packets
I was just playing with the ign table moving up and down in the cells without changing anything and got this odd behaviour:

A stream of write failures occurred (though I never made an edit) and didn't stop coming for ages. The firmware was more or less idle and in good shape (fresh reset) when this happened, not related to the corruption that you found.

Curiously the last stack had all zero sequence, which is odd. This is FYI, no idea how to reproduce other than what I described above.
(gdb) run --g-fatal-warnings -p FreeEMS -P /dev/ttyUSB0
Starting program: /home/fred/MegaTunix/src/.libs/megatunix --g-fatal-warnings -p FreeEMS -P /dev/ttyUSB0
[Thread debugging using libthread_db enabled]
[New Thread 0xb0445b70 (LWP 11429)]
[New Thread 0xafc44b70 (LWP 11431)]
[New Thread 0xaf443b70 (LWP 11432)]
[New Thread 0xaec42b70 (LWP 11434)]
[Thread 0xaf443b70 (LWP 11432) exited]
timeout, no packet found in GENERIC_READ queue for sequence 188 (BC), locID 61444
Re-issued command sent, seq 185!
[New Thread 0xaf443b70 (LWP 11446)]
[New Thread 0xae3abb70 (LWP 11447)]
Packet ERROR Code 0x6005, "Invalid main table Load order!"
DATA Write Response PACKET NACK ERROR, rollback not implemented yet!!!!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 230!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 188!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 188 (BC), locID 8
Re-issued command sent, seq 193!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 193 (C1), locID 8
Re-issued command sent, seq 41!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 41 (29), locID 8
Re-issued command sent, seq 15!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 15 (0F), locID 8
Re-issued command sent, seq 43!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 43 (2B), locID 8
Re-issued command sent, seq 164!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 164 (A4), locID 8
Re-issued command sent, seq 10!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 10 (0A), locID 8
Re-issued command sent, seq 231!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 231 (E7), locID 8
Re-issued command sent, seq 132!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 132 (84), locID 8
Re-issued command sent, seq 97!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 97 (61), locID 8
Re-issued command sent, seq 131!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 131 (83), locID 8
Re-issued command sent, seq 144!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 144 (90), locID 8
Re-issued command sent, seq 71!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 71 (47), locID 8
Re-issued command sent, seq 190!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 190 (BE), locID 8
Re-issued command sent, seq 160!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 160 (A0), locID 8
Re-issued command sent, seq 215!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 215 (D7), locID 8
Re-issued command sent, seq 52!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 52 (34), locID 8
Re-issued command sent, seq 248!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 248 (F8), locID 8
Re-issued command sent, seq 235!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 235 (EB), locID 8
Re-issued command sent, seq 142!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 142 (8E), locID 8
Re-issued command sent, seq 41!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 41 (29), locID 8
Re-issued command sent, seq 247!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 247 (F7), locID 8
Re-issued command sent, seq 224!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 224 (E0), locID 8
Re-issued command sent, seq 125!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 125 (7D), locID 8
Re-issued command sent, seq 152!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 152 (98), locID 8
Re-issued command sent, seq 23!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 23 (17), locID 8
Re-issued command sent, seq 69!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 69 (45), locID 8
Re-issued command sent, seq 108!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 108 (6C), locID 8
Re-issued command sent, seq 73!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 73 (49), locID 8
Re-issued command sent, seq 186!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 186 (BA), locID 8
Re-issued command sent, seq 244!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 244 (F4), locID 8
Re-issued command sent, seq 23!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 23 (17), locID 8
Re-issued command sent, seq 115!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 115 (73), locID 8
Re-issued command sent, seq 12!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 12 (0C), locID 8
Re-issued command sent, seq 107!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 107 (6B), locID 8
Re-issued command sent, seq 41!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 41 (29), locID 8
Re-issued command sent, seq 248!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 229!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 64!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 64 (40), locID 8
Re-issued command sent, seq 7!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 7 (07), locID 8
Re-issued command sent, seq 35!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 79!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 79 (4F), locID 8
Re-issued command sent, seq 190!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 30!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 227!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 153!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 16!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 90!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 186!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 254!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 19!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 240!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 147!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 187!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 235!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 52!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 27!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 21!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 219!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 242!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 226!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 222!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 242!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 108!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 134!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 206!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 198!
timeout, no packet found in GENERIC_[RAM|FLASH]_WRITE queue for sequence 0 (00), locID 8
Re-issued command sent, seq 222!
No tags attached.
has duplicate 0000450closed dandruczyk Firmware Device fails to respond to requests, sometimes for long period (50-150+ attempts) 
? mtx.back.to.back.requests.logicdata (2,191,787) 2011-11-30 13:50
http://issues.freeems.org/file_download.php?file_id=40&type=bug

Notes
(0000734)
dandruczyk   
2011-11-28 20:51   
If you stop highspeed streaming from the menu, I bet it goes away.. This seems to be a firmware fault that has problems accepting commands when highspeed streaming is running due to either missing interrupts or some other possible firmware issue.
(0000736)
Fred   
2011-11-28 21:07   
Good info. I'll look into it at the same time as the other issue you reported. Leave this one floating around until then. What is with the zero sequences, though? That's what you're setting/expecting, right?
(0000738)
dandruczyk   
2011-11-28 21:17   
The zero seq's are unusual. megatunix will NOT use a 0 for sequence for several reasons, mainly because as an integer it looks like a NULL when used a g_object_[gs]et_data. MegaTunix defaults to a random number between 2 and 255.
(0000739)
Fred   
2011-11-28 21:23   
OK, so it sounds like MTX IS getting a bit confused. Re the random thing, unrelated, but wouldn't it make more sense to cycle through them with an increment? that way it'd be simple to spot one missing in a stream if you were logging etc. I always wondered why they seemed random, this explains it :-)
(0000740)
dandruczyk   
2011-11-28 21:27   
Sequential could work, however it's possible them it could clash with other commands in flight due to the limited numerical space for the sequence (8 bit) The random number bit was easier, as it was one call vs and increment+test+adjust if needed.
(0000741)
Fred   
2011-11-28 21:32   
sequential with a shared number pool for datalogs/burns/writes/etc should work well. i cant think of a reason not to do that.
(0000747)
dandruczyk   
2011-11-28 23:10   
missed packets are now requested with a bumped sequence number instead of random.

Initial request still uses a randon sequence number.

Am noticing its MUCH easier to trigger the request timeout if the ECU has highspeedstreaming turned on. This appears to expose a bug/fault in the firmware where commadns are being missed, perhaps becasue the device is to busy slinging bits and has interrupts disabled for extended periods causing it to miss chars on the input from the host?
(0000748)
dandruczyk   
2011-11-28 23:52   
altered behavior, and can no longer replicate the fault.
(0000749)
Fred   
2011-11-29 00:17   
Will test tomorrow and close if fixed. You should have set this resolved, not just assigned to me.
(0000762)
Fred   
2011-11-30 00:29   
OK, I need to investigate more, but I'm pretty sure that this is either a hardware issue, or an issue with MTX. I don't know which yet, so I'm not pointing the finger, but what I'm seeing on the logic analyser are 500ms spaced packets being sent from the device back to the PC perfectly formed always with double start/stop. What we see in the mtx log is missing starts, as far as I can tell. So either the hw misses the first byte or two of fresh data from a cold line, or mtx misses it. I thought I saw some behaviour in mtx too, but can't be sure. I'll play with this more tomorrow and see what I can sort out. This might be the end of the double start/stop hack too, it may be related.
(0000763)
Fred   
2011-11-30 00:30   
You could also drop that time out by a LOT at some point. The packet timing for the worst of them will be the location ID list, the rest should all be faster to respond AFAIK. I can and will do exact timings for the docs, maybe tomorrow for that too.
(0000764)
dandruczyk   
2011-11-30 13:40   
The timeout is a MAX, basically the "give-up" point, if the packet come's in sooner, that it fine. The queue is registered BEFORE the packet is even sent, so there's never any risk of the queue' not being present to deliver the packet.

I mentioned to you a very very long time ago (before the issue tracker was even up) that the duplicate start/stop's were likely to cause problems, but you shrugged me off.

If the serial timing is off on either the ECU or the USB-serial adapter that can lead to bytes being missed.
(0000765)
Fred   
2011-11-30 13:49   
OK, the issue with the continuous missing packets is this:

You send a datalog request and back to back, you send a data block request, which, of course, as specified by the protocol, is ignored. You get a datalog response shortly afterward as requested.

Attaching a saleae log showing it.

4.434592250 - your datalog request start byte begins
4.435927500 - your datalog request stop byte ends AND your data block request start byte begins
4.437322812 - your data block request stop byte ends
4.440238812 - the second stop byte of my running datalog packet ends
line from ecu dead while processing
4.442289687 - the start byte of the datalog reply begins

Thus the ECU is responding perfectly well, just not to what you expect because you're violating the protocol specification.

You can get the client from here: http://www.saleae.com/downloads/ [^]

I wonder if this is responsible for the few at startup too... I won't spend anymore time on this until you're confident that you're not back-to-backing requests and timing out on the response to the second one.

You told me that you waited for the last packet before sending the next. That's clearly not true if there is more than one source of packets. You should have a single thread that handles packet dispatch and reply delegation to avoid this, IMO. Feel free to ignore.
(0000766)
Fred   
2011-11-30 13:53   
I'm not sure if the session that I uploaded includes the serial decoders or not. If not, they're easy to configure, one catch, the way I hooked up the probes means that the FreeEMS one is inverted. It will give you garbage output if you don't select that.

Also, it's kinda cool, the response datalog is almost indistinguishable in the stream of async ones. The only thing that gives it away is your sequence inclusive header :-) Pretty cool! :-)
(0000768)
Fred   
2011-11-30 14:04   
You can sort-of verify this empirically by disabling polling and enabling streaming, i just tried a dozen times and only had a few random-ish location ids, like a normal boot up. If you could add hex to the location ID debug output, that would be very useful, pretty please :-)
(0000769)
Fred   
2011-11-30 14:39   
Re timeouts, the 2k blocks take 204ms to complete sending, PLUS OS and PC side software delays and internal MTX delays. I don't know what those are, but 500 still seems excessive, however perhaps it's not.

The list of IDs takes 222ms and most of it is calculation time on the device, not transmission, the opposite to the big blocks.

It's up to you, 500ms isn't unreasonable, it just seems like it when you're waiting for it.

We'll discuss the dual byte thing in IRC to avoid polluting this thread/issue.
(0000771)
Fred   
2011-11-30 20:35   
"You told me that you waited for the last packet before sending the next. That's clearly not true if there is more than one source of packets. You should have a single thread that handles packet dispatch and reply delegation to avoid this, IMO. Feel free to ignore."

Here is an architecture document to help you get the internal structure and semantics correct:

http://stuff.fredcooke.com/InterractingWithFreeEMS.png [^]

salmon = plugin/freeems specific, blue = tuner framework, lots of detail missing, obviously...
(0000776)
dandruczyk   
2011-12-01 00:11   
The problem is that with datalog packets coming in so fast, Everything that depends on that data now stacks up and stalls the UI. Runing those tasks at decoupled rates breaks things extensively.

Things like status boxes (runtime status window), the logviewer, any and all of the watches (events fired based on specified conditions), and the datalogger output are all intrinsically tied to the datalog stream. GTK+ can't handle running all four of those tasks 80-100x per second. Since ALL GUI OPERATIONS must ONLY be run from ONE THREAD and ONE THREAD ONLY, Every Gui toolkit on the planet (java included) has this sort of restriction. Re-architecting each of those tasks to run at an independent rates makes things dramatically more complex and hurts the overall UI, and will result is a shitty user experience, and greatly slowed development, as well as the introduction of a lot of new bugs since things need to be ripped to hell to suit you.

I hope you're happy that you pretty much blew the deadline by a month.
(0000777)
Fred   
2011-12-01 00:31   
Relax for a moment, please. Firstly, what deadline? Secondly, in the above diagram you can just drop data at any point in the chain. You can either decouple the whole lot with the mentioned negative side effect, or you can decouple the processed data from the raw data updates, or you can just not process the packets at all unless they are needed (set a timeout for all of the data and only decode datalog packets into data if required). If you set the time out on the needing of a packet a fraction shorter than the one polling then you will always accept your polled data, and accept only what you need from a full speed stream.

Note, there are some other architectural differences in the above diagram, but the data stream stuff is a big part of it in the context of this thread. By FAR the most important part of the above is having a single dispatch service. Forget full speed logging, there is no need to implement something to solve that issue yet. Just break up the sending of packets such that only one piece of code does it, and that code waits for the previous packet's reply (or timeout) before sending another. This is how you told me you were already doing it, which turned out to be false. If you just make it behave correctly in this respect, the datalog stuff can wait, it's not a big deal. Violating the protocol by sending two packets back to back and then blaming a lack of receipt of a reply to the second one on me, IS a big deal. I don't mind you pointing the finger, but I don't like the tantrum when it gets pointed back with proof, and I especially don't like the fact that it doesn't behave correctly.

I hope the above helps in some way, most likely by ensuring you don't implement the data service decoupling that will be eventually required until later and focus instead on packet sending semantics.
(0000778)
dandruczyk   
2011-12-01 01:10   
I'm too infuriated right now to even have the sanity necessary to respond to you in anything representing semi-coherence.
(0000779)
dandruczyk   
2011-12-01 03:42   
datalog decoupling rewritten. Lots of other shit is likely to now be very flakey or buggy, too bad, so sad. file a GOOD DETAILED ISSUE on it otherwise I am unlikely to notice it.
(0000780)
dandruczyk   
2011-12-01 03:43   
marking as resolved
(0000785)
Fred   
2011-12-01 09:11   
Reopening and assigning to you. The issue here was not datalog decoupling, it was packet dispatching. If in the process of doing what you did, you reworked the dispatch mechanism to function properly, great, "Change Status To" "resolved" and check me for "assigned to" (one step, one email notification, not 3...) and I'll check it out. Otherwise it can stay open until the dispatch stuff is functional in a specification compliant way.
(0000786)
Fred   
2011-12-01 09:12   
Also, it was never explained why MTX was trying to write to the device when I did not edit the table. I don't understand that foundational aspect of this issue, please advise on that also.
(0000787)
dandruczyk   
2011-12-01 13:24   
Packet dispatching was CAUSED BY THE DATALOG REQUEST METHOD. end of story.

> Also, it was never explained why MTX was trying to write to the device when I did not edit the table. I don't understand that foundational aspect of this issue, please advise on that also.

Odds are you changed a value but changed it back. Due to issues like rounding, internally it may look like it was changed, hence a value was sent, Without a MTXlog wiht serial write logging enabled or a binary log, I wouldn't know but you provided neither.
(0000789)
Fred   
2011-12-01 13:40   
"Packet dispatching" is not something that can be caused, it is something that is needed to be handled correctly. IE, your sentence with lots of CAPITAL LETTERS does NOT make SENSE at ALL. CAPS for FUN. The fact that there were two sources of packets interleaving inappropriately was the issue. Having datalog requests sent was never an issue. Only HOW they were sent was an issue.

If I pull MTX and it no longer polls datalogs I'm reopening this again. The app needs a proper dispatch handler that can take ANY number of packets from ANY source and handle them properly. If your fix was to remove polling and handle streamed packets, that's not really a fix to the problem that this issue describes. I'll check later, but have a few other things to sort out first. In the process of exposing MTX issues I found a few small optimisations to make to the firmware which I want to test and push first.

Also, if it still loses a few packets during init and the number is not consistent with the hw errors + overruns figures, then I'm going to go snooping with the saleae again and find out what is really going on.

Note, don't feel the need to knee-jerk work on stuff like this. It's likely always better to consider it for a while first and come up with the best approach as opposed to the first thing that crosses your mind that will alleviate the issue in the short term.
(0000793)
dandruczyk   
2011-12-01 15:06   
> If your fix was to remove polling and handle streamed packets, that's not really a fix to the problem that this issue describes

This is EXACTLY what fixed it. If you had even bothered to look at the datalog code and traced it's execution path you would have seen that that codepath had a potential "hole" where other packets could be slipped within. That codepath no longer exists, with the benefit of handling the full streaming rate at the expense of CPU consumption.

There are a couple of other potential ones but they exist only in a limited one-use context (during interrogation), though those will be fixed at a later time as they only can get run once, and thus are basically forgotten about.

A side effect of all this is that megatunix can no longer accurately determine a loss of serial connection without making BAD assumptions, since in its natuarl state it isn't requesting anything anymore.
(0000795)
Fred   
2011-12-01 15:35   
As promised.

You like the word "can't" too much, Dave.

MTX can perfectly determine loss of communications, far more effectively than it could before, and far more quickly. It can notice resets better and generally be better overall. You could even slip an echo packet into the stream as a test, or a sequenced datalog request and look for the presence of it in the stream.

Once again, this issue is not about the lack of good behaviour, it's about an architectural defect. Sticking a plaster on the wound is not a long term solution. In the short term the app was working well enough. Why bother spending time hacking it in non-final ways? What is required is a dispatcher service that higher layers (such as pollers, reset commands, bench test, etc) can access locked by a mutex of some sort and queue packets to be sent by a piece of code that knows how to deal with them. Fixed was a poor choice of word, deferred would have been more appropriate.

It'll be interesting to see how much CPU it does actually use, though. I bet it's not much, really, unless you have the entire gui trying to update at 100Hz, if so, that's not cool and I'll stick with an older version for the time being.
(0000797)
dandruczyk   
2011-12-01 16:26   
Where is the docs on this "echo" packet? I don't remember seeing those in your PDF.

> Once again, this issue is not about the lack of good behaviour, it's about an architectural defect. Sticking a plaster on the wound is not a long term solution. In the short term the app was working well enough. Why bother spending time hacking it in non-final ways? What is required is a dispatcher service that higher layers (such as pollers, reset commands, bench test, etc) can access locked by a mutex of some sort and queue packets to be sent by a piece of code that knows how to deal with them. Fixed was a poor choice of word, deferred would have been more appropriate.

FOR fucks sake, THIS ALREADY EXISTS!!! If you looked at the code you'd know that. Your ignorance is driving me insane. IF you don't know don't ASSUME YOU KNOW how it is.

MegaTunix ia a huge pile of plaster, if you don't like it, write your own from scratch. It was written by a completely UNTRAINED (read: self-taught) with little thought to design (since the target was always ever changing and moving) by a programmer who has minimal knowledge and understanding of modular/structure/layer or whatever kind of bullshit acronymn you want to label it with. If that doesn't suit you, feel free to write your own, instead of constantly blaming my design when it's completely crystal clear you have no fucking clear concept of the design methods that MegaTunix currently uses. I had to make freeems support based on scattered, and largely incomplete documentation (which has thankfully improved, but only lately) documentation . It will NEVER be perfect in your eyes. I know its a steaming turd, I've accepted that. I don't have the time in the day to rewrite it from the ground up. I need to WORK to afford the basic necessities (food, fuel heat).
(0000799)
Fred   
2011-12-01 16:41   
You wrote that overnight? You're a legend! That's a good effort. Or, are you saying that this thing already existed before? If so, NO, it did NOT, because if it DID, then it would NOT be possible for what happened to have happened. Clear? Good. It's not ignorance, it's called black box testing. Note, this is what ALL of your users are going to do. IE, evaluate the behaviour of the application only without care for intent or historic reasons. If the behaviour says X that, sir, is irrefutable. If you come back and say that you rewrote it to use a proper single channel of packet creation and dispatch such that NO code uses the serial device directly except that code, then I'll apologise, for this, and only this.

I don't think MTX is a steaming pile. You have self esteem and temper issues, that's the problem. MTX is quite nice in many ways. It just needs a little love in some areas to be stable, correct and more flexible. Stop throwing excuses around re "untrained"/"self-taught" - do you think I learned my skills at university? Think again. You're a good dev, as evident from your code, ideas and conversation, but perhaps short on patience, and definitely short on opening your mind to new ideas from other devs such as cpuTorture, Jammi, me, Ben, etc. Try asking questions instead of the "no, you're wrong" approach, you never know, you may learn something.

You're right that it will never be perfect in my eyes. Neither will OLV be. Neither will the firmware be. Neither will my wife be. Nothing is, I'm just realistic.

No one said to rewrite it. Just to layer it appropriately such that only one thing sends packets and everything else queues them there.

The only comment that I have on the docs is that they're almost unchanged since January...
(0000803)
dandruczyk   
2011-12-01 17:16   
> You wrote that overnight? You're a legend! That's a good effort. Or, are you saying that this thing already existed before? If so, NO, it did NOT, because if it DID, then it would NOT be possible for what happened to have happened. Clear? Good. It's not ignorance, it's called black box testing. Note, this is what ALL of your users are going to do. IE, evaluate the behaviour of the application only without care for intent or historic reasons. If the behaviour says X that, sir, is irrefutable. If you come back and say that you rewrote it to use a proper single channel of packet creation and dispatch such that NO code uses the serial device directly except that code, then I'll apologise, for this, and only this.

No, it DID exist, and has for months, however it is ALSO possible to bypass the queue to inject packets and information directly (REQUIRED by the interrogation routines)

Stop misunderstanding and mis-interpreting shit. Go read the fucking code instead of ASSUMING like you keep doing.

> Just to layer it appropriately....

How the FUCK does someone do that when they don't understand the concept clearly with regards to programming!!?? the is obviously clear to you, but not one bit to me, and you have yet to be able to explain it in any concrete terms that make sense to me.

>The only comment that I have on the docs is that they're almost unchanged since January...

Bullshit, the PDF's from your latex crap that had the info only came out within the past month. Before that it was a scatterbrained mess of various OO docs which had either missing or conflicting information. For someone who DID NOT write the firmware or have an internal understanding, the docs were a nightmare to navigate and use. the PDF's are better though they feel incomplete. (don't remember seeing anything in there about an "echo" packet unless you are grouping that intrinsically with something else.
(0000804)
Fred   
2011-12-01 17:33   
I'm not going to read the code, period. ALSO possible to bypass = duplicated code or a dirty internal API. There should have been no mechanism of getting a packet onto the line except through that service. If there was, then it did not exist as a clean service through which its users HAD to pass. If you want to prove this "concretely" then you should reintroduce the polling mechanism layered over that existing service in a way that works.

Quite simply, they ask questions and try to understand it better before mouthing off. It's not a concrete thing, Dave, hence no concrete explanations. The implementation is up to you. I've just described the semantics, which are language and implementation independent. The concrete description exists in terms of source code, both written and yet to be written.

No, not bullshit. One of the latex docs has only untouched content pasted in. The other one has the deprecated stuff changed and the bench test stuff added (copy/paste from forum, almost), and the new stuff introduced in the last month added, but is otherwise unchanged. The core doc is unchanged. There were/are PDF versions of those available. I'll give you that they look prettier now, but the content is UNCHANGED, and, actually, more scattered :-) Not less. I'm working on that situation, however what I said remains true, the docs are the same as they were. Only reformatted and with new features added. Once again, not bullshit... git speaks the truth.
(0000805)
dandruczyk   
2011-12-01 18:13   
>I'm not going to read the code, period.

Then STOP ASSUMING you know how it works PERIOD! IF you're unwilling to make the effort, then stop wasting my time with out of context assumptions.

> If you want to prove this "concretely" then you should reintroduce the polling mechanism layered over that existing service in a way that works.

Why, you've deprecated that API. I'm not double double the work for nothing.

> No, not bullshit. One of the latex docs has only untouched content pasted in.

Prior to the latex PDF's the info was SCATTERED among multiple poorly named files, making them difficult to find and reconcile. That has been fixed, but at the time it was a monstrous bitch to decipher and make any semblance of sense out of.
(0000806)
Fred   
2011-12-01 18:21   
I've deprecated no such thing! What I deprecated IN JANUARY was the call to control what was streamed. That's been deprecated the entire time that you've been using it, and, you'll love this, I can prove it... The call to request a basic datalog still exists and is not deprecated at this time.

Prior to the Latex docs that John introduced 4 months ago, which were copy pastes from odts in the same directory, there were odts in the same directory. NOTHING has changed in that regard. Perhaps you wiped the sleep out of your eyes?

Finally, you've not, by ignoring it, dodged the assertion that you did not have such a structure in place or did have dirty duplicated code or a dodgy API.
(0000810)
dandruczyk   
2011-12-01 19:36   
>I've deprecated no such thing! What I deprecated IN JANUARY was the call to control what was streamed. That's been deprecated the entire time that you've been using it, and, you'll love this, I can prove it... The call to request a basic datalog still exists and is not deprecated at this time.

Uhh: http://issues.freeems.org/view.php?id=442 [^]
 ... Additionally Dave is strongly against a generic memory based streaming control setup and would prefer a single call like the CURRENT DEPRECATED ONE. (emphasis mine).
(0000812)
Fred   
2011-12-01 20:22   
emphasis: control setup, not polling setup, though that could change too, it is not deprecated and is valid.
(0000824)
Fred   
2011-12-02 09:41   
Closing, confirmed MTX is fixed in 110d7672d85c00b660efa2f4b3eb8a31e699c8d9, well done Dave! :-)