From the interviewee’s perspective, you can learn a lot about the person that has written or administered the test. Is the test designed to show off the writer’s knowledge of the minutiae of the ANSI standard rather than to test practical know-how? Does it test ludicrous knowledge, such as the ASCII values of certain characters? Are the questions heavily slanted towards your knowledge of system calls and memory allocation strategies, indicating that the writer may spend his time programming computers instead of embedded systems? If any of these are true, then I know I would seriously doubt whether I want the job in question.

From the interviewer’s perspective, a test can reveal several things about the candidate.  Primarily, one can determine the level of the candidate’s knowledge of C.  However, it is also very interesting to see how the person responds to questions to which they do not know the answers.  Do they make intelligent choices, backed up with some good intuition, or do they just guess?  Are they defensive when they are stumped, or do they exhibit a real curiosity about the problem, and see it as an opportunity to learn something?  I find this information as useful as their raw performance on the test.

With these ideas in mind, I have attempted to construct a test that is heavily slanted towards the requirements of embedded systems. This is a lousy test to give to someone seeking a job writing compilers! The questions are almost all drawn from situations I have encountered over the years.  Some of them are very tough; however, they should all be informative.

This test may be given to a wide range of candidates. Most entry-level applicants will do poorly on this test, while seasoned veterans should do very well. Points are not assigned to each question, as this tends to arbitrarily weight certain questions.  However, if you choose to adapt this test for your own uses, feel free to assign scores.

Preprocessor

1. Using the #define statement, how would you declare a manifest constant that returns the number of seconds in a year? Disregard leap years in your answer.

#define SECONDS_PER_YEAR (60UL * 60UL * 24UL * 365UL)

I’m looking for several things here:

(a)    Basic knowledge of the #define syntax (i.e. no semi-colon at the end, the need to parenthesize etc.).

(b)    A good choice of name, with capitalization and underscores.

(c)    An understanding that the pre-processor will evaluate constant expressions for you. Thus, it is clearer, and penalty free to spell out how you are calculating the number of seconds in a year, rather than actually doing the calculation yourself.

(d)    A realization that the expression will overflow an integer argument on a 16 bit machine – hence the need for the L, telling the compiler to treat the expression as a Long.

(e)    As a bonus, if you modified the expression with a UL (indicating unsigned long), then you are off to a great start because you are showing that you are mindful of the perils of signed and unsigned types – and remember, first impressions count!

2. Write the ‘standard’ MIN macro. That is, a macro that takes two arguments and returns the smaller of the two arguments.

#define MIN(A,B)       ((A) <=  (B) ? (A) : (B))

The purpose of this question is to test the following:

(a)    Basic knowledge of the #define directive as used in macros. This is important, because until the inline operator becomes part of standard C, macros are the only portable way of generating inline code. Inline code is often necessary in embedded systems in order to achieve the required performance level.

(b)    Knowledge of the ternary conditional operator.  This exists in C because it allows the compiler to potentially produce more optimal code than an if-then-else sequence. Given that performance is normally an issue in embedded systems, knowledge and use of this construct is important.

(c)    Understanding of the need to very carefully parenthesize arguments to macros.

(d)    I also use this question to start a discussion on the side effects of macros, e.g. what happens when you write code such as :

least = MIN(*p++, b);

3. What is the purpose of the preprocessor directive #error?

Either you know the answer to this, or you don’t. If you don’t, then see reference 1. This question is very useful for differentiating between normal folks and the nerds. It’s only the nerds that actually read the appendices of C textbooks that find out about such things.  Of course, if you aren’t looking for a nerd, the candidate better hope she doesn’t know the answer.

Infinite Loops

4. Infinite loops often arise in embedded systems. How does one code an infinite loop in C?

There are several solutions to this question. My preferred solution is:

while(1)

{

…

}

Another common construct is:

for(;;)

{

…

}

Personally, I dislike this construct because the syntax doesn’t exactly spell out what is going on.  Thus, if a candidate gives this as a solution, I’ll use it as an opportunity to explore their rationale for doing so.  If their answer is basically – ‘I was taught to do it this way and I have never thought about it since’ – then it tells me something (bad) about them. Conversely, if they state that it’s the K&R preferred method and the only way to get an infinite loop passed Lint, then they score bonus points.

A third solution is to use a goto:

Loop:

…

goto Loop;

