Cybiko Project Ideas

We know that the reliability issues with the RF/RS232 subsystems on the Cybiko will eventually cause lockup on a Cybiko unit. In order to circumvent this, the following is proposed …

Have a co-located pair of Cybikos dedicated to running an RS232 to RF link. RF data would be sent/received in 'broadcast' mode. Therefore all Cybiko units would receive all messages. The AVR microcontroller would ensure that the datastream was sent to each Cybiko for xmission and that received messages were de-duplicated before being passed down to the connected RS232 subsystem. A 'heartbeat' line would be connected from each Cybiko to the AVR. This would be continually toggled by code in a running Cybiko. If the heartbeat ever failed, we assume that the Cybiko is hung and the AVR would initiate a reset pulse to the affected Cybiko. This would then reboot & re-join the party.

The following diagram illustrates the setup for one resilient node:

Another thought. Rather than having both Cybikos transmit and receive at the same time, it might be better to run a 'master/slave' setup. We know that a Cybiko that does not take part in much RF or RS232 activity will happily run for many days (weeks) at a time. Therefore, if we keep one in slave mode, simply running the heartbeat, the chances of two units going down at the same time should be very low indeed. Will need some sort of protocol to allow the remote controller to know 'who is master'.

AVR would talk to the subsystem using its internal UART. The Cybikos RS232 would be connected to 'bit banged' ports on the AVR. Fortunately, BASCOM has a good implementation of these virtual serial ports. Reckon it might be best to clock the AVR device at 12MHz., to give that little extra grunt.

Remember that, when booting, the Cybikos throw out a load of debug data onto the RS232 port. The AVR code will have to ignore this.

Init all three ports to 9600baud 8 bits, 1 start, 1 stop , no parity.
do
  wait for heartbeat from Cybiko1
  if good Cybiko1 heartbeat, select Cybiko1 as master, exit loop
  else reset Cybiko1
  if good Cybiko2 heartbeat, select Cybiko2 as master, exit loop
  else reset Cybiko2
loop
 
do
  check for heartbeat from master, if no heartbeat swap master/slave
  check for incoming byte from subsystem, send to master
  check for incoming byte from master, send to subsystem
loop   

A general purpose 'smart' terminal for use in conjunction with a microcontroller.

Connects via the Cybiko serial port to micro UART at a user configurable baud rate

Cybiko runs a custom written Command Interpreter that exposes the features of the Cybiko in order that they can be easily used by the micro. Idea is to have the Cybiko act as an 'intelligent' peripheral which provides a range of services to the micro.

Ideally, the command protocol should be reasonably 'terse' so as to allow small micros, with limited ROM/RAM space to work with the Cybiko. In many useage scenarios, the Cybiko is likely to have more 'grunt' than the micro to which it is attached. It would be good if certain commands might operate concurrently. e.g. if we ask the Cybiko to get us an 'Enter delimited string' from the keyboard, it would be neat if we could continue to perform other operations whilst waiting for the string to be entered.

Investigation into the threading models within CyOS might be interesting.

Features:

• Keyboard
  1. All keyboard input to be re-directed to the Cybiko serial port.
  2. Support an 'editbox, OK, Cancel' style UI for simple data entry.
• Screen - Micro can direct its output onto the Cybiko screen. Perhaps implement VT100 style control codes.
• Sounder - Micro can activate the sounder on the Cybiko.
• Vibrator - Micro can activate the vibrator on the Cybiko.
• Wireless - Micro can:
  1. scan for other Cybikos in range and get a list of their Ids
  2. send a message to another Cybiko
  3. be notified of incoming messages to the attached Cybiko
• Datalog - Micro can open a named file & subsequently store gathered data to this file.
• Dataread - Open a named file & read data items from it (e.g. a pool of string resources)
• Date/Time - Micro can retrieve the Date/Time from the Cybiko
• Id - recover the CyId and nickname of the attached Cybiko.

Advanced idea. Have a PC based program to allow a UI for the Cybiko to be designed. This might be as simple as “constant text” (like a “help page”) or as involved as having a “name/multi-value options” setup screen. The PC based program then generates the UI for the Cybiko and an 'include' file which allows the UI to be displayed and interacted with.

Note: Recently, the RFTerminal program has been further developed. It now has quite a lot of the sort of functionality that is mentioned in this idea.

