Is it possible to connect and disconnect to some available network connection with swift, cocoa?
///Addition
So.. I found the NSNetworkInterface, but can't understand how to turn it on or off. Need some little example, just explain, what call -> what get
Is it possible to connect and disconnect to some available network connection with swift, cocoa?
You can't do any of this on iOS, of course, since your code will never run with sufficient privileges and the necessary frameworks probably aren't available. You asked about Cocoa, though, not Cocoa Touch, so I'm presuming you're talking about MacOS X.
I assume that you mean actually connecting to a network rather than just connecting to some host over an established network. To do that, you need to change the system configuration. It is possible to do that, although you'll need to work at a lower level than Cocoa and instead use the SystemConfiguration framework to change the configuration registry. Your code will have to be running with root privileges in order to work, and that alone may make the process untenable depending on your situation. You can find complete instructions and code at Programmatically changing network configuration on OSX. Note that the article dates from 2011, so it's possible that things have changed enough that the advice there no longer works, but it will at least point you in the right direction.
The article obviously predates Swift, but I don't see anything there that wouldn't work in Swift.
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
I've got a Behringer X32 rack, which uses an extension of the OSC (Open Sound Control) protocol. This particular rack communicates via UDP packets on port 10023. A fellow named Patrick Maillot actually has some pretty extensive albeit unofficial documentation of the protocol, including multiple executables you can download to interact with the system (outside of the official Behringer apps).
What I would like to do is pretty simple, though I'm having a hard time getting up to speed with this. I want to be able to mute and subsequently un-mute Mute Group 1 on my device. The mute group is already set up; all I want to do is utilize the protocol to either activate or deactivate it.
I can successfully connect to the rack using the X32_Command.exe program. But wading through the documentation, here's what I came up with as my best guess for which commands I should be sending:
/config/mute/1/ON
/config/mute/1/OFF
However, I don't think I have the syntax right (or maybe I've just got the wrong set of commands altogether), because those don't seem to do anything. In the X32_Command.exe console application I appear to receive the following responses when issuing those commands, respectively:
->X, 20 B: /config/mute/1/ON~~~
->X, 20 B: /config/mute/1/OFF~~
However, nothing actually happens on the rack. The mute group isn't affected at all when I issue these commands. How do I get this working? What am I doing wrong?
Just saw this (better late than never). The correct syntax for X32_Commmand.exe would be (as stated in the documentation):
/config/mute/1 ,i 0
/config/mute/1 ,i 1
Normally in Linux PCI drivers may expose a control interface to user-land
via a character device, e.g. /dev/drv_ctl, and a user application can
read/write I/O control commands with ioctl() on the open file descriptor.
In Linux we create this with register_chrdev() kernel API.
I would like to have the same or similar mechanism and behaviour on Solaris, but seems that on Solaris it works slightly different; DDI routine ddi_create_minor_node() requires a node type indicating audio, block, net etc. device, this looks quite vague to me, for example what type a crypto PCI device belongs to?
Also, it seems that ddi_create_minor_node() creates a node under /devices/* and not under /dev/*
I would appreciate if someone could clarify my doubts and point out at the right directions.
Thanks.
Typically you create a symlink under /dev yourself, using a name which is useful to you. That would point to your actual /devices path which was created by calling ddi_create_minor_node(). You'll find the list of ddi node types in <sys/sunddi.h>; for a crypto device (what even is that?) you'd probably want DDI_PSEUDO.
I need help, I'm desperate
During two weeks I have been working in my project, this uses serial port communication (a PIC serial board). I got to set the connection up, but I can not get data from the COM port. I've read some forums and the cause of the problem seems to be the incomplete implementation of System.IO.Ports class.
When I try to get data of the COM port, the event SerialDataReceivedEventHandler (represents the method that will handle the DataReceived event of a SerialPort object.) is not called or activated. I tried to resolve it but I don't find a definitive solution. I thought to prove a external DLL, but a friend told me that the problem will go on, in fact I did it and got the same problem: SerialDataReceivedEventHandler does not work. Also, someone recommended me using a secondary thread, although I don´t understand how to do it at all.
I wrote a program in visual C# and everything works fine. I'm intrigued.
I need to find a solution, some idea or good documentation. If there's someone knows something about it, help me please.
I need to understand the cause of this to continue.
Unity is based on Mono, and Mono doesn't implement completely the Serial class, in particular there are no notifications implemented (such as SerialDataReceivedEvent).
That's why it works in Visual Studio, and not in Unity.
Here are the differences between the Mono and complete .NET implementation of the Serial class :
Extract from http://www.mono-project.com/archived/howtosystemioports/#limitations
"Limitations
At the time of this writing, there are a a few limitations that one must take note:
1) There is no event notification for received serial data. If you want to receive data, one must set a timeout and watch for received data by polling ReadByte() when you think there might be data.
2) One must Read data in byte[] format only – there is no char[] support. You must do your own reading of bytes and translate that into your encoding.
3) DiscardNull, ParityReplace, ReceivedBytesThreshold are not implemented."
I think it happens because the Unity is based on Mono instead of .Net, and a pretty old version of it. You couldn't use Linq on iOS devices for a long time because of AOT bugs, and the localisation implementation is buggy (or at least it was in the previous versions of Unity I tried to work with). I wasn't even able to find the source of System.IO.Ports in the source of Unity's Mono fork, so it's surprising it compiles at all.
I have a rather popular Bonjour-based application in App Store. It works perfectly, but around 0.2% of my users report a bizarre bug: "no arrows appear on the edges of the screen, so I can't share stuff with other people!". Needless to say, displaying these arrows is tied to the browsing of a particular Bonjour service on the local domain.
The problem is, the Apple review team seems to intermittently happen to be in this 0.2%. This isn't good for review results, as you might imagine. No matter how much I try, I cannot reproduce this bug.
From the few logs I have, it looks like my app is running correctly, just not receiving NSNetServiceBrowser delegate calls. What can cause this?
Things I've tried:
Having a shorter service name < 14 chars in length to be in spec.
Publishing on #"local." rather than #"" (aka Go Look For The Default Registration Domain). My app is rather useless on a wide-area network anyway.
Things I haven't tried: restarting the browsing machinery periodically. (I have two browsers, though, one looking for the legacy longer name, one for the new shorter one.)
What to do?
There are many areas where things can go wrong. Since the NSNetService instance provided to your delegate methods is autoreleased, you need to retain it if you plan on reusing it out of scope for that method. Most people will add it to an NSMutableArray or NSMutableDictionary so that it is automatically retained, and only autoreleased when removed from the collection. If that is the case for your code, make sure that you have properly initialized your collection before adding the object. Since messages to nil are perfectly ok, you may be sending the addObject:netService message to nil. You will not receive an obvious indication that you never initialized your array or dictionary, and it will appear as though everything is working just fine…except that delegate messages “mysteriously” don’t fire off when peers change status, when you try to connect to one, etc. This crops up often enough in Bonjour troubleshooting that I would recommend it as the first place to start your troubleshooting. It happens to the best of us.
One easily missed problem for apps running network code on a background thread: throwing an un-handled exception on that thread. This can occur without crashing your whole app due to Cocoa/Unix’s rules on threading. If your networking code “just stops working for no reason,” then you may want to check your iPhones Console and logs for error messages. Make sure you have set a breakpoint on the objc_exception_throw symbol.
For more, read the full article "Troubleshooting Bonjour Networking for the iPhone" at my dev blog.