Show pageOld revisionsBacklinksBack to top This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong. ======How does that work?====== This section is to log aspects of the cybiko that need further investigation. =====Native compilation===== An undocument directive exists for the C compiled that indicates that the following code block should be compiled to native code. <code c> __native void hello() { <code goes here> } </code> The problem is all attempt to compile and link a source file that contains such a directive fail on the link stage. It would seem that if you compile using the vcp1 (C++) compile rather than the vcc (C) compiler the output from C++ using the -V18 switch will actually link. {{native.zip}} It does run but this another matter to investigate. =====Serial I/O===== Control flow API, how do these actually work? <code c> bool com_get_DTR ( com_t port ) bool com_get_RTS ( com_t port ) bool com_set_DTR ( com_t port, bool state ) bool com_set_RTS ( com_t port, bool state ) </code> Does this API actually toggle a pin on the serial port high/low?\\ This program {{serialflags.gif}} {{serialflags.zip}} will invoke these API calls, we just need to monitor the serial port with a break-out box to determine what happens. These keys invoke the com_set... API function calls. <code> <Q> set DTR <W> clear DTR <E> set RTS <R> clear RTS </code> Any character that appears on the cybiko serial port will be echo'd straight to the console. <note classic> It would seem that the RTS/DTR pin are not exposed on the 4pin serial connection that is used by the Cybiko Classic. </note> After examining the Cybiko Classic schematic, it is obvious that there is no DTR/RTS control. Which does beg the question - what were these API called designed to do? cybiko/thingstoinvestigate.txt Last modified: 2009/11/27 17:54by 127.0.0.1