This would be a useful utility that would could be used to verify that various programs in the messaging suite are working. i.e. RFTerm,SerialRelay,Repeater

Useful options might be

• Max/Min length of message
• Transmit pace - How may messages per minute should be generated.
• Timeout period - After running for a given number of minutes the unit should halt for a period.
• Halt period - Amount of time to suspend transmision during a timeout.

The addition of a MP3 player and associated smartcard to a Classic unit would allow a smart 'RS232 based disk storage subsystem' to be developed. A microcontroller could send RS232 commands to create files, store and retrieve data etc. Great for data logging from remote experimentation. Since the smartcard can be read by a PC (it's just a FAT filesystem) this is easy to do.

The current application suite is now quite extensive. In order to save code space and reduce the burden on code maintanance, it might be interesting to explore how easily a .dl can be made to allow sharing of commonly used functions.

Here is the first user-created .dl for use in programs. It ties together 4 of Ernest Pazera's functions and I called it epforms.dl.

epforms.zip

The functions are:

FileListForm gets a list of files according to the wildcard filter (ex. *.txt) that you provide when calling it in a form that you can simply scroll through and select. The other parameters are easy to figure out from the prototype:

int FileListForm(
 char* title,    // (IN) Title of the form
 char* filter,   // (IN) Filter for file list
 char* filename, // (OUT) Filename selected
 struct cWinApp* ptr_win_app, // (IN) app pointer(main_module.m_process)
 int x,          // Upper left corner, x pos
 int y,          // Upper left corner, y pos
 int w,          // Width of form
 int h           // Height of form
)

SimpleMenuForm pops up a form with text line options that you can scroll through and select. Here's the prototype:

int SimpleMenuForm(
 char* title,     // (IN) Title of the menu
 char** ItemList, // (IN) List of items (array of char*, with last item being "")
 int x,           // (IN) X coordinate of upperleft
 int y,           // (IN) Y coordinate of upperleft
 int width,       // (IN) Width of form
 int height,      // (IN) Height of form
 bool round,      // (IN) TRUE=rounded, FALSE=rectangular
 struct cWinApp* ptr_win_app // (IN) App pointer(main_module.m_process)
)

MessageBox is the easiest to use and it is your standard pop up message with buttons to press. It's prototype is:

int MessageBox(
 char *title,   // (IN) Title of the message box
 char *message, // (IN) Message for this message box
 long style,    // (IN) Style (combination of mbXXXX constants)
 struct cWinApp *ptr_win_app // (IN) App pointer (main_module.m_process)
)

InputBox is similar is MessageBox except that it has an input area to enter a line of text. It's prototype is:

int InputBox(
 char* title,     // (IN) Title of the input box
 char* message,   // (IN) Message for this input box
 long style,      // (IN) Style (combination of mbXXXX constants)--NOTE: mbEdit does NOT need to be specified
 int edit_size,   // (IN) Max length of the string for input box
 char* edit_text, // (IN/OUT) Input box text
 struct  cWinApp *ptr_win_app // (IN) App pointer (main_module.m_process)
)

Right now, the only way that we have to connect a Cybiko to a 'gateway' PC is via the RS232 port on the Cybiko Classic. However, there is an alternative route to exchanging info between these devices. When fitted with an MP3 player, there is a USB connection between the Classic and the PC (in addition to the serial link). Files written to the MP3 flashcard by the PC can be read by the Cybiko. Files written by the Cybiko to the flashcard can be read by the PC. Obviously, this isn't great for transient messaging, but it might prove handy for occasional large dumps of data.

Update … looks like this won't work. Whenever the USB cable is in place, access from the Cybiko to the smartcard seems to be disabled!

A possible workaround for this problem would be to use some sort of wireless transfer application to access the information on the smartcard.

A driver and processor for a motor, such as in a model Chinook. Uses RS232 to communicate with external microprocessor (PIC?) which sends and recieves data about pitch, yaw, motor speeds, and possibly expandability for landing, roll, turning. Gui on remote cybiko to display the information, maybe in graphical format at some point. Should at least display the data such as pitch and yaw. Uses RPM counter from Widget libary.

The cybiko incorporates an I2C bus for the internal clock. If this were tapped into then several extra functions could be obtained, such as parallel output or digital potentiometer. There are also functions like temperature sensors and sound control, such as volume and tone.