Skip to content

🌾 Handheld computing platform for data acquisition

Notifications You must be signed in to change notification settings

Fantalucio/CropTop

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

CropTop

Development

CropTop is a small-form data acquisition platform initially developed by Kennedy Caisley and Ryan Donahue, two undergraduate electrical engineering students at the University of Idaho. It is designed to support the cereal grain crop strength research being conducted by Dr. Daniel Roberston in the UI Department of Mechanical Engineering.

The current iteration of the project is being developed by Collin Heist, an undergraduate Electrical Engineering student at University of Idaho.

What can CropTop do?

Croptop is based around a 32 bit PIC32MX795F512L microcontroller and includes the following peripherals onboard:

  • 12 bit temperature/humidity sensor
  • 3-axis accelerometer
  • ΔΣ 24 bit 1kSPS ADC
  • GNSS receiver
  • USB 2.0 OTG interface
  • 5A DC motor controller
  • Resistive touch controller
  • Rotary encoder interface
  • Linear encoder interface
  • 1GB NAND flash
  • User programmable push buttons
  • User programmable LEDs
  • 14 additional GPIO

The current screen and GUI utilizes the Nextion NX8048T070, which has an on-board graphical processor and memory. Interaction with the screen is done through a UART connection. The GUI is created using the Nextion GUI Editor, and has on-board code that can be interacted with using the Nextion-provided commands.


To-Do

  • Finish GPS implementation within screen.c and GPS.c
    • The interaction with the GPS is inside screen.c, but commented out. This is because the PIC would error during GPS read operations, and I was unable to diagnose why. I've since made some changes to the GPS library, and it might work but should be verified before implemented.
  • Finish refresh_live_feed command implementation in screen.c.
    • X-Load string needs to be generated and sent to display.
    • Y-Load string needs to be generated and sent to display.
    • Potentiometer angle string needs to be generated and sent to display.
    • IMU angle string needs to be generated and sent to display.
  • Finish start_test command implementation in screen.c.
    • The entire test procedure is not implemented.
    • Using tests.c is recommended, so that the test library is more comprehensive.
  • Implement stop_test command within screen.c.
    • Most likely, a FSM will need to be implemented to reflect the current state of the PIC - i.e. not_testing, and testing states inside tests.c to facilitate tests.
  • Implement view_first_folder command within screen.c.
    • This function will need to sent folder information data to the display. Currently not implemented since USB reading / writing is nonfunctional.
  • Implement view_next_folder command within screen.c.
    • This function will need to act similarly to view_first_folder, except sequence through folders on the USB.
  • Implement test result graphing on the display.
    • This will need to be done with the add and addt commands (sent from PIC to display) for writing to the test results Waveform (graph). Read the Nextion Instruction Set description for more detail: https://nextion.tech/instruction-set/ .

PCB Layout

Version 1.0

Initial PCB design by Kennedy Caisley and Ryan Donahue.

Version 2.0

Updated PCB design also by Kennedy Caisley and Ryan Donahue. This was more debuggable, and was designed to fit to the screen layout being used at the time (hence the shape). Had all the proper external connectors required for end-use. The screen connectors ended up being incorrectly aligned, and this required changing screen modules.

Version 3.0

Latest PCB design, by Collin Heist, that removed the on-board graphics chip in favor of the Nextion 7" display header - but otherwise, the design from v2.0 was preserved. The board was expanded to match the mounting holes provided by the Nextion screen.


Code Development Standards

Development Checklists

Header File

  • Has a valid file heading (template).
  • Has multiple-inclusion protection (template).
  • Has verbose #define statements.
  • Has function prototypes.
  • Has limited (to no) macro functions - replace these with inline functions, instead.

Source File

  • Has an associated header file.
  • Has a valid file heading (template).
  • Has required source file sections (template).
  • All functions have an associated comment block (template).
  • All small functions, that will likely not require stepping through or debugging, are inline.
  • All function names and variables are verbose (i.e. initialize_screen() as opposed to init_scr()).
  • All function parameters that do not change during operation are const.
  • All functions that are not user-facing (from a library perspective) are private (static).

Nextion GUI

  • The number of unique pages are kept to a minimum because pages have quite a lot of overhead (in memory).
  • Objects with strings - either for text display or variables - have the minimum length required.
  • The number of PIC-screen communications are kept to a minimum this is because the UART communication is somewhat unreliable.

Templates

File Heading (source and header)

/**
 *  File
 *      filename.h
 *  Summary
 *      A brief summary of the header file's purpose.
 *  Author(s)
 *      Author 1, Author 2.
 *  Note
 *      Optional additional information regarding the file.
 */

Multiple Inclusion Protection

#ifndef __FILENAME_H__
    #define __FILENAME_H__
    // Code
#endif

Source File Sections

/* ----------------------------------- File Inclusion ----------------------------------- */
/* -------------------------- Global Variables and Structures --------------------------- */
/* ---------------------------------- Public Functions ---------------------------------- */
/* --------------------------------- Private Functions ---------------------------------- */
/* ----------------------------- Interrupt Service Routines ----------------------------- */

Function Comment Blocks

/*
 *  Summary
 *      Short description of the function.
 *  Parameters
 *      param1[in]: Description of the first parameter (in if not changed).
 *      param2[out]: Description of the second parameter (out if changed).
 *  Returns
 *      Describe the meaning of the return value (if there is one).
 *  Note
 *      Optional addition of the function.
 */

About

🌾 Handheld computing platform for data acquisition

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • C 72.8%
  • Makefile 24.8%
  • Shell 1.6%
  • C++ 0.8%