Skip to content

Instantly share code, notes, and snippets.

@hemmerling
Last active August 29, 2015 14:05
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hemmerling/6b4b1bf6e635033e1313 to your computer and use it in GitHub Desktop.
Save hemmerling/6b4b1bf6e635033e1313 to your computer and use it in GitHub Desktop.
Brick Firmware - Public Gist

01 Todo-List for the "Brick Firmware" project

Brick Firmware

Short description of the project idea

Brick Firmware

Goal of the original "Brick Daemon" project ( this is not this project ! ):

Just-IT people ( e.g. IT students, IT experts, hobbyists...) can write Java / Python/ c# Script to control embedded microcontroller hardware, by accessing a web server running on their own PC by HTTP/REST, while the webserver written in Java, communicates over USB cable, by a simplified compressed TCP/IP protocol, with special microcontroller boards.

All software is OpenSource.

The buiness model of Tinkerforge is to sell special hardware ( microcontroller boards, sensors,..) so that these untrained just-it people can handle embedded systems WITHOUT C programming, and by the special hardware ( look at the shop ), WITOUT soldering, they just click interface cables together, by a simple system, so that just-it people ( or engineers with little time ) can build laboratory protoypes of data acquisition and control systems

Now the project "Brick Firmware"

We want the Brick Daemon work with given third-party microcontroller boards :-).

  • One of the founders of the project, graduated electric engineer Rolf Hemmerling, went to about 30 hands-on workshops by MCU manufacturers, with focus ARM, e.g. ST, TI, Freescale, Atmel, and some others, and mostly he got free or subventioned boards.
  • while one participant from India, also graduated electric engineer, has some 8-bit micrcontroller boards ( PIC18, 8051 ),
  • and another participant from India is "just" PC software expert.

So if you own an embedded board with an MCU similar to

ATSAM3S4C with 256 Kbyte Flash ROM, 48 KBytes SRAM.

http://www.atmel.com/devices/sam3s4c.aspx

or even less ( bare metal board, the Tinkerforge crew just starts with a true Linux board ), then you might join. Maybe even boards with much less RAM may work, thats one of the goals to find out the minimum RAM requirement.

Your board must not be ARM, can be Coldfire, Microchip Pic, Renesas,.. anything goes, its up to you to implement your own "Brick Firmware" for your board and MCU.

Alernatively you might try to make the "Brick Daemon" work without microcontroller boards, so making the PC itself ( or another PC in the Internet / Intranet ) an embedded device.

02 Setup of IDEs ( 8051 Keil uVision IDE, PIC Mikroelektronika IDE, Texas Instruments Code Composer Studio (CCS) ), for an embedded software project, on Windows

Setup of 8051 Keil uVision IDE for an 8051 Project

  1. Go with your WindowsExplorer to the "c:\users\public"
  • Create a new directory "51demo_keil".
    • If you by any reason repeat this step and so the directory exists, be shure that the directory is empty, e.g.
      • Delete the directory
      • Or delete all files and subdirectories in the directory
    • And then recreate the directory.
  • Go into the "51demo_keil" directory with WinExplorer
  • Create the 5 directories "src", "bin", "asm", "doc", "project", "inc"
  • Copy by WindowsExplorer a file "anyname.c" ( as the name suggests, it does not matter ) which you already created, into "c:\users\public\51demo_keil\src" and name it "51demo.c"
  • Call Keil uVision IDE, and create a project at "c:\users\public\51demo_keil\project" with the name "51demo"
  • Add the single file "51demo.c" from within the IDE. In case that you want to create other .c and .h files, be shure that the files are stored at "c:\users\public\51demo_keil\src". In opposite, the compiler application directory "C:\Keil\C51\INC" is no place for own files, nor should there be hard coded reference to that location in your source code. Its ok to refer to the files at directory "C:\Keil\C51\INC" in Your C code by "#include <reg52.h>". Naming rules: Use serious and explaining names for your files, not your first name or last name..
  • In the project explorer, you see now a tree:
    • "Target1"
      • "New Group"
        • "51demo.c"
  • Right-mouseclick on "Target1", select "Options for Target:Target1"
  • Select the tab "Output"
  • Press the button "Select Folder for Objects" and select the directory "c:\users\public\51demo_keil\bin". You have to go into the folder to select it, by the file selector
  • Select the tab "Listing"
  • Press the button "Select Folder for Listings" and select the directory "c:\users\public\51demo_keil\lst". You have to go into the folder to select it, by the file selector
  • Press the button "Ok"
  • Execute the menu item "File / Save all"
  • Execute the menu item "Project / Build target"
  • Give yourself feedback to your own work:
    • No go to the project directory, by the Windows Explorer. Go into each directory and sub-directory and check what files are there, and think about if the files are right at this place
    • If necessary, correct your project, if you see some files not at location where you expected it
  • To clean all targets, execute the menu item "Project / Clean targets"

