Hello Matthias, Matthias Trute <mtr...@web.de> writes:
> Hi Enoch, > >> Would you be ready to replace the autogenerated readflashcell / >> writeflashcell code in device.asm for 128KB architectures as follows: > > Some of the 128KB devices use two bits in the RAMPZ register (at > least according to the partdescription files). And all of the > 256KB devices (obviously). Your patch potentially breaks them > all. > My project's AVR does not mind writing non-0s to RAMPZ bits 1-7. 256KB devices can use two ROLs followed by two RORs to restore. AmForth, BTW, does not currently support >128KB Flash programs. If readflashcell and writeflashcell were in macros.asm I would not mind if they had a destructive temp7 side-effect (AmForth ASM programmer must be familiar with macros.asm). Not so the case with the automatically generated device.asm which is a sort of hardware description. >> P/S I have rewritten your usart ISR drivers to support RTS/CTS/DTR in a >> generic way (using application supplied macros). > > I rewrote (internally) the assembly code with plain forth code: > > ; : isr-rx USART_DATA c@ > ; dup 3 = if cold then \ ctrl-c check > ; usart_rx_data usart_rx_in c@ dup >r > ; + c! > ; r> 1+ usart_rx_mask and usart_rx_in c! > ; ; > ; setup with > ; ' isr-rx URXCaddr int! > > It the verbatim translation of the existing code, it took > (IIRC) a few minutes to write it. It has > some possibilities for improvements / factors, that the > assembly code does not have. One could be your CTS/RTS (or > XON/XOFF) flow control. > >> BTW, I can now upload code using any send-file utility which respects >> CTS, so bye-bye echo monitoring :-) Will share code if you are interested. > > I am, as long as you use forth ;) Here I have a different opinion. The use of ASM in the implementation of the kernel, if it leads to faster execution yet without code size bloating, is *a good thing*. Ordinary AmForth users would thank you if their Forth code would run faster. > Since CTS/RTS use additional hardware a recipe > for the cookbook would be great. Subject to the GPL license you and any other AmForth-er are welcome to examine my changes at https://github.com/wexi/amforth-shadow Using #ifdef in the kernel makes the use of CTS/RTS/DTR optional. The application supplied macros are exlained at https://github.com/wexi/amforth-shadow/blob/master/amforth-shadow.org For the record, here is amforth-shadow non compete agenda: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ AmForth master site is http://amforth.sourceforge.net/ -- We hope it accepts our experimental code :-) About another experimental code hoping to be integrated into AmForth HQ: I am very happy with those "soft interrupts" (SLIH). They enabled me to accomplish things from within ISRs which would otherwise have required multitasking. I look forward to help in further AmForth development as my time allows. Thank you for your great work. Regards, Enoch. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