Candidates that propose this are either assembly language programmers (which is probably good), or else they are closet BASIC / FORTRAN programmers looking to get into a new field.

Data declarations

5. Using the variable a, write down definitions for the following:

(a) An integer

(b) A pointer to an integer

(c) A pointer to a pointer to an integer

(d) An array of ten integers

(e) An array of ten pointers to integers

(f) A pointer to an array of ten integers

(g) A pointer to a function that takes an integer as an argument and returns an integer

(h)    An array of ten pointers to functions that take an integer argument and return an integer.

The answers are:

(a)    int a;                 // An integer

(b)    int *a;               // A pointer to an integer

(c)    int **a;             // A pointer to a pointer to an integer

(d)    int a[10];          // An array of 10 integers

(e)    int *a[10];        // An array of 10 pointers to integers

(f)     int (*a)[10];     // A pointer to an array of 10 integers

(g)    int (*a)(int);     // A pointer to a function a that takes an integer argument and returns an integer

(h)    int (*a[10])(int); // An array of 10 pointers to functions that take an integer argument and return an integer

People often claim that a couple of these are the sorts of thing that one looks up in textbooks – and I agree. While writing this article, I consulted textbooks to ensure the syntax was correct. However, I expect to be asked this question (or something close to it) when in an interview situation. Consequently, I make sure I know the answers – at least for the few hours of the interview.  Candidates that don’t know the answers (or at least most of them) are simply unprepared for the interview.  If they can’t be prepared for the interview, what will they be prepared for?

Static

6. What are the uses of the keyword static?

This simple question is rarely answered completely.  Static has three distinct uses in C:

(a)    A variable declared static within the body of a function maintains its value between function invocations.

(b)    A variable declared static within a module[1], (but outside the body of a function) is accessible by all functions within that module. It is not accessible by functions within any other module.  That is, it is a localized global.

(c)    Functions declared static within a module may only be called by other functions within that module. That is, the scope of the function is localized to the module within which it is declared.

Most candidates get the first part correct.  A reasonable number get the second part correct, while a pitiful number understand answer (c).  This is a serious weakness in a candidate, since they obviously do not understand the importance and benefits of localizing the scope of both data and code.

Const

7. What does the keyword const mean?

As soon as the interviewee says ‘const means constant’, I know I’m dealing with an amateur. Dan Saks has exhaustively covered const in the last year, such that every reader of ESP should be extremely familiar with what const can and cannot do for you. If you haven’t been reading that column, suffice it to say that const means “read-only”.  Although this answer doesn’t really do the subject justice, I’d accept it as a correct answer. (If you want the detailed answer, then read Saks’ columns – carefully!).

If the candidate gets the answer correct, then I’ll ask him these supplemental questions:

What do the following incomplete[2] declarations mean?

const int a;

int const a;

const int *a;

int * const a;

int const * a const;

The first two mean the same thing, namely a is a const (read-only) integer.  The third means a is a pointer to a const integer (i.e., the integer isn’t modifiable, but the pointer is). The fourth declares a to be a const pointer to an integer (i.e., the integer pointed to by a is modifiable, but the pointer is not). The final declaration declares a to be a const pointer to a const integer (i.e., neither the integer pointed to by a, nor the pointer itself may be modified).

If the candidate correctly answers these questions, I’ll be impressed.

Incidentally, one might wonder why I put so much emphasis on const, since it is very easy to write a correctly functioning program without ever using it.  There are several reasons:

(a)    The use of const conveys some very useful information to someone reading your code. In effect, declaring a parameter const tells the user about its intended usage.  If you spend a lot of time cleaning up the mess left by other people, then you’ll quickly learn to appreciate this extra piece of information. (Of course, programmers that use const, rarely leave a mess for others to clean up…)

(b)    const has the potential for generating tighter code by giving the optimizer some additional information.

(c)    Code that uses const liberally is inherently protected by the compiler against inadvertent coding constructs that result in parameters being changed that should not be.  In short, they tend to have fewer bugs.

Volatile

8. What does the keyword volatile mean? Give three different examples of its use.

A volatile variable is one that can change unexpectedly.  Consequently, the compiler can make no assumptions about the value of the variable.  In particular, the optimizer must be careful to reload the variable every time it is used instead of holding a copy in a register.  Examples of volatile variables are:

(a)    Hardware registers in peripherals (e.g., status registers)

