Giter VIP home page Giter VIP logo

isotp-c's Introduction

Welcome to my Corner of GitHub

My name's Simon and I'm an embedded software developer by profession, I also own a small business located in Germany.

During my dayjob, I develop telematics and diagnostics software using ISOBUS for a German agricultural machinery manufacturer.
My small business develops smaller-scale applications for multiple platforms, hosts web applications, email and gameservers, along with providing IT services and custom PC-building services.

I also have an Internet presence where I will occasionally write a little blog post, tutorial or something similar and then delete it because I didn't like it after a few weeks!.

If you're here, you've probably stumbled on one of my open-source projects and might be looking for documentation. Not to worry, I have a link for that, too! It's not the prettiest portion of my website, but I'll get to that eventually. At least it's permanent darkmode.

My Tech Stack

My Main Machines

My main machines which I use for everyday tasks, like gaming, developing and just general gits and shiggles are in no particular order:

  • M1 Pro MacBook Pro (16")
  • Custom-Built Gaming PC running Windows (+ WSL) / Linux
    • Ryzen 7 7700X
    • RTX 3080 10GiB
    • 32GiB DDR5 5600
    • MSI X670E MPG Carbon
  • Xiaomi Mi 13 Pro

My Favourite Languages

I develop software for a living and as a hobby, and have done so for over a decade now. In the meantime I've come to love and hate some programming languagues.

Here's a list of my favourites (in no particular order)!

  • C++
  • C#
  • Lua
  • Bash
  • Swift

Languages I won't touch with a 50ft pole if I don't have to

As with all things in life, some languages just don't fit a given person's personality. Be it you've shot yourself in the foot, or the "core features"/"selling points" of the language are simply infuriating to you.

For me, those are:

  • Python
  • Visual Basic
  • JavaScript (ECMAscript, whatever)
  • Perl

Languages I'm aquainted with

You have friends, you have enemies and then you have those in life, whom you don't really know, but are curious to know more about. For me, these languages are in that weird area of my brain where they make me think about them, and try to find reasons to love or hate.

  • Rust
  • Objective C

My Projects

My projects range from public to private, to weird semi-complete WIPs. A lot of these I've started but due to circumstances in my life, couldn't complete, or found the current state usable enough to just keep them as-is.

A lot of recent projects have come into life because of my private IT stuff, but also because of passion projects at work, where I've created better versions for my personal use.

Just scroll through my repositories and see if you like anything.

isotp-c's People

Contributors

brandonros avatar driftregion avatar garaminowicz avatar jgressma avatar kazetsukaimiko avatar lishen2 avatar maclark88 avatar pgreenland avatar pschmale-grimme avatar simoncahill avatar speedy-h avatar tictacmenthe avatar woodz- avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

isotp-c's Issues

Building a static library unnecessarily forces adoption of PIC (position independent code)

Hi,

I'm in the process of integrating isotp-c into a microcontroller project.

We're using CMake so have included the project as a subdirectory setting the isotpc_STATIC_LIBRARY configuration option.

As noted in the project README, position independent code (PIC) is always forced on:

-fPIC

I was hoping to understand the rationale behind this, as it's typically only required for dynamic libraries.

Additionally flagging the target_compile_options as public means they're propagated to dependencies. Causing build options to sort of "leak" out of the library into the modules which link to it.

isotp PUBLIC

In our case our startup code doesn't include any support for PIC, as everything is statically linked. I was surprised to find the system crashing at startup, having linked in isotp-c. Seems its compile definitions had spread and attempted to enable PIC on the module which links to the library causing the system to crash as PIC wasn't properly setup.

For the moment I've just commented out the PIC option but was hoping to submit a PR. Either to make it configurable via cmake, or to only include it when requesting a shared library be built.

I'd propose to make the other compile options private, such that they're only applied to the isotp-c library itself. They're not bad in terms of what they're looking to do. We've got everything but -Wno-unknown-pragmas turned on ourselves already, so aside from PIC didn't really notice them. They probably shouldn't be forced upon the wider project as a whole though.

Would appreciate your thoughts.

Great work on continuing the development of the library btw!

Thanks,

Phil

Arbitration for transmit messages.

I do not see where transmits are able to clear the transmit status.
It appears there may need to be a receive loop that processes the arbitration messages from the receiver during a transmit sequence. Transmit works with a small frame (7 bytes or less) that requires no arbitration.

In addition, I do not see where the uint32_t receive_arbitration_id is ever used.

Never executed else if branch in time calculation

The if condition here

if (us <= 127000) {
will always be true before the else if branch
} else if (us >= 100 && us <= 900) {
could ever become true.

I propose:

/* st_min to microsecond */
static uint8_t isotp_us_to_st_min(uint32_t us) {
    if (us <= 127000) {
        if (us >= 100 && us <= 900) 
        {
            return 0xF0 + (us / 100);
        } 
        else 
        {
            return us / 1000;
        }
    }
    return 0;
}

[Edit:] Same here:

isotp-c/isotp.c

Lines 21 to 25 in 5ddce32

if (st_min <= 0x7F) {
return st_min * 1000;
} else if (st_min >= 0xF1 && st_min <= 0xF9) {
return (st_min - 0xF0) * 100;
}

Documentation bug; timeout in millis instead of microseconds

Reported by Mark,

There is a bug in the documentation concerning the timer values.

I am confused as to whether the return should be in milliseconds or microseconds as both units are referred to in the documentation.

In the code:

        link->send_timer_st = isotp_user_get_us();

In the documentation:

/* required, return system tick, unit is millisecond */
uint32_t isotp_user_get_ms(void) {
    // ...
}

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.