Hi Okabe. 2017年8月19日土曜日 15時03分17秒 UTC+9 Kiwamu Okabe: > Hi Fujii, > > On Sat, Aug 19, 2017 at 2:32 PM, Fujii Ken-ichi <fujiik...@gmail.com> wrote: > > I am building embedded drivers for RX110 series. > > It is still on the way, but since the bit manipulation functions for that > > has been completed, it will be released. > > > > https://github.com/fujiik102/ats-rx-drivers > > It's great work for me!
Thanks! > > > Bit.sats in the above describes bit manipulation functions and the > > definitions necessary for them. > > Bit.dats and BitInt.hats describe the implementation of the implementations > > and propositions of the functions (BitInt.hats is included from Bit.dats). > > > > Pin.sats and Pin.dats are defining and implementing general-purpose I / O > > drivers for pins, but they are still in the middle. > > Over future of your library, what invariant on hardware register can we > capture? > For example: > > * Enforce that code doesn't read and use uncertain bit If you are saying things like a register that can read an uncertain value unless some setting is made. So, I think there are two choices. 1.Restrict reading of registers. Add arguments of the configuration view to the register read function. 2.Restrict the use of reading results. Add a snapshot of the setting view at the time of reading to the register view. Either way, I think that we should respond individually. > * Enforce that code doesn't start DMA without setup of buffer I think DMA will be a problem in programming with theorem-proving. Simplest solution is to prohibit DMA. Then we can put troubles in the trash box with usefulness. Even if you take other methods, DMA should not be applicable to all addresses. For example, it limits the read address of DMA to the receive register of the serial driver. In that case, the serial driver must also be designed to support DMA. Or perhaps it is better to give up on implementation at the driver level for DMA and provide only abstract interface. My recommendation is the first one. In addition, List one of the other problems. * Time measurement and impatient interrupt When performing timing dependent processing, it is important to accurately know the current time. But ”time” has a nasty nature that will change as we measure. Also, we tend to think that execution time is predictable, but that is a big mistake. For example, A fickle compiler may put in a gap of our program one million nop instructions. Or more likely, long time interrupt handling may be inserted immediately after acquiring the current time, and the "current time" of that interrupt may be ruined. Temporary interrupt disabled will solve the problem of interrupts, but that's the entrance to another difficulty. One of the common requirements for embedded development is that the system is required to do something process within x micro seconds after an interrupt trigger occurs. However, interrupt handling is not always called immediately after a trigger occurs, for example during other interrupt processing or when the interrupt is disabled. In that case, it is necessary to limit the interrupt invalidation period and the time taken for interrupt processing. As a solution, make an in-language language to run assembly language inline, but it is bothersome, I do not want to do it. It is a future task. Please tell me if you have anything amazing solution. Best regards, -- You received this message because you are subscribed to the Google Groups "ats-lang-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-users+unsubscr...@googlegroups.com. To post to this group, send email to ats-lang-users@googlegroups.com. Visit this group at https://groups.google.com/group/ats-lang-users. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/ac887bf3-cab9-4aa0-80b7-c87d9e25fd0d%40googlegroups.com.