(b)    Non-stack variables referenced within an interrupt service routine.

(c)    Variables shared by multiple tasks in a multi-threaded application.

If a candidate does not know the answer to this question, they aren’t hired.  I consider this the most fundamental question that distinguishes between a ‘C programmer’ and an ‘embedded systems programmer’.  Embedded folks deal with hardware, interrupts, RTOSes, and the like. All of these require volatile variables. Failure to understand the concept of volatile will lead to disaster.

On the (dubious) assumption that the interviewee gets this question correct, I like to probe a little deeper, to see if they really understand the full significance of volatile. In particular, I’ll ask them the following:

(a) Can a parameter be both const and volatile? Explain your answer.

(b) Can a pointer be volatile? Explain your answer.

(c) What is wrong with the following function?:

int square(volatile int *ptr)

{

return *ptr * *ptr;

}

The answers are as follows:

(a)    Yes. An example is a read only status register. It is volatile because it can change unexpectedly. It is const because the program should not attempt to modify it.

(b)    Yes. Although this is not very common. An example is when an interrupt service routine modifies a pointer to a buffer.

(c)    This one is wicked.  The intent of the code is to return the square of the value pointed to by *ptr. However, since *ptr points to a volatile parameter, the compiler will generate code that looks something like this:

int square(volatile int *ptr)

{

int a,b;

a = *ptr;

b = *ptr;

return a * b;

}

Since it is possible for the value of *ptr to change unexpectedly, it is possible for a and b to be different. Consequently, this code could return a number that is not a square!  The correct way to code this is:

long square(volatile int *ptr)

{

int a;

a = *ptr;

return a * a;

}

Bit Manipulation

9. Embedded systems always require the user to manipulate bits in registers or variables. Given an integer variable a, write two code fragments. The first should set bit 3 of a. The second should clear bit 3 of a. In both cases, the remaining bits should be unmodified.

These are the three basic responses to this question:

(a) No idea. The interviewee cannot have done any embedded systems work.

(b) Use bit fields.  Bit fields are right up there with trigraphs as the most brain-dead portion of C.  Bit fields are inherently non-portable across compilers, and as such guarantee that your code is not reusable.  I recently had the misfortune to look at a driver written by Infineon for one of their more complex communications chip.  It used bit fields, and was completely useless because my compiler implemented the bit fields the other way around. The moral – never let a non-embedded person anywhere near a real piece of hardware![3]

(c) Use #defines and bit masks.  This is a highly portable method, and is the one that should be used.  My optimal solution to this problem would be:

#define BIT3       (0×1 << 3)

static int a;

void set_bit3(void) {

a |= BIT3;

}

void clear_bit3(void) {

a &= ~BIT3;

}

Some people prefer to define a mask, together with manifest constants for the set & clear values.  This is also acceptable.  The important elements that I’m looking for are the use of manifest constants, together with the |= and &= ~ constructs.

Accessing fixed memory locations

10. Embedded systems are often characterized by requiring the programmer to access a specific memory location. On a certain project it is required to set an integer variable at the absolute address 0x67a9 to the value 0xaa55. The compiler is a pure ANSI compiler. Write code to accomplish this task.

This problem tests whether you know that it is legal to typecast an integer to a pointer in order to access an absolute location.  The exact syntax varies depending upon one’s style. However, I would typically be looking for something like this:

int *ptr;

ptr = (int *)0x67a9;

*ptr = 0xaa55;

A more obfuscated approach is:

*(int * const)(0x67a9) = 0xaa55;

Even if your taste runs more to the second solution, I suggest the first solution when you are in an interview situation.

Interrupts

11. Interrupts are an important part of embedded systems. Consequently, many compiler vendors offer an extension to standard C to support interrupts. Typically, this new key word is __interrupt. The following code uses __interrupt to define an interrupt service routine. Comment on the code.

