changes made for railcom and CV programming changes #139
Conversation
* master: (350 commits) Updates targets that we broken by linker changes. Moves the usb interrupt vector number reference internal to the usb cdc serial driver. Simplify some of the code. Refactors CAN driver for pic32mx to have a header and be instantiated in the hw_init.cxx. Updates some of the interrupt generating code and makefile includes. Moves ISRWrapper. Move ISRwrapper.S over to the generic directory. Updates the suffix of the multibin make target for 091 Adds interrupt generation code for the mx530. Adds a generated file, one for each freertos interrupt. The output .o files from these will be pulled in when a given symbol is referenced from c++. Once the .o is pulled in, the specific interrupt trampoline is linked into the main program. Moves the reset_data in ram0. Makes sure we detect duplicate interrupt vector table entry. Adds documentation. Stores the interrupt vector (internal) number for the uart module. Adds freertos isr wrapper macro. Moves ISRWrapper to the freertos drivers directory. Removes obsolete linker script. Switches over lccbuffer compilation to use shared linker script. Adds memory map for MX530. Updates symlinks. ... # Conflicts: # src/openlcb/TractionCvSpace.hxx
| @@ -945,13 +945,13 @@ TivaDCC<HW>::TivaDCC(const char *name, RailcomDriver* railcom_driver) | |||
|
|
|||
| unsigned h_deadband = 2 * (HW::H_DEADBAND_DELAY_NSEC / 1000); | |||
| unsigned railcom_part = 0; | |||
| fill_timing(RAILCOM_CUTOUT_PRE, 6 - railcom_part, 0); | |||
There was a problem hiding this comment.
The code here has an invariant that railcom_part is always set to the absolute microsecond that the sum of the previous RAILCOM_CUTOUT_XXX segments represent. This is used to compute the length of next part by a simple subtraction.
You broke this invariant, and after your changes it is impossible to reason what this code does. Please restore this invariant so we can merge this code.
|
We should consider adding wifiparams.c to to the gitignore. Also I should double check the timing I made, I think it only effects the tail end of the cutout, testing so far with current timing has had no adverse effects on Railcom performance however, it may just be that the packets I've used have not used the full channel 2 time window so it hasn't been an issue yet. |
Had to make some adjustments for Wifi params, railcom timing, and CV programming menu on the throttle