0000062: Port Control Screen And Packets

Viewing Issue Simple Details [ Jump to Notes ]

[ View Advanced ] [ Issue History ] [ Print ]

Category

Severity

Reproducibility

Date Submitted

Last Update

0000062

[FreeEMS-Tuner] Features Requests

minor

N/A

2008-11-16 20:41

2009-09-02 21:38

Reporter

Fred

View Status

public

Assigned To

sry_not4sale

Priority

normal

Resolution

open

Status

acknowledged

Product Version

Summary

0000062: Port Control Screen And Packets

Description

Obviously I need to write the firmware side for this too, but it would be immensely useful to be able to configure the IO from a dedicated tab in the GUI.

I think the format should be:

send (full state for all pins)
receive (full state for all pins)

At start up the GUI should query the device to find out the current state. Or perhaps it could be on a user config basis?

The tab in question will need a sub section for each port and a set of columns or rows or check boxs for the bits in each control register. There should be some sort of LED indicator for each pin to show the actual state received after the update is made. I guess it should be sent on a per click/adjustment basis in real time. There could/should be another LED saying that the state of the pin and the settings don't match.

This will be enormously useful in understanding the hardware better as it will enable me to test various theories without soldering new stuff up.

You won't be able to do much with it until I provide the details or what you should be able to control and how the packets should look, but have a think about it. it might be a case of just writing large blocks of registers with memcpy on my end, or maybe i will need to be more explicit.

This is a good task for me on the train so look for some results later this week. This of course relies on the comms reception working properly, so that takes priority for sure.

I've been working on the pin out stuff tonight, but it is tough going. it would be nice if I could configure things on the fly to test out some theories.

This type of packet could be used to implement various control strategies on the PC side where it is easier to write complex code and then migrate them to the firmware when well tested and debuged. Stuff like PID idle and what have you could all start life on the PC side using this interface.

In the long term it could be a very valuable debug tool when there are hardware and wiring issues etc. Well worth doing in my opinion. Quite easy too bar laying out the gui.

Additional Information

Issue History
Date Modified	Username	Field	Change
2008-11-16 20:41	Fred	New Issue
2008-11-16 20:41	Fred	Status	new => assigned
2008-11-16 20:41	Fred	Assigned To	=> sry_not4sale
2008-11-16 20:41	Fred	Issue Type	=> New Feature
2009-09-02 21:38	sry_not4sale	Status	assigned => acknowledged

Relationships