Setup of PIC Mikroelektronika IDE for a PIC18 Project

  1. Go with your WindowsExplorer to the "c:\users\public"
  • Create a directory "18demo_me"
  • Go into the "51demo_me" directory with WinExplorer
  • Copy by WindowsExplorer a c demo file into "c:\users\public\51demo_me" and name it "18demo.c"
  • Call Mikroelektronika IDE, and create a project at "c:\users\public\51demo_me" with the name "18demo"
  • Add the single file "18demo.c" from within the IDE. You can access the files of your project by the "project browser".
  • Execute the menu item "Build / Build"
  • Prepare your project to be saved ( e.g. to be added and commited to a code version control system like GIT, Subversion, or to be zipped )
    • Move the *.hex files to a safe place, if you need it
    • To clean all targets, execute the menu item "Project / Clean Project Folder". Let the IDE delete the following filetypes: *.asm, *.asm.ini, *.brk, *.c.ini, *.cfg, *.cp, *.dbg, *.dct, *.dlt, *.hex, *.log, *.lst, *,mcl, *.mcppi_callertable.txt. As the IDE does not remember your settings, you have to reselect the filetypes before each saving again and again...
    • Even then, just the calling the IDE and the (automatic) loading a project, causes the generation of files of filetypes *.bmk, *.brk, *.c.ini, *.cfg, *.dct, which must be deleted manually or better by a batch file.
    • Use the batch file "cleanproject.bat" to clean a PIC project, created with the PIC Mikroelektronika IDE.

Batch file "cleanproject.bat" to clean a PIC project, created with the PIC Mikroelektronika IDE

rem
rem Batch file "cleanproject.bat" to clean a PIC project,
rem created with the PIC Mikroelektronika IDE
rem
rem Be shure that there is a final last <carriage return> at the end of file,
rem so that the file ends with an empty line
rem
rem Filetypes which are created just by calling an IDE
del *.bmk
del *.brk
del *.c.ini
del *.cfg
del *.dct
rem Filetypes created by building a project, and
rem which can be selected by "Clean Project"
del *.asm
del *.asm.ini
del *.brk
del *.c.ini
del *.cfg
del *.cp
del *.dbg
del *.dct
del *.dlt
del *.hex
del *.log
del *.lst
del *.mcl
del *.mcppi_callertable.txt
del *.user.dic
rem

See GitHub Gist "hemmerling / cleanproject.bat" https://gist.github.com/hemmerling/a8e28dbb0b177f388a38

