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

Post Reply
User avatar
janosch
Posts: 189
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Contact:

terminal.cpp Unknown Command Sequence "json"

Post by 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).
Attachments
Screenshot from 2022-08-31 16-03-53.png
User avatar
janosch
Posts: 189
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Contact:

Re: terminal.cpp Unknown Command Sequence "json"

Post by 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.
Attachments
Screenshot from 2022-09-02 17-08-49.png
User avatar
johu
Site Admin
Posts: 3864
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Contact:

Re: terminal.cpp Unknown Command Sequence "json"

Post by 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...
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
janosch
Posts: 189
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Contact:

Re: terminal.cpp Unknown Command Sequence "json"

Post by 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.
User avatar
janosch
Posts: 189
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Contact:

Re: terminal.cpp Unknown Command Sequence "json"

Post by 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?
User avatar
johu
Site Admin
Posts: 3864
Joined: Thu Nov 08, 2018 10:52 pm
Location: Kassel/Germany
Contact:

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

Post by 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
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
User avatar
janosch
Posts: 189
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Contact:

Re: terminal.cpp Unknown Command Sequence "json"

Post by 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 8-)
Attachments
PXL_20220907_160956184-min.jpg
User avatar
EV_Builder
Posts: 954
Joined: Tue Apr 28, 2020 3:50 pm
Location: The Netherlands
Contact:

Re: terminal.cpp Unknown Command Sequence "json"

Post by 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.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke modules.
User avatar
janosch
Posts: 189
Joined: Tue Jun 30, 2020 9:23 am
Location: London, UK
Contact:

Re: terminal.cpp Unknown Command Sequence "json"

Post by 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
Post Reply