- Active Projects
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.
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.
Useful options might be
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.
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.