Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CANModule to fit CAN into app restructure #407

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

upadhyaydhruv
Copy link
Contributor

No description provided.

Copy link
Member

@wmmc88 wmmc88 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some of the functions you modified were tied to mbed threads. u need to remove the start calls to those threads in CANInterface.cpp

@@ -112,51 +108,47 @@ void CANInterface::rxClient(void) {
}

void CANInterface::txProcessor(void) {
while (true) {
auto startTime = Kernel::Clock::now();
auto startTime = Kernel::Clock::now();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

startTime is now no longer used here

@@ -55,12 +55,8 @@ void CANInterface::rxPostman(void) {
void CANInterface::rxClient(void) {
while (true) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should no longer be while true if its a 1ms periodic function

ThisThread::sleep_for(1ms);
} while (mail == nullptr);
// Check if a message has arrived:
mail = m_rxMailbox.try_get();

MBED_ASSERT(mail != nullptr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with the above logic change on lines 58 and 59, but now it results in try_get sometimes returning nullptr if the mailbox is empty. should change this assert to maybe a debug print and early return(or just an if block to block execution of rest of this function. personally, i prefer single return statements from functions in fw code)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would the MBED_ASSERT not account for that?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MBED_ASSERT would actually break the program, I agree that we should remove it and just wrap the logic in an if block

}
MBED_ASSERT(m_txMailboxOneShot.free(mail) == osOK);
ThisThread::sleep_for(TX_INTERDELAY);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should revisit this and see if this sleep is actually necessary. there really should be no sleeps in the periodic functions cuz itll screw up all the timings


m_numStreamedMsgsSent++;

ThisThread::sleep_for(TX_INTERDELAY);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto comment about sleeps in periodic

void CANModule::periodic_1ms(void) {

// These functions need to be called at 1 kHz, or every 1ms
interface.rxClient();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

function should be renamed

void CANModule::periodic_10ms(void) {

// These functions need to be called every 100 Hz (10ms)
interface.txProcessor();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

function should be renamed

interface.rxClient();
}

void CANModule::periodic_10ms(void) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was there a discussion on tx being 10ms?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RX runs at 1kHz and TX runs at 100Hz

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i more meant like was there a reason those numbers were chosen? its fine if there wasn't- they seem reasonable anyways

Copy link
Member

@cindyli-13 cindyli-13 Jan 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm there's no concrete reason, other than we want RX to run faster than TX

@cindyli-13
Copy link
Member

@upadhyaydhruv Actually, I thought about this a bit and I think it doesn't make sense to have both a CANModule and a CANInterface when the CANInterface is getting changed so that it can only be used in a module context. Can you delete the existing CANInterface driver and move all the logic into CANModule? Also, can you rename CANModule to CANDriverModule?

@cindyli-13 cindyli-13 force-pushed the app-structure-redesign branch from 1cf1f09 to 07b4016 Compare January 16, 2022 19:59
Base automatically changed from app-structure-redesign to master January 18, 2022 01:46
cindyli-13 and others added 10 commits February 3, 2022 21:49
* Add modules and main.cpp skeleton

* Fix typos
* Watchdog module

* clang fix

* clang fix2

* test-watchdog

* Edited WatchdogWrapper.h

* Fixed pure virtual function errors

* fixed namespace error

* Fixed error2

* Cmake

* Cmake

* Cmake fix

* Top-level Cmake

* Changes made

* clang fix

* Update libs/utility/src/WatchdogWrapper.cpp

Co-authored-by: Cindy Li <cindyli0213@hotmail.com>

* Update test-apps/test-watchdog/src/main.cpp

Co-authored-by: Cindy Li <cindyli0213@hotmail.com>

* cmake

* Changed periodic function name

* watchdogwrapper fix

Co-authored-by: Cindy Li <cindyli0213@hotmail.com>
* PDB Module added

* CMake

* rename include

* Fixed Errors

* clang fix

* Changes made

* Made pins config private members

* clang
@upadhyaydhruv upadhyaydhruv force-pushed the can_module_restructure branch from bab7f0e to 6947dd6 Compare February 4, 2022 02:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants