modules malloc os_module

Can someone who looks after AcornDDE confirm that OS_Module 7 in application space is the same as free() when used in a module environment. ie you can use OS_Module 7 in application space to free a malloc created in a module. I can’t find it documented anywhere. Doesn’t seem right to me – a different language may implement malloc/free in modules differently.

I would be very surprised if there was any direct compatibility between free() in a module and OS_Module 7.
Consider fopen() handles vs OS file handles.

As would I, which is why I think it can’t be right to use it to free the linked list returned from OS_ServiceCall,1,0xd2 (report usb connected devices).

I would assume that a memory block defined by an OS API would be an RMA block so you would use OS_Module to free it.
Of course, you could always try free() and see what it does? :-)

I’m surprised OS_Module 7 didn’t fail. The service call is handled in usbmodule at line 525 which calls service_call (line 1465) for each device and service_call uses malloc to create the linked list item.

I haven’t been using OS_ServiceCall. As I said before I can’t see a way to delete it. In any case even if a “correct” way to delete it was made available – say another call to free the block – it doesn’t feel safe to me. If my program crashes before I free the block the data doesn’t get freed. I would much rather have seen a call which put the list in a block allocated in the callers environment – but that may not be possible if the list of attached devices can change between a call to get a block size and a call to fill the block.

which calls service_call (line 1465) for each device and service_call uses malloc to create the linked list item.

We would need to examine the CLib code to see what malloc() actually does in this case – because it would be dumb to use a CLib specific function to allocate memory . . . how are you supposed to deal with that in a BASIC program?

[see next post]

It is okay.

malloc() is defined in this file and it begins:

extern void *malloc(size_t size)
{ void *ptr;
  if (_kernel_processor_mode() & 0xF) /* not USR26 or USR32 */
      return _kernel_RMAalloc(size);

and free() is just below, beginning:

extern void free(void *p)
{ int rc;
  if (p >= RMABase && p < RMAEnd) {
    _kernel_RMAfree(p); return;

The _kernel functions are here and the code is:

|_kernel_RMAalloc|
        FunctionEntry
|_kernel_RMAalloc_from_extend|
        MOVS    r3, a1
        Return  ,,EQ
        MOV     r0, #Module_Claim
        SWI     Module
        MOVVS   a1, #0
        MOVVC   a1, r2
        Return

and:

|_kernel_RMAfree|
        FunctionEntry
|_kernel_RMAfree_from_extend|
        MOVS    r2, a1
        MOVNE   r0, #Module_Free
        SWINE   Module
        MOV     a1, #0
        Return

So in short, it looks like it claims/frees RMA blocks, so the associated OS_Module calls should work just fine.

:-)

Good.

All we need now is one of the good people at ROOL to change the USB docs at around line 292 to specify that OS_Module 7 should be used to free the memory.

Still not totally happy. I like my mallocs and frees to be black boxes. A change to malloc/free may inadvertantly cause a problem – or if riscos is compiled with another compiler the internals may be different.

A change to malloc/free may inadvertantly cause a problem – or if riscos is compiled with another compiler the internals may be different.

I wouldn’t imagine this would be possible – there are specific limitations on how you can allocate/release memory in the RMA. You can’t arbitrarily extend the size of a module, you can’t claim application workspace (which may be paged in and out beyond your control) and you can’t play with WimpSlot (application workspace again).

Therefore, so long as it is a module and the address is in the RMA, the code for malloc() and free() should immediately fall into an OS_Module claim/release. There’s not a lot else it can do. Well, I suppose it could do it as a Dynamic Area, but that would be weird for the sake of being weird!

Given the head banging that it took to get the USB stuff working on the Beagle (thank you again!), and given that I am still getting padding packets (don’t care, with MIDI I can work around this), I think that the above will be black-boxy enough for me to call OS_Module 7 and leave it at that. :-)

Now it works, I hope all the rest will be… if not simple, then at least relatively painless.

Unless you’ve already changed it miditest2 has the wrong mask for nopad it should be NOT 1 not 1 :-) ie &fffffffe

Unless you’ve already changed it miditest2 has the wrong mask for nopad it should be NOT 1 not 1 :-) ie &fffffffe

Mmm, is the miditest2 you have the one that sets up OS_Args as “(31 << 1)” instead of “(1 << 31)”?

Note to self – don’t code when you’re tired! ;-)

:-)

Are there any docs giving details of SWI OS_Args 9 (IOCtl) in full?
Perhaps explaining nopad and noblock.

Documentation is very sketchy. ‘noblock’ is a DeviceFS specific option set with OS_Args and I’ve tried to document it in the Wiki – Textile aaargh! ‘nopad’ isn’t set with OS_Args – though it should/could be. It is specific to USB and is found in the USB docs I mentioned earlier.

I was after a USB to RS232 adaptor that I could use with Windows/RISC OS. The Windows side was to connect a Morse key to a machine that didn’t have a RS232 socket.
The Windows program – CWCom Morse Code Communicator (MRX Software) reads the 9 pin RS232 port (Pin 6 DSR and Pin 4 DTR) – Morse Key presumably joining the connections together.

The idea was – if the adaptor worked well with RISC OS – it should work with Windows – one adaptor I acquired – I havn’t yet got to work.

USB adapters are the other thread :-) do you know which chipset you have in your adapter?

Information from the Iyonix is :-
Serial adaptor Vendor ID 1a86 – product Id 7523 USB spec 1.10 – Product USB2.0-Ser!

Ha! I was bogged down with one of those before I got bogged down with the castle usb stack :-)

It’s a CH340 and information about it is, to be charitable about it, non existant. I’ve even used information from the PCI version datasheet. Anyway I have it working for basic serial operations but got sidetracked at that point so I don’t yet know how to handle the pins you want.

Have you tried it on a PC and does it work with your morse key? The reason I ask is that if its the same cheapo cable from amazon that I have it only outputs a non standard 5v space and 0v mark.

Thanks for that info on the CH340 – it was about to get flying lessons :-)
Have you a RISC OS Serial Driver – or a means of talking to a modem -available?

Not working with XP – have you a Driver – the morse key only connects two connections together so I doubt if the 0-5V output will make any difference – real high tech.

Windows 8 found a driver for it. Try this ch341ser.zip driver

On the riscos front I have data transfer without handshaking ie I’m only using the rx and tx pins I can switch on and off dtr rts I just need to figure out how to read the other pins. ie which flag is which pin.

Its not a riscos serial driver but that won’t matter for you. I could probably cobble together a BASIC version for you to tinker with – or would you prefer C. It’ll be a few days – I need to find the time.

Thanks for the pointer to the XP driver – instructions in – what looks to be Chinese – and a BASIC File.

What program do you think -could display the Chinese & English charactors?

A BASIC copy of your driver for RISC OS – would be very interesting- Tks

Ok here’s a BASIC program CH340.zip which just allows you to read and write the modem status. I’ve kept it down to a minimum so as not to be too confusing. It just recognises the device and has setModemStatus and getModemStatus functions.

I’ve got a CH340-based dongle on its way to me, so I would appreciate all the code you are prepared to make available.

Ok no problem. I’ll tidy up what I’ve got and post it. I have one last problem left – what is the interrupt endpoint for. It seems to work without it.

I don’t know if you’ve tried it but snoopy pro is handy on a PC for seeing what windows drivers are doing.

Here’s the code CH340c.zip. If any of the code is useful feel free to use it.

I can only think the interrupt endpoint is related to Hardware handshaking – I’ve not tested that.