_____ 
 |_   _|
   | |  
   | |  
   |_|  
        

 _   _ 
( ) ( )
| | | |
| | | |
| \_/ |
`\___/'
       
       

  _____ 
 | ____|
 |  _|  
 | |___ 
 |_____|
        

     ### 
  #####  
 ##  ##  
 ##  ##  
 ##  ##  
 ##  ##  
  ### ## 
         

 _______ 
(  ____ \
| (    \/
| |      
| | ____ 
| | \_  )
| (___) |
(_______)
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
See BuildrootOrangePiPc (fast boot) Notes about ECU serial external datalogger * request runtime data via (bidirectional, full duplex) 1st serial port of VEMS ECU * log to SD card ** in .vemslog format ** with timestamps if RTC available * USB mass storage device to PC, so files from SD can be transferred to PC fast (normally without removing SD). Currently implemented on STM32F103C8T6 (using device' built-in RTC and USB). '''Considering: porting to Orange PI PC (or lite / one / zero / plus or similar)''' * with optional header-connected I2C RTC (useful if no ntp/GSM/wifi internet or other time-source) * the immensely powerful device can be "double"-used for many apps simultaneously, even cloud apps: secure wallet, or file sharing, audio/video communications / capture (and motion) * perhaps recording audio before rally race could log more information about date, environment, vehicle than an RTC would provide, ** and perhaps even running vemstune (although a bit slow for logviewer, and the linux build kinda works, but hasn't been too agressively tested for stability) ---- '''STM => Orange PI PC notes''' * logging to (unix) file instead of self-handled FAT FS on SD block device ** the timestamp is handled automatically * using high level /dev/ttySx or /dev/ttyUSB0 or similar serial port, instead of stm32's raw UART. * mainloop: select() instead of busyloop (considered kind in generic multitasking environment) * optional: data relay ** if serial data is coming without request, sending (relaying) the same RAW data to the TX would make (perhaps) sense. ** This way ECU TX => ARM => VT => ECU RX could be implemented (when no VT, just plug in a dummy DSUB9 with 2-3 connected to close the loop ) ** alternatively ARM could be sniffing the ECU TX => VT line (and ARM => ECU only activated when PC/VT serial is disconnected). No serial relay is needed in the ARM for this. ** However, '''ARM best have v3 ECU config (only needed for EGT cal, assuming 72.5 would work well though, as egt calibration is 72 usually) *** ECU config requested at startup, which might not be available if VT is started before ARM (not the normal usecase, but worths to consider) ---- Orange PI PC arm-hf binary __might be__ compatible with raspberry arm-hf 32 bit (although raspberry is not an initial target, and might not be supported) * perhaps depends on Debian Jessie or Ubuntu library details, if that is used (slow boot) * Orange PI PC H5 and Raspberry 3 in 64 bit mode need different compile (64 bit toolchain)
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.