Setup of Texas Instruments Code Composer Studio (CCS) 5.5 / 6.01 to use the MISRA-C Checker with other non-TI Projects, on Windows

  • Motivation: We want to use the TI compiler to make your ARM, Atmel, PIC18, 8051,... code MISRA-C ( see http://en.wikipedia.org/wiki/MISRA_C ) compatible. We don´t want to do linking, nor do we want to generate an executable file - we just want to use the MISRA-C preprocessor of the C compiler
  • Configure the workspace
    • Create a directory "C:\users\public\eclipse_ti"
    • At startup of the CCS application, a modal windows "Workspace Launcher. Select a workspace" asks for the URL of a workspace. -Workspace "C:\users\public\eclipse_ti" -Let CCS always ask for the workspace location: "[_] Use this as default and do not ask again"
    • If you want to restart at any point, just delete the contents of the directory "C:\users\public\eclipse_ti" :-)
  • Load an existing CCS project:
    • "File / Import...",
    • "Code Composer Studio / Existing CCS Eclipse Project"
    • Press the "Next" button
    • Press the "Browse..." button and select the root directory of an existing CCS project, so that it is displayed at "Select search-directory"
    • CCS displays now projects which it discovers in the directory, at "Discovered projects".
    • Select a project
    • Don´t let CCs copy the project into the work directory, by "[_] Copy project into workspace".
    • Press the button "Finish"
  • Make your project compatible to the TI compiler, e.g. the MSP430 compiler if your project is not for ARM ( but for Atmel, PIC18, 8051,... ) targets
  • Select a project in the project explorer
  • Execute "Project / Build Project"
  • Tip: Left-click on the "CONSOLE" and move the mouse while holding the left-mouse clicked to the window with "PROBLEMS" and "ADVICE", so that "CONSOLE", "PROBLEMS", "ADVICE" is in one window. if you have the 3 outputs in 1 window, you have more space on screen, and its easier to make the console output big. So that you can then make the "CONSOLE" window big with one mousedraw, to see what compiler messages are, instead of scrolling around in 2 directions in the little window
  • Tips to make your code compatible to the strange TI compiler
    • Include "include files" ( .h ) of your target compiler as local files, if necessary
    • Use conditional compilation ( #if #then #else ) to make slight changes in the code or the header files, if necessary
  • If you manage to compile your project with the strange TI compiler, you are ( almost ) done.
  • Configure a project to enable MISRA-C checking
  • Select a project in the project explorer
  • Execute the menu item "Project / Properties"
    • Select "Build / MSP430 Compiler / Advanced Options / MISRA-C:2004"
      • "Enabling checking of MISRA-C:2004 rules (--check_misra)". Press the button "All"
      • Press the button "Return"
  • Execute the MISRA-C checker:
    • "Project / Build Project"
  • Update your code to make it MISRA-C compatible as close as possible. If you used conditional compilation to hide changes between your target compiler and the TI compiler, be shure to apply the changes to both versions :-)

How to write C code so that it can be compiled on 8051 / PIC18 and with CCS

Main C file of 8051 project

#include "misra_8051.h"
void main(void)
{
  /* ... */
}

Include file "misra_8051.h" for 8051 projects

#ifndef MISRA_8051
#define MISRA_8051
#ifdef MSP430
/*... your specific code for msp430 */
void rc5_init(void);
#else
/* your specific code for 8051 */
#include <reg52.h>
#endif
#endif /* MISRA_8051 */

Main C file of PIC18 project

#include "misra_pic18.h"
void main(void)
{
  /* ... */
}

Include file "misra_pic18.h" for PIC18 projects

#ifndef MISRA_PIC18
#define MISRA_PIC18
#ifdef MSP430
/*... your specific code for msp430 */
void rc5_init(void);
#else
/* your specific code for PIC18 */
#endif
#endif /* MISRA_PIC18 */

03 Template of ( incomplete, but by TI CCS automatically checked ) MISRA-C Rules, taken from the document “misra.txt" of Texas Instruments Code Composer Studio

With this template, you can easily document your progress of passing the MISRA-C rules in your project. By checking [x] the checkboxes, you claim to have passed the MISRA-C rule with your project. You can add comments both on rules you did not pass, and which you passed. E.g. you can give implementation help, or explanation of the MISRA-C warnings, or tell why you can´t pass the MISRA-C rule for your project. Feel free to add multi-line comments, though in the template there is just one line with "Comments" for each rule.

  • 01 "Environment"
  • 01.01 required "All code shall conform to ISO 9899:1990 "Programming languages - C", amended and corrected by ISO/IEC 9899/COR1:1995, ISO/IEC 9899/AMD1:1995, and ISO/IEC 9899/COR2:1996."
    • Comments:
  • 02 "Language extensions"
  • 02.01 "Assembly language shall be encapsulated and isolated." ( required )
    • Comments:
  • 02.02 "Source code shall only use /* ... */ style comments." ( required )
    • Comments:
  • 02.03 "The character sequence /* shall not be used within a comment." ( required )
    • Comments:
  • 03 "Documentation"
    • Comments:
  • 04 "Character sets"
  • 04.01 "Only those excape sequences that are defined in the ISO C standard shall be used." ( required )
    • Comments:
  • 04.02 "Trigraphs shall not be used." ( required )
    • Comments:
  • 05 "Identifiers"
  • 05.02 "Identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide that identifier." ( required )
    • Comments:
  • 05.03 "A typedef name shall be a unique." ( required )
    • Comments:
  • 05.04 "A tag name shall be a unique identifier." ( required )
    • Comments:
  • 05.06 "No identifier in one name space should have the same spelling as an identifier in another name space, with the exception of structure and union member names". ( advisory )
    • Comments:
  • 05.07 "No identifier name should be reused". ( advisory )
    • Comments:
  • 06 "Types"
  • 06.01 "The plain char type shall be used only for storage and use of character values." ( required )
    • Comments:
  • 06.02 "signed and unsigned char type shall be used only of the storage and use of numeric values." ( required )
    • Comments:
  • 06.03 "typedefs that indicate size and signedness should be used in place of the basic numerical types." ( advisory )
    • Comments:
  • 06.04 "Bit fields shall only be defined to be of type unsigned inti or signed int." ( required )
    • Comments:
  • 06.05 "Bit fields of the type signed int shall be at least 2 bits long." ( required )
    • Comments:
  • 07 "Constants"
  • 07.01 "Octal extensions (other than zero) and octal escape sequences shall not be used." ( required" )
    • Comments:
  • 08 "Declarations and definitions"
  • 08.01 "Functions shall have prototype declarsions and the prototype shall be visible at both the function definition and call." ( required )
    • Comments:
  • 08.02 "Whenever an object or function is declared or defined, its type shall be explicitly stated." ( required" )
    • Comments:
  • 08.05 "There shall be no definitions of objects or functons in a header file." id="8.5" ( required )
    • Comments:
  • 08.06 "Functions shall be declared at file scope." ( required" )
    • Comments:
  • 08.07 "Objects shall be defined at block scope if they are only accessed from within a single function." ( required )
    • Comments:
  • 08.08 "An external object or function shall be declared in one and only one file." ( required )
    • Comments:
  • 08.11 "The static storage class specifier shall be used in definitions and declarations of objects and functions that have internal linkage." ( required )
    • Comments:
  • 08.12 "When an array is declared with external linkage, its size shall be stated explicitly or defined implicitly by initialization." ( required )
    • Comments:
  • 09 "Initialization"
  • 09.01 "All automatic variables shall have been assigned a value before being used." ( required )
    • Comments:
  • 09.02 "Braces shall be used to indicate and match the structure in the non-zero initialization of arrays and structures." ( required )
    • Comments:
  • 09.03 "In an enumerator list, the "=" construct shall not be used to explicitly initialize members other than the first, unless all items are explicitly initialized." ( required )
    • Comments:
  • 10 "Arithmetic type conversions"
  • 10.01 "The value of an expression of integer type shall not be implicitly converted to a different underlying type if: a) it is not a conversion to a wider integer type of the same signedness, or b) the expression is complex, or c) the expression is not constant and is a function argument, or d) the expression is not constant and is a return expression." ( required )
    • Comments:
  • 10.02 "The value of an expression of floating type shall not be implicitly converted to a different type if: a) it is not a conversion to a wider floating type, or b) the expression is complex, or c) the expression is a function argument, or d) the expression is a return expression." ( required" )
    • Comments:
  • 10.03 "The value of a complex expression of integer type may only be cast to a type that is narrower and of the same signedness as the underlying type of the expression." ( required )
    • Comments:
  • 10.04 "The value of a complex expression of floating type may only be cast to a narrower floating type." ( required )
    • Comments:
  • 10.05 "If the bitwise operations ~ and << are applied to an operand of underlying type unsigned char or unsigned short, the result shall immediately cast to the underlying type of the operand." ( required )
    • Comments:
  • 10.06 "A "U" suffix shall be applied to all constans of unsigned type." ( required )
    • Comments:
  • 11 "Pointer type conversions"
  • 11.01 "Conversions shall not be performed between a pointer to a function and any type other than an integral type." ( required )
    • Comments:
  • 11.02 "Conversions shall not be perfornmed between a pointer to object and any type other than an integral type, another pointer to object type or a pointer to void." id="11.2" ( required )
    • Comments:
  • 11.03 "A cast should not be performed between a pointer type and an integral type." ( advisory )
    • Comments:
  • 11.04 "A cast should not be performed between a pointer to object type and a different pointer to object type." ( advisory )
    • Comments:
  • 11.05 "A cast shall not be performed that removes any const or volatile qualifications from the type addressed by a pointer." ( required )
    • Comments:
  • 12 "Expressions"
  • 12.01 "Limited dependence should be placed on C's operator precedence rules in expressions." ( advisory )
    • Comments:
  • 12.02 "The value of an expression shall be the same under any order of evaluation that the standard permits." ( required )
    • Comments:
  • 12.03 "The sizeof operator shall not be used on expression that contain side effects." ( required )
    • Comments:
  • 12.04 "The right-hand operand of a logical && or || operator shall not contain side effects." ( required )
    • Comments:
  • 12.05 "The operations of a logical && or || shall be primary-expressions." ( required )
    • Comments:
  • 12.06 "The operands of logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean should not be used as operands to operators other than (&&, || and !)." ( advisory )
    • Comments:
  • 12.07 "Bitwise operators shall not be applied to operands whose underlying type is signed." ( required )
    • Comments:
  • 12.08 "The right-hand operand of a shift operator shall lie between zero and one less than the width in bits of the underlying type of the left-hand operand." ( required )
    • Comments:
  • 12.09 "The unary minus operator shall not be applied to an expression whose underlying type is unsigned." ( required )
    • Comments:
  • 12.10 "The comma operator shall not be used." ( required )
    • Comments:
  • 12.13 "The increment (++ and decrement (--) operators should not be mixed with other operators in an expression." ( advisory )
    • Comments:
  • 13 "Control statement expressions"
  • 13.01 "Assignment operators shall not be used in expressiopns that yield a Boolean value." ( required )
    • Comments:
  • 13.02 "Tests of a value against zero should be made explicit, unless the operand is effectively Boolean." ( advisory )
    • Comments:
  • 13.03 "Floating-point expressions shall not be tested for equality nor inequality." ( required )
    • Comments:
  • 13.04 "The controlling expression of a for statement shall not contain any objects of floating type." ( required )
    • Comments:
  • 13.05 "The three expressions of a for statement shall be concerned only with loop control." ( required )
    • Comments:
  • 13.06 "Numeric variables being used within a for loop for iteration counting shall not be modified in the body of the loop." ( required )
    • Comments:
  • 14 "Control Flow"
  • 14.01 "There shall be no unreachable code." ( required )
    • Comments:
  • 14.02 "All non-null statements shall either: a) have at least one side effect however executed, or b) cause cohntrol flow to change." ( required )
    • Comments:
  • 14.03 "Before preprocessing, a null statement shall only occur on a line by itself; it may be followed by a comment provided that the first character following the null statement is a white-space character." ( required )
    • Comments:
  • 14.04 "The goto statement shall not be used." ( required )
    • Comments:
  • 14.05 "The continue statement shall not be used." ( required )
    • Comments:
  • 14.06 "For any iteration statement there shall be at most one break statement used for loop termination." ( required )
    • Comments:
  • 14.07 "A function shall have a single point of exit at the end of the function." ( required )
    • Comments:
  • 14.08 "The statement forming the body of a switch, while, do ... while or for statement shall be a compound statement." ( required )
    • Comments:
  • 14.09 "An if (expression) construct shall be followed by a compound statement. The else keyword shall be followed by either a compound statement, or another if statement." ( required )
    • Comments:
  • 14.10 "All if ... else if constructs shall be terminated with an else clause." ( required )
    • Comments:
  • 15 "Switch statements"
  • 15.01 "A switch label shall only be used when the most closely-enclosing compound statement is the body of a switch statement." ( required )
    • Comments:
  • 15.02 "An unconditional break statement shall terminate every non-empty switch clause." ( required )
    • Comments:
  • 15.03 "The final clause of a switch statement sahll be the default clause." ( required )
    • Comments:
  • 15.04 "A switch statement shall not represent a value that is effectively Boolean." ( required )
    • Comments:
  • 15.05 "Every switch statement shall have at least one case clause." ( required )
    • Comments:
  • 16 "Functions"
  • 16.01 "Functions shall not be defined with variable numbers of arguments." ( required )
    • Comments:
  • 16.03 "Identifiers shall be given for all of the parameters in a functuion protoype declaration." ( required )
    • Comments:
  • 16.04 "The identifiers used in the declaration and definition of a function shall be identical." ( required )
    • Comments:
  • 16.05 "Functions with no parameters shall be declared with parameter type void." ( required )
    • Comments:
  • 16.07 "A pointer parameter in a function prototype shall be declared as pointer to const if the pointer is not used to modify the adressed object." ( advisory )
    • Comments:
  • 16.08 "All exit paths from a function with non-void return type shall have an explicit return statement with an expression." ( required )
    • Comments:
  • 16.09 "A function identifier shall only be used with either a preceding &, or with a parenthesized parameter list, which may be empty." ( required )
    • Comments:
  • 17 "Pointers and arrays"
  • 17.04 "Array indexing shall be the only allowed form of pointer arithmetic." ( required )
    • Comments:
  • 17.05 "The declaration of objects should contain no more than 2 levels of pointer indirection." ( advisory )
    • Comments:
  • 17.06 "The address of an object with automatic storage shall not be assigned to another object that may persist after the first object has ceased to exist." ( required )
    • Comments:
  • 18 "Structures and unions"
  • 18.01 "All structure or union types shall be complete at the end of a translation unit." ( required )
    • Comments:
  • 18.04 "Unions shall not be used." ( required )
    • Comments:
  • 19 "Preprocessing directives"
  • 19.01 "#include statements in a file should only be preceded by other preprocessor directives or comments." ( advisory )
    • Comments:
  • 19.02 "Non-standard characters should not occur in header file hnames in #include directives." ( advisory )
    • Comments:
  • 19.03 "The #include directive shall be followed by either a or "filename" sequence." ( required )
    • Comments:
  • 19.04 "C macros shall only expand to a braced initializer, a constant, a parenthesized expression, a type qualifier, a storage class specifier, or a do-while-zero construct." ( required )
    • Comments:
  • 19.05 "Macros shall not be #define'd or #undef'd within a block." ( required )
    • Comments:
  • 19.06 "#undef shall not be used." id="19.6" ( required )
    • Comments:
  • 19.07 "A function should be used in preference to a function-like macro." ( advisory )
    • Comments:
  • 19.08 "A function-like macro shall not be invoked without all of its arguments." ( "required" )
    • Comments:
  • 19.09 "Arguments to a function-like macro shall not contain tokens that look like preprocessing directives." ( required )
    • Comments:
  • 19.10 "In the definition of a function-like macro each instance of a parameter shall be enclosed in parentheses unless it it used as the operand of # or ##." ( required )
    • Comments:
  • 19.11 "All macro identifiers in preprocessor directives shall be defined before use, except in #ifdef and #ifndef preprocessor directives and the defined() operator." ( required )
    • Comments:
  • 19.12 "There shall be at most one occurrence of the # or ## preprocessor operators in a single macro definition." ( required )
    • Comments:
  • 19.13 "The # and ## preprocessor operators should not be used." ( advisory )
    • Comments:
  • 19.14 "The defined preprocessor operator shall only be used in one of the two standard forms." ( required )
    • Comments:
  • 19.15 "Precautions shall be taken in order to prevent the contents of a header file being included twice." ( required )
    • Comments:
  • 19.16 "Preprocessoing directives shall be syntactically meaningful even when excluded by the preprocessor." ( required )
    • Comments:
  • 19.17 "All #else, #elif and #endif preprocessor directives shall reside in the same file as the #if or #ifdef directive to which they are related." ( required )
    • Comments:
  • 20 "Standard libraries"
  • 20.01 "Reserved identifiers, macros and functions in the standard library, shall not be defined, redefined or undefined." (required )
    • Comments:
  • 20.02 "The names of standard library macros, obhjects and functions shall not be reused." ( required )
    • Comments:
  • 20.04 "Dynamic heap memory allocation shall not be used." ( required )
    • Comments:
  • 20.05 "The error indicator errno shall not be used." ( required )
    • Comments:
  • 20.06 "The macro offsetof, in library <stddef.h>, shall not be used." ( required )
    • Comments:
  • 20.07 "The setjmp macro and the longjmp function shall not be used." ( required )
    • Comments:
  • 20.08 "The signal handling facilities of <signal.h> shall not be used." ( required )
    • Comments:
  • 20.09 "The input/output library <stdio.h> shall not be used in production code." ( required )
    • Comments:
  • 20.10 "The library functions atof, atoi and atol from library <stdlib.h> shall not be used." ( required )
    • Comments:
  • 20.11 "The library functions abort, exit, getenv and system from library <stdlib.h> shall not be used." ( required )
    • Comments:
  • 20.12 "The time handling functions of library <time.h> shall not be used." ( required )
    • Comments:

05 Teamwork is not compatible with these attitudes...

  • "I'm a programmer and I'm used to work in a way where I do my work, do not check if I am wrong or not, present the work to my manager / client and wait for their feedback on my faults".
  • "I never follow your project [rules] because you are developer and I am engineer".
  • "yes...i know that you dont like my attitude"
  • "..comment is not my task that is done by software developer" by the mouth of an electric engineer, who develops both embedded hardware and software.
  • "If i do in my way you did not accept it".
  • Though I graduated as engineer after a valuable 4-years college education, I can't do self-contained work even for the most simple operations.
    • I need always detailed instructions on the level of a process description - step by step. I never think about my work, e.g. if there is a simple typing mistake, copy+paste mistake or other obvious fault, I won´t realize, but follow the instructions stupidly.
    • So I won´t address my team / boss / customer argueing that "there might be some mistake but I am shure that I did the right work, by following corrected instructions". I never address my my team / boss / customer, besides for asking "tell me how to do so".
    • I also can´t give feedback to my own work, i.e. I can´t describe why I failed, what informations were / are missing, and what I need to have success.
  • "Seriously you are always create a pressure on me", "plz dont force me"
  • "I changed syntax but the working principle is same" ( the candidate changed the C code from a loop which polls a device to an interrupt-based system ).
  • "I dont understand what is the function of a software documentation generator ( e.g. DOXYGEN ) in company which develops embedded controllers for the automotive industry".
  • He names the private website of an Internet buddy twice in his GitHub profile as if he is a staff member, and refused to remove this violation of data privacy and intellectual property, by reasoning "I am unpaid worker in your company ....so I dont remove from my github account". Of course he never did any unpaid work for his Internet buddy.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment