terminal.cpp Unknown Command Sequence "json" [SOLVED]

[janosch]

Ok this might be a stupid one but I am a bit at a loss here, so I am posting it:

Web interface "spontaneously" stopped reading params from my VCU, so I had a bit of a look around and in Terminal::Run I stepped through the parsing and found leading "\n" in term->inBuf but I can't quite figure out how that got there.

I believe what needs to be in term->inBuf is "json\n\000...." but instead its "\njson\n\000...". I got no idea where that newline could come from all of a sudden

I stepped through "CmdLookup(inBuf)" and it looks for "" instead of "json", which doesn't match anything in termCmds[] obviously.

As a band-aid I added an EmptyCommand to terminal_prj.cpp that copies the inBuf one byte to the left and just calls CmdLookup again, that then gives a JSON response on UART, cool, but where are these newlines coming from? Presumably they are the terminating \n from previous call. Also my bandaid doesn't quite work because it then breaks the JSON parsing in the webinterface.

Is this a timing problem when booting up and then ESP & STM are out of sync forever by one newline?
Hope this makes some sense. (tried two different STMs and two different ESPs).

[janosch]

Yeah, copying everything to the left one char and replacing the command echo with just a newline echo brings the params back into the web interface, but I am sure breaks other functionality. It will break itself once the \n decide to go and I am one char short.

Question remains where the newlines spontaneously came from.

[johu]

The ESP itself creates a newline to flush the buffer. That is all normal so far. Remains the question why it no longer reads the json command afterwards. You must have changed something somewhere, seemingly unrelated...

[janosch]

Ok, good, sounds like I understood how its meant to work in that case and just messed up somewhere. Will take a look today.

[janosch]

Right, what I tried to do here was add an I2C display and have it updated in main(){ while(1){}}.
Unfortunately adding I/O like that messes up the timings for Terminal::Run(), destroying plotting functionality and web interface.

I could:
1) add the I2C I/O code into the scheduled handlers, but delays will mess with my CAN code, cause timeouts everywhere else in the system, (I don't think this will work at all)
2) add a physical switch somewhere that switches between web interface UART and I2C:

Code: Select all

while(1){
	if(web_interface){
		t.Run();
	}else{
		update_display();
	}
}

3) add the information I want to display on the I2C display to the UART json instead, then have another microcontroller listen into UART and update the display from there (urgh, not nice)
4) modify the scheduler to interrupt the I2C display code and give the terminal higher priority (very computer science-y)

Has anyone else added IO heavy operations to stm32-template and is still using the web interface successfully?
Maybe I am missing something simple here.

I am drawn to solution 2) and 4) but not super happy with either idea. The more I think about it, as soon as the Terminal wants to do something it can just take priority over the I2C, if I can somehow hack that in, maybe that works. Can I throw my own interrupts that have a high enough prio to interrupt main code, but not high enough to interrupt the Ms100Task etc?

[johu]

if you have a free timer left you can instantiate another scheduler that runs at lower priority. Priorities are set in nvic_setup(), the higher the number, the lower the priority.

Otherwise check whether you can DMA your i2c code, that will make it latency free

[janosch]

Yes! I think it works with the second scheduler, thanks.

Had to:
- create a second scheduler using TIM3
- bump the priority for CAN_TX, CAN_RX and Ms{10,100,500}Task in libopeninv
- put a pointer to the Terminal on the stack

The variable is being plotted in the web interface and at the same time the I2C display is being updated. Marvelous indeed.

I tried calling tp->run() every 0.5ms (changed the 100 in Stm32Scheduler::AddTask to a variable, and thought I could make it faster, but that made the connection worse instead of better, calling it every 1ms seems to be rock solid so far.

I will check tomorrow if I broke CAN, if I can run all three at the same time then I am happy. Let's see!
Edit: CAN works too

[EV_Builder]

Wouldn't it have worked if you would have added update_display() to the 500mS task?
Best way to go is definitely using DMA for i2c. Calling the display to often might make it unreadable.

The real test for your display will be in a car since then (depending on CAN Filters) the module needs to chew away more interrupts.

[janosch]

It works in a car, you see e.g. 60A for regen, -100A when pressing throttle harder, 90A when ChaDeMo etc.

Just adding to 500ms made the display work, but it destroyed the web interface, hence having to add a second scheduler to be able to interrupt it, the code is blocking, so in 500ms it would also block important CAN messages etc. because 500ms runs at the same priority as 10ms