__interrupt double compute_area(double radius) {

{

double area = PI * radius * radius;

printf(“\nArea = %f”, area);

return area;

}

This function has so much wrong with it, it’s almost tough to know where to start.

(a)    Interrupt service routines cannot return a value. If you don’t understand this, then you aren’t hired.

(b)    ISR’s cannot be passed parameters. See item (a) for your employment prospects if you missed this.

(c)    On many processors / compilers, floating point operations are not necessarily re-entrant. In some cases one needs to stack additional registers, in other cases, one simply cannot do floating point in an ISR. Furthermore, given that a general rule of thumb is that ISRs should be short and sweet, one wonders about the wisdom of doing floating point math here.

(d)    In a similar vein to point (c), printf() often has problems with reentrancy and performance.  If you missed points (c) & (d) then I wouldn’t be too hard on you.  Needless to say, if you got these two points, then your employment prospects are looking better and better.

Code Examples

12. What does the following code output and why?

void foo(void)

{

unsigned int a = 6;

int b = -20;

(a+b > 6) ? puts(“> 6″) : puts(“<= 6″);

}

This question tests whether you understand the integer promotion rules in C – an area that I find is very poorly understood by many developers.  Anyway, the answer is that this outputs “> 6”.  The reason for this is that expressions involving signed and unsigned types have all operands promoted to unsigned types. Thus –20 becomes a very large positive integer and the expression evaluates to greater than 6. This is a very important point in embedded systems where unsigned data types should be used frequently (see reference 2).  If you get this one wrong, then you are perilously close to not being hired.

13. Comment on the following code fragment?

unsigned int zero = 0;

unsigned int compzero = 0xFFFF;       /*1’s complement of zero */

On machines where an int is not 16 bits, this will be incorrect. It should be coded:

unsigned int compzero = ~0;

This question really gets to whether the candidate understands the importance of word length on a computer.  In my experience, good embedded programmers are critically aware of the underlying hardware and its limitations, whereas computer programmers tend to dismiss the hardware as a necessary annoyance.

By this stage, candidates are either completely demoralized – or they are on a roll and having a good time.  If it is obvious that the candidate isn’t very good, then the test is terminated at this point. However, if the candidate is doing well, then I throw in these supplemental questions.  These questions are hard, and I expect that only the very best candidates will do well on them. In posing these questions, I’m looking more at the way the candidate tackles the problems, rather than the answers. Anyway, have fun…

Dynamic memory allocation.

14. Although not as common as in non-embedded computers, embedded systems still do dynamically allocate memory from the heap.  What are the problems with dynamic memory allocation in embedded systems?

Here, I expect the user to mention memory fragmentation, problems with garbage collection, variable execution time, etc. This topic has been covered extensively in ESP, mainly by Plauger.  His explanations are far more insightful than anything I could offer here, so go and read those back issues! Having lulled the candidate into a sense of false security, I then offer up this tidbit:

What does the following code fragment output and why?

char *ptr;

if ((ptr = (char *)malloc(0)) == NULL) {

puts(“Got a null pointer”);

}

else {

puts(“Got a valid pointer”);

}

This is a fun question.  I stumbled across this only recently, when a colleague of mine inadvertently passed a value of 0 to malloc, and got back a valid pointer! After doing some digging, I discovered that the result of malloc(0) is implementation defined, so that the correct answer is ‘it depends’. I use this to start a discussion on what the interviewee thinks is the correct thing for malloc to do.  Getting the right answer here is nowhere near as important as the way you approach the problem and the rationale for your decision.

Typedef

15. Typedef is frequently used in C to declare synonyms for pre-existing data types.  It is also possible to use the preprocessor to do something similar. For instance, consider the following code fragment:

#define dPS  struct s *

typedef  struct s * tPS;

The intent in both cases is to define dPS and tPS to be pointers to structure s.  Which method (if any) is preferred and why?

This is a very subtle question, and anyone that gets it right (for the right reason) is to be congratulated or condemned (“get a life” springs to mind). The answer is the typedef is preferred. Consider the declarations:

dPS p1,p2;

tPS p3,p4;

The first expands to

struct s * p1, p2;

which defines p1 to be a pointer to the structure and p2 to be an actual structure, which is probably not what you wanted. The second example correctly defines p3 & p4 to be pointers.

Obfuscated syntax

16. C allows some appalling constructs.  Is this construct legal, and if so what does this code do?

int a = 5, b = 7, c;

c = a+++b; 

This question is intended to be a lighthearted end to the quiz, as, believe it or not, this is perfectly legal syntax.  The question is how does the compiler treat it? Those poor compiler writers actually debated this issue, and came up with the “maximum munch” rule, which stipulates that the compiler should bite off as big a (legal) chunk as it can.  Hence, this code is treated as:

c = a++ + b;

Thus, after this code is executed, a = 6, b = 7 & c = 12;

If you knew the answer, or guessed correctly – then well done.  If you didn’t know the answer then I would not consider this to be a problem.  I find the biggest benefit of this question is that it is very good for stimulating questions on coding styles, the value of code reviews and the benefits of using lint.

Well folks, there you have it.  That was my version of the C test.  I hope you had as much fun doing it as I had writing it.  If you think the test is a good test, then by all means use it in your recruitment.  Who knows, I may get lucky in a year or two and end up being on the receiving end of my own work.

References:

1. In Praise of the #error directive. ESP September 1999.
2. Efficient C Code for Eight-Bit MCUs. ESP November 1988.

[2] I’ve had complaints that these code fragments are incorrect syntax. This is correct. However, writing down syntactically correct code pretty much gives the game away.

[3] I’ve recently softened my stance on bit fields. At least one compiler vendor (IAR) now offers a compiler switch for specifying the bit field ordering. Furthermore the compiler generates optimal code with bit field defined registers – and as such I now do use bit fields in IAR applications.

Until recently closed circuit underwater breathing apparatus, commonly referred to as rebreathers, have been reserved purely for technical and military divers. Poseidon Diving Systems wanted to bring rebreathers to the recreational dive market, but lacked the in-house expertise to do so. Therefore they approached our client Stone Aerospace for help. Stone Aerospace promptly recommended that RMB be brought into the project to provide electronics and firmware expertise.

Re-inventing the Rebreather

Poseidon’s concept was audacious in scope. Execution required innovation and expertise on a higher level than competing products. During the initial brain storming session, RMB made critical contributions that surpassed industry norms. This innovation resulted in multiple patent filings and many trade secrets. The design consists of a distributed network of processors, together with a smart battery charger. In all, RMB designed six separate PCBs, wrote 134,000 lines of embedded code, and provided hundreds of pages of technical documentation to support CE certification.

Best in Class

The Poseidon Diving Systems MKVI rebreather was successfully launched and is finding wide and enthusiastic support in the market place. Its technical innovations have caused both consternation and admiration in the industry, and have firmly established Poseidon as the market leader.

Sensortech Systems has long been the leader in moisture measurement using RF technology. When they decided to expand their product offerings to include an online moisture gauge based upon near-infrared adsorption, they knew they needed a partner who could handle a wide range of technical problems including very low level signal measurement, brushless DC motor control, and complex computational algorithms. There were also challenges dealing with a plethora of connectivity options including TCP/IP, IrDA, and the usual field bus protocols such as DeviceNet, Profibus and Modbus.

Understanding the Industry

RMB crafted a solution that was half the size of competing products while offering dramatically more functionality at a significantly lower cost. We were cognizant that commissioning costs of online instrumentation can be significant, and so we incorporated a level of diagnostics that was previously unheard of in the industry.

Leading the Way

The IR3000 has been the key to the tremendous growth of Sensortech’s MoistTech division. It has been the foundation upon which subsequent products have been based and it continues to lead the industry today.

As part of NASA’a planetary robotics program, Stone Aerospace was selected by NASA to develop an autonomous underwater robot capable of mapping its environment on the fly and using this map to return home. This was considered to be a critical step with the ultimate aim of exploring the sub-surface ocean of Europa, one of the moons of Jupiter. While many of the technical problems were to be taken on by universities, Stone Aerospace needed a trusted partner that not only could take on the design of key components of the robot, but could also assess whether the other contractors were developing robust technical solutions in a timely manner.

DepthX Circuit Boards

RMB designed multiple printed circuit boards for use in the DepthX vehicle and made significant contributions to the power storage and distribution systems. Through periodic meetings and reviews RMB helped keep the project on track–particularly when another vendor’s system failed at low temperatures during a critical trial.

Where No Man Has Gone Before

The DepthX vehicle was successfully deployed in Northern Mexico in May 2007 and was used to autonomously explore hitherto unexplored cenotes. As a result of these successful trials, Stone Aerospace has received further contracts to develop the technology—and RMB is continuing to ensure the future success.

When Schonstedt Instrument Company decided to introduce its GA-92XTd magnetic locator, it didn’t know if the radical mechanical design would be a big success or not. To minimize their development costs they repackaged an existing design for the electronics component. Shortly after its introduction, it was clear that Schonstedt had a hit on their hands, and so they turned their attention to the manufacturing cost of the unit. RMB was asked to redesign the electronics with the express intent of eliminating cost. By delegating this task to RMB, they freed up their own engineers for other tasks and could easily quantify the cost of the redesign project.

Passing the Test

The first step was to analyze the existing analog circuit using a combination of SPICE simulation and in-circuit testing. Once this was complete, the bulk of the analog circuitry was removed and replaced with a microcontroller. Final verification of the design involved a series of blind tests with experienced users of the device. Only once the testers were unable to differentiate between the original and new designs was the redesign complete.

Good Engineering Saves Money

The redesigned main board featured only 4 layers (down from 6), less than half the number of components, and a cost reduction of 40%. The cost of the redesign was recouped by Schonstedt within just 6 months.

For many years Babington Technology had used an off-the-shelf controller for its Airtronic diesel burner. The US military was using it extensively as part of their field feeding systems, but it had several weaknesses that were creating support headaches for Babington. RMB was brought in to explore the possibility of developing a custom control for the Airtronic burner. The challenge was to make the design backward compatible while adding new features for protection and diagnosis of the overall system.

Simulated, Tested, and Approved

The first step was to build a true-to-life simulation of the new proposed control. This included a fully working user interface that simulated behavior in the presence of under/over voltage line conditions, non-sinusoidal power, and ignition/fuel faults. The simulation demonstrated the controller’s look and function, thus cutting down enormously on the iterations typically required by such a project.

Upon approval of the simulated behavior, we designed the housing, a custom LCD, two printed circuit boards, and a substantial amount of complex firmware. After successful testing of the prototypes, we helped select a contract manufacturer and supervised the transfer of the design for production.

Better Products Mean Bigger Profits

Today Babington finally has a control that matches the sophistication of its Airtronic burner. The control’s new capabilities are opening up new markets for Babington, while its support issues are fading away as the UBIAC is deployed across its existing customer base.

When a major pharmaceutical company ran into an unexpected problem shortly before a new product was to be submitted for approval testing, they turned to RMB for an independent review of the proposed solution. The review was arranged at very short notice and required a consultant that understood all aspects of embedded systems design including power supplies, power management, signal measurement, data analysis, and firmware. RMB was able to quickly understand the issues at hand, examine the proposed solution, and offer an independent assessment of the solution and risks.

At the end of the review process, the project manager expressed gratitude for our contribution and said he wished we had been available from the beginning.

A group of private investors were interested in purchasing a small technology company with very interesting intellectual property related to secure printing mechanisms. RMB was asked to:

• visit the company
• assess the technology
• determine whether the technology was sufficiently well developed and documented for ease of transfer

After meeting with the technical staff, reviewing schematics, and poring over source code for several days, RMB was able to write a detailed report on our findings. The result was an informed decision that reduced risk.

A Canadian Printed Circuit Board manufacturer was suspected of knowingly participating in the manufacture of electronic devices designed to enable theft of copyrighted materials. An Anton Piller order (search and seizure order) was duly obtained. However, prior to its execution the legal team needed advice on what to look for when they walked through the door.

Beyond merely providing background information prior to the raid, an RMB engineer accompanied the legal team throughout the search and seizure process and was able to effectively identify parts and drawings related to the order.

Equally importantly, RMB was able to offer advice on how PCB manufacturers operate and how the raid should be conducted so as to have the minimum impact on the business, thus minimizing the possibility of the manufacturer suing the plaintiff for loss of revenue.

When DISH Network needed expert help in analyzing satellite TV receivers that were suspected of being designed for TV piracy, they turned to RMB’s president Nigel Jones for help. DISH Network knew of Mr. Jones from his work and testimony as an opposing witness in earlier litigation.

The distributors of the receivers in question alleged the product had a legitimate use. However, it was known the receivers were widely used for DISH Network piracy. Thus the essential question to be answered was, “Is there evidence to either support or disprove the hypothesis that these receivers were designed explicitly for piracy?” The analysis involved studying the hardware in the receivers, together with the factory and pirate firmware. Extensive knowledge of both hardware and firmware was needed, together a very good understanding of manufacturing methods.

To date Mr. Jones has generated detailed reports in support of multiple cases in both the USA and Canada. The first case settled shortly after the submission of his report, with an agreed judgment in the amount of $106m being entered, along with a permanent injunction barring any further importation, distribution or other trafficking in the illicit